GitHub adds Starlink secret detection while cutting noisy credential matches

GitHub now detects Starlink public API v2 secrets, with SpaceX joining its secret-scanning partner program. The November 5 update also tightens several existing detectors to reduce false positives. These are two sides of the same practical problem: find more genuine credential leaks without burying maintainers in strings that only resemble credentials.

The new detector is named starlink_public_api_v2_secret. When a supported partner secret is found in a public repository, GitHub can notify the issuing provider so it can take protective action, such as revocation or rotation. The announcement does not establish that every detection has already been revoked, nor that every possible Starlink credential format is covered.

A plausible string is not always a secret

Several improvements concern the context around a candidate value. GitHub says the OpenVSX detector now handles legacy tokens more carefully so unrelated UUIDs are less likely to be mistaken for credentials. The Logfire detector follows the documented length and character set more closely, excluding placeholders and public browser tokens.

For Alibaba, AWS and Google patterns, the changes can suppress isolated matches when filtering removes the companion value needed to make the pair meaningful. Tencent detection now requires both letters and digits after the prefix, avoiding alphabetic identifiers such as function names.

Those examples show why secret scanning is not just a search for long, random-looking text. Many legitimate identifiers look random. Some examples in documentation deliberately resemble keys. A detector has to use format and context to distinguish a plausible exposure from background material, while avoiding filters so aggressive that real leaks disappear.

Less noise can make real alerts easier to act on

A false positive costs attention even when it causes no direct security incident. Someone has to inspect the match, understand the surrounding code and decide whether it grants access. Repeated unnecessary alerts can make the next warning easier to postpone.

The update does not publish a universal reduction percentage, so it would be wrong to claim a measured improvement across all repositories. It does identify concrete cases in which detection has become more selective. That is a better basis for understanding the change than a generic claim that the scanner is now smarter.

GitHub’s secret-scanning documentation recommends rotating an exposed credential. Removing the string from the latest file does not, by itself, invalidate a copy someone already obtained. Repository history and the credential’s validity are different parts of the problem.

Partner notifications and repository alerts are not identical

GitHub distinguishes notifications sent to the issuing partner from alerts shown to repository users. The partner program supplies a route to the service that can revoke a credential; repository alerts support the maintainer’s own investigation. Available features also depend on repository type and plan.

The documentation says public repositories receive scanning automatically for free, while private organization repositories require the applicable Secret Protection configuration. It also describes scanning Git history across branches and rescanning when new supported types are introduced. A newly added detector can therefore matter to code that was committed before the detector existed.

The practical gain from the Starlink addition is a shorter route from an exposed supported token to the people able to invalidate it. The quieter existing detectors address the other half of that route: helping a maintainer recognize that a warning deserves action. A secret scanner earns trust when it finds the right string—and the response actually removes the access that string carried.