GitHub Secret Scanning Adds Starlink API Detection and Tunes 10 Credential Detectors

What changed​

GitHub lists three items:

• New partner: SpaceX is now a secret scanning partner.
• New detector: GitHub now detects starlink_public_api_v2_secret.
• Upgraded detectors: The Alibaba, AWS, Google, OpenVSX, Pydantic Services and Tencent detectors get additional false-positive filtering.

The changelog presents the SpaceX secret twice, once as the partner's supported type and once as a newly detected type. It doesn't mention push protection for this pattern. It also doesn't mention validity checks or a minimum plan for this detector. Don't assume any of those.

How partner reporting works​

When a match for a partner's secret format is found in a public source, a payload is sent to an HTTP endpoint the provider chooses. GitHub's documentation says the provider then validates the string. Providers are expected to implement secret revocation and user notification in their alert service. In practice, SpaceX decides whether to revoke the credential, issue a new one or contact the affected user. That decision depends on risk. Detection and forwarding don't by themselves mean a credential is valid or has been revoked.

The changelog describes two separate paths:

• Partner path: Partner secrets are reported automatically to the issuer when found in public repositories.
• User path: User secrets generate alerts when found in public or private repositories where secret scanning applies.

The partner path is described only for public sources, so don't assume a private-repository match is automatically sent to SpaceX. GitHub's docs also say partner alerts go to the provider and don't appear in your repository's alert list. Don't wait for a Security tab entry as proof that a partner has been told.

GitHub's partner documentation says scanning covers more than commits:

• issue and pull request titles, descriptions and comments
• GitHub Discussions
• wikis
• secret gists

Public partner-pattern scanning can't be reconfigured. These are general program details, not a SpaceX-specific confirmation for every location.

Background from outside GitHub: an independent API catalogue says Starlink's Public API V2 credentials are tied to an enterprise or business Starlink account, whose admin must create a V2 service account. That is third-party profiling, not part of GitHub's announcement. It does suggest the exposed credentials belong to account administrators, who can manage fleets of terminals. That's my inference, not a GitHub claim.

The false-positive fixes​

All ten changes tighten matching. None adds a new provider pattern.

Why the pairing language matters​

Many cloud credentials come as a pair, such as an ID and a secret. GitHub's docs say that when access needs paired credentials, an alert is created only when both parts appear in the same file. The docs add that pair matching helps cut false positives.

The new filtering applies to a narrow case. An ID-like string turns up. Dictionary filtering then discards every candidate companion secret, perhaps because they look like ordinary words. The ID is now left unpaired, and the detector drops it instead of alerting.

The changelog doesn't say every named credential type always requires a pair. It also doesn't say all partial matches are suppressed. Read the change as a precision tweak.

What GitHub doesn't tell us​

• There are no precision measurements and no estimate of how many alerts will disappear.
• It doesn't say whether existing alerts will be closed or rescanned.
• It gives no rescan schedule for the new Starlink pattern.

So don't promise your security team a drop in alert volume. Expect fewer junk alerts, but watch your own queue to see whether that happens.

What to do​

1. Treat any detected credential as exposed. GitHub's guidance is to rotate it immediately. Scrubbing Git history is time-consuming and often unnecessary once the credential is revoked. Deleting the secret from the latest commit doesn't remove it from history.
2. Check your coverage. Secret scanning runs automatically and free on public repositories. Organization-owned private and internal repositories need GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud. User-owned repositories have separate conditions: Enterprise Cloud with Enterprise Managed Users, or Enterprise Server with Secret Protection enabled.
3. Turn on Secret Protection if you're eligible and it's off. For a repository, open Settings, then Advanced Security under "Security and quality". Next to "Secret Protection", click Enable, review the impact and confirm. Organization owners can apply this at scale with security configurations.
4. Expect history to be covered. GitHub scans history on all branches and periodically rescans repositories when new secret types are added. An old Starlink key in a past commit could therefore still be flagged, though the changelog gives no timing.
5. Don't wait on a partner. A partner notification doesn't mean GitHub has fixed anything for you. Rotate the key yourself.

No configuration change is called for to receive the new detection where secret scanning already applies.

Bottom line​

This is a routine pattern update, and the detector tuning is arguably the more useful half. Fewer UUIDs, placeholders and function names flagged as secrets means developers are more likely to read the alerts that remain. The SpaceX addition extends partner-style revocation to Starlink API credentials. As always, rotating a leaked key is the fix.