GitHub Secret Scanning Adds SpaceX, Upgrades Six Detectors

On November 5, 2026, GitHub published a changelog update titled "Secret Scanning Update" that does two things: it adds SpaceX as the newest member of GitHub's secret scanning partnership program, with a dedicated detector for Starlink's public API v2 client secret, and it tightens the matching logic on six existing detectors — Alibaba Cloud, AWS, Google Cloud Storage, OpenVSX, Pydantic Logfire, and Tencent Cloud — to cut down on false-positive alerts. The SpaceX addition is not a new banner or alert in anyone's repository; when GitHub's scanners find an exposed Starlink secret in a public repo, they report it silently and automatically straight to SpaceX, the same way they already do for dozens of other partner secret types.

What GitHub announced on November 5

GitHub's own changelog entry lays out two unrelated but related changes under one "Secret Scanning Update" headline. The first is a new partner: SpaceX has joined the secret scanning partner program, and GitHub now ships a detector for the secret type starlink_public_api_v2_secret — a client secret used with Starlink's public API v2. The second is a maintenance pass: GitHub tightened the pattern and context matching used by six existing detectors, spanning ten distinct secret-type strings listed on GitHub's page of supported secret scanning patterns, specifically to reduce false positives rather than to add new coverage.

Both changes are described by GitHub as improvements to application security tooling, not new products or plans. Nothing about pricing, the Security and quality tab's UI, or GitHub Copilot changes here — this is purely about which secrets GitHub's scanners recognize and how precisely they recognize them. For context, this update lands the same week GitHub shipped Copilot inside Xcode's native coding assistant — part of a broader run of developer-experience and security updates GitHub has been pushing through its changelog this quarter.

A quick primer: how secret scanning and the partner program actually work

Secret scanning is a GitHub feature that scans a repository's entire Git history across all branches, plus issues, pull request text, Discussions, wikis, and secret gists, looking for patterns that match known credential formats — API keys, tokens, passwords, and similar hardcoded secrets. According to GitHub's own documentation, public repositories are scanned automatically and at no cost; private and internal repositories owned by an organization require GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud, while user-owned repositories need Enterprise Cloud with Enterprise Managed Users, or Enterprise Server with Secret Protection enabled. When a match is found in a context where GitHub shows alerts, it appears under that repository's Security and quality tab, and GitHub's guidance is to rotate the affected credential immediately rather than spend time scrubbing it out of Git history.

The partner program is a separate, narrower mechanism layered on top of that scanning engine. Any service provider — a cloud vendor, a SaaS company, now SpaceX — can work with GitHub to register a secret-type pattern (ideally with a unique prefix, high entropy, and a checksum), a test account, and an HTTP endpoint. GitHub's documentation on the partner program explains that once a provider is onboarded, matches found in public sources — public repositories and public npm packages — are sent automatically to that provider's endpoint as a signed JSON payload containing the token, the secret-type name, and where it was found. The partner is expected to treat anything GitHub reports as public and compromised, which in practice means revoking the credential and notifying the affected customer. Partners can also send GitHub a true-positive or false-positive label back, which is part of how GitHub tunes detectors over time — the same kind of feedback loop that produced this week's false-positive fixes.

Crucially, that partner-reporting path is distinct from the end-user alerts most developers are used to. For a secret type covered by the partner program, a match in a public repository goes straight to the partner and does not generate a visible alert for the repository owner. The behavior changes in private repositories: there, repository admins and the person who committed the secret are alerted on GitHub as usual, and the partner is not notified. GitHub's reference documentation on supported secret scanning patterns also tracks, detector by detector, whether push protection — the feature that can block a push containing a matching secret before it ever reaches a branch — is enabled for that pattern, which is a separate layer from partner reporting.

What the SpaceX addition means in practice

With SpaceX now a partner, any public GitHub repository, or public npm package, containing a string that matches the starlink_public_api_v2_secret pattern gets flagged by GitHub's scanner and reported directly to SpaceX's endpoint — automatically, continuously, and without the repository owner necessarily knowing it happened. That's the operative detail here and it's worth repeating plainly: this is not a pop-up, a Security tab entry, or an email to the developer who leaked the credential. It's GitHub acting as a silent intermediary so SpaceX can revoke or rotate the Starlink API secret on its own side before it's abused, the same workflow AWS, Google, Alibaba, Tencent, and dozens of other partners already rely on for their own secret types.

Practically, that means a developer building against Starlink's public API v2 — for telemetry, fleet management, or other integrations — who accidentally commits a client secret to a public repo should assume GitHub has already told SpaceX about it, and should still rotate the credential themselves rather than relying on SpaceX's side of that handoff as the only safety net. If the same secret ends up in a private or internal repository instead, the partner program's public-source trigger doesn't apply, and GitHub falls back to its ordinary alerting: admins and the committer get notified through the Security and quality tab, and SpaceX is not looped in.

The six detectors that just got more accurate

The second half of the update has nothing to do with new coverage — it's about precision. GitHub tightened the matching logic for six existing detectors covering ten secret-type strings, all aimed at reducing false positives that otherwise clutter the Security and quality tab and the partner feedback loop. The pattern across most of these fixes is the same idea: stop flagging a "key ID" or token-shaped string as a secret when the companion value it would normally pair with has already been filtered out as unlikely to be real.

Two threads run through this list. The AWS, Alibaba Cloud, and Google Cloud Storage fixes are all variations of the same "unpaired match" problem: these providers' credentials typically come in pairs — an access key ID alongside a secret key, for instance — and scanners have historically flagged the ID half even when nothing resembling the paired secret appears nearby. GitHub's fix suppresses those lone-ID matches once its dictionary filtering has already ruled out the companion value. The OpenVSX, Logfire, and Tencent Cloud fixes instead narrow the pattern or context rules directly — requiring a mix of letters and digits, excluding known placeholder strings, or ignoring UUIDs that show up in unrelated contexts.

Why false-positive fixes matter beyond annoyance

False positives are not just noise. Every alert that lands in the Security and quality tab competes for a security team's attention, and a scanner that regularly cries wolf on Alibaba Cloud key IDs or Tencent Cloud identifiers trains teams to triage secret-scanning alerts more slowly — exactly the opposite of what the feature is supposed to encourage. On the partner side, false positives are worse: GitHub's partner program is built around providers treating every report as "public and compromised" and reacting accordingly, so a detector that fires on non-secrets forces partners to run needless revocation and customer-notification workflows, or to start discounting GitHub's reports altogether. Tightening pattern and context matching on six established detectors is the unglamorous maintenance work that keeps both halves of the system — developer-facing alerts and partner-facing automatic reporting — trustworthy enough to act on immediately, which is the entire point of secret scanning.

Where this fits in GitHub's security roadmap

This update arrives in the same stretch of changelog activity where GitHub has been shipping a string of developer-experience and security changes, including the default blocking of risky pull_request_target workflows starting December 2 and the general availability of GitHub in Slack and Teams. None of those are the same feature as secret scanning, but together they point at the same instinct: GitHub is spending more of its changelog real estate on the mechanics that keep code and credentials safe by default, rather than only on headline AI features. SpaceX joining the partner program is also notable simply as a signal of who's opted in — the roster already includes major cloud providers, and adding an aerospace and satellite-internet company suggests the program's reach is widening past the usual developer-tooling and cloud-infrastructure names.

What happens next

For most developers, nothing changes operationally — secret scanning keeps running the same way it always has, and the detector upgrades are invisible unless a team had been seeing (or relying on being warned by) false positives from one of the six affected providers. Anyone integrating with Starlink's public API v2 should treat the new starlink_public_api_v2_secret detector as a reason to double-check that client secrets aren't committed to public repositories at all, rather than leaning on GitHub-to-SpaceX reporting as a backstop. Organizations that rely on any of the ten upgraded secret types should expect fewer, more accurate alerts going forward, but GitHub's changelog doesn't indicate any action is required on the user side — these are server-side detector changes, not settings to configure. Teams that want tighter guarantees than default scanning can enable push protection on their repositories or organizations and consider GitHub's free secret-scanning assessment for an initial read on what's already exposed.

Frequently asked questions

What is GitHub's secret scanning partner program?

It's a program where service providers register their own secret-type patterns with GitHub so that matches found in public repositories and public npm packages are reported automatically and directly to the provider, rather than only appearing as a user-facing alert.

Will I get an alert if a SpaceX secret is exposed in my repository?

If it's a public repository, no — the match is sent straight to SpaceX so it can revoke or rotate the credential, and it won't show up in your Security and quality tab. In a private or internal repository, GitHub alerts the repository admins and the committer as it normally would, and SpaceX is not notified.

What is the new secret type GitHub can detect for SpaceX?

starlink_public_api_v2_secret, a client secret used with Starlink's public API v2.

Which six detectors were upgraded to reduce false positives?

Alibaba Cloud, AWS (covering three AWS secret types), Google Cloud Storage (covering three secret types), OpenVSX, Pydantic Services Inc.'s Logfire token, and Tencent Cloud.

Does GitHub charge for secret scanning?

Public repositories are scanned automatically at no cost. Private and internal repositories owned by an organization need GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud; user-owned repositories need Enterprise Cloud with Enterprise Managed Users, or Enterprise Server with Secret Protection enabled.

How does a company become a GitHub secret scanning partner?

By emailing [email protected] to start enrollment, agreeing to GitHub's terms, and providing a unique secret-type name, a detection regex, a test account, and an endpoint URL that can accept signed POST requests and handle revocation and user notification.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage