GitHub’s secret scanning now includes built‑in validators for MongoDB, Meta (Facebook), and multiple Microsoft Azure token types, expanding the service’s ability to tell you not just that a secret was leaked but whether that secret is still usable — a capability that meaningfully changes how development teams triage and remediate exposed credentials.
Secret scanning has long been one of the highest‑leverage features in modern code security: automated detection of API keys, tokens, connection strings, and other sensitive strings in repositories reduces the window between accidental exposure and exploitation. For months GitHub has been extending secret scanning from detection toward validation — contacting the issuer or otherwise checking whether a leaked secret is actually active and therefore an immediate risk.
On September 30, 2025 GitHub announced another expansion of those validation checks. The platform added automatic validity checks for a set of new token patterns, specifically:
That said, validity checks are a tool — not a silver bullet. Organizations must weigh privacy and data‑residency tradeoffs, maintain strong secret hygiene, and integrate validity checking into a broader program of automated rotation, least privilege, and incident response. When implemented thoughtfully, however, validity checks dramatically improve the economics of secrets management: fewer false alarms, faster fixes, and better protection for the systems teams build and maintain.
Source: The GitHub Blog Secret scanning adds validators for MongoDB, Meta, and Microsoft Azure - GitHub Changelog
Background / Overview
Secret scanning has long been one of the highest‑leverage features in modern code security: automated detection of API keys, tokens, connection strings, and other sensitive strings in repositories reduces the window between accidental exposure and exploitation. For months GitHub has been extending secret scanning from detection toward validation — contacting the issuer or otherwise checking whether a leaked secret is actually active and therefore an immediate risk.On September 30, 2025 GitHub announced another expansion of those validation checks. The platform added automatic validity checks for a set of new token patterns, specifically:
- Azure: microsoft_ado_personal_access_token, microsoft_azure_apim_repository_key_identifiable, microsoft_azure_maps_key, microsoft_azure_entra_id_token
- Meta: facebook_very_tiny_encrypted_session
- MongoDB: mongodb_atlas_db_uri_with_credentials
Why validity checks matter
From volume to signal
Secret scanning by itself reduces risk by surfacing exposures, but it often produces many stale or already‑revoked secrets. Validity checks convert noisy detection into prioritized action:- High‑signal triage: Alerts marked Active indicate credentials that an attacker could use right now — the ones you should remediate first.
- Faster response: Knowing a secret is active removes time‑consuming verification steps (trying the credential, contacting the provider, or assuming the worst).
- Automation-friendly: Automated pipelines can filter and escalate only Active secrets to rotation/playbooks, reducing human overhead.
Practical consequences for teams
Security teams and developers both benefit. Developers spend less time chasing false alarms; SecOps can run targeted rotations and incident playbooks; managers get better metrics on “time‑to‑neutralize real risk” instead of noise.What GitHub added — the new validators explained
The new validators added on September 30 extend the set of partner and provider patterns that GitHub will actively check. Here’s what each new pattern means in practice and why it matters.Microsoft Azure token patterns
- microsoft_ado_personal_access_token (Azure DevOps PAT): Azure DevOps personal access tokens grant a range of permissions on repositories, pipelines, artifacts, and more. If a PAT with broad scopes is leaked and shows as Active, it can allow an attacker to read private repos, trigger or tamper with pipelines, or access organization resources tied to Azure DevOps.
- microsoft_azure_apim_repository_key_identifiable (APIM repo key): Azure API Management repository keys (used for repository integration or template updates) may allow modification of API configurations or deployment artifacts.
- microsoft_azure_maps_key: Azure Maps API keys provide access to mapping, geocoding, and routing APIs. Active keys could be abused for high‑volume API use, incurring cost or exposing location‑sensitive data.
- microsoft_azure_entra_id_token (Entra ID token): Tokens issued by Microsoft Entra ID (formerly Azure AD) are identity tokens that can indicate authenticated sessions or federated access; active identity tokens could be used to impersonate sessions or validate credentials against provider debug endpoints.
Meta (Facebook) session token pattern
- facebook_very_tiny_encrypted_session: This pattern name reflects a specific, compact session token format used by Facebook/Meta SDKs and session mechanisms. Session tokens and “session info” tokens are typically used to track logged‑in state; if active, they can be used to impersonate users or validate sessions against the platform’s debug endpoints.
MongoDB Atlas connection URIs
- mongodb_atlas_db_uri_with_credentials: A MongoDB Atlas connection string that includes credentials (username
assword@host) gives direct, programmatic access to a database instance. If the URI is active and points to a production cluster, an attacker may be able to read or modify data immediately.
How validity checks work (technical details and limits)
- GitHub’s secret scanning identifies strings that match supported provider patterns. For patterns configured for validity checks, GitHub will securely send the token (or derived identifier) to the token provider or validation endpoint to confirm whether it’s active.
- The resulting validity status is generally one of: Active, Inactive, or Unknown. Unknown indicates the check couldn’t confirm (provider unavailability, throttling, or unsupported token version).
- Validity checking is an opt‑in capability in repository/org settings — organizations can enable automatic verification from the Code security and analysis settings (the checkbox labeled to automatically verify if a secret is valid).
- Webhooks and APIs reflect validity: secret scanning webhooks include a validity property and lifecycle actions (for example, a
validatedaction when status changes). - Validity checks are conducted on a cadence; closed alerts may still be rechecked automatically so formerly closed leaks can be re‑flagged if they become active again.
- Validity checks do not revoke or rotate secrets on behalf of the user; they only report status. Remediation (rotate/revoke) remains the user’s responsibility or must be automated separately.
- Not all supported scan patterns have validity checks; the set is growing and depends on integrations with token issuers.
- Some validations are performed via partner integrations rather than by GitHub itself, which may involve transmitting tokens to provider endpoints.
Benefits: what teams stand to gain
- Prioritized remediation: Triage becomes evidence‑driven. Active secrets move to the top of the queue.
- Reduced human toil: Less manual verification and fewer wasted investigations into stale keys.
- Better metrics: Teams can measure meaningful time‑to‑remediate for live credentials.
- Programmatic response: Automated systems can act differently on Active vs Unknown (e.g., immediate rotation vs scheduled verification).
- Wider coverage: Adding Azure, Meta, and MongoDB targets common and high‑impact secret types found in many modern projects.
Risks, tradeoffs, and blind spots
No security control is risk‑free. Validity checks improve signal, but they also introduce new operational and privacy considerations that teams must understand.1. Privacy and data residency concerns
Validity checks require sending secrets (or secret identifiers) to external validation endpoints — sometimes run by third parties or providers located outside a given jurisdiction. For organizations with strict data residency or compliance requirements, that transmission may be a policy blocker unless governance, contracts, or data‑processing agreements are in place.- Mitigation: Review organizational security policy before enabling automatic validation at the enterprise level; use repository‑level opt‑in where possible; rely on on‑demand verification for more control.
2. Exposure risk during validation
Any system that transmits secrets must protect them in transit and at rest. While providers design validation endpoints to minimize risk, organizations should evaluate the provider‑level guarantees about how the data is handled.- Mitigation: Use organizations’ security assessments, require encryption in transit, and favor providers with clear handling policies. Enable validation only for repositories where the team accepts the tradeoff.
3. False negatives and unknown status
Validity checks can return Unknown for multiple benign reasons: provider rate limiting, token type not supported yet, or network errors. Unknown must be treated as “potentially active” until proved otherwise.- Mitigation: Treat Unknown alerts as requiring follow‑up; implement a playbook to retry verification and consider rotation for sensitive tokens.
4. Reliance on provider APIs and throttling
Validation depends on the availability and semantics of provider APIs. Providers can change behavior, throttle checks, or even deprecate endpoints, which may affect GitHub’s ability to verify tokens.- Mitigation: Don’t assume validation is infallible. Combine validation data with internal logs, IAM audit trails, and usage telemetry.
5. False sense of security
An Inactive status is useful, but it is not a permanent guarantee. Tokens can be reissued, rotated back, or otherwise become exploitable after an initial Inactive report.- Mitigation: Maintain strong secret hygiene: rotate secrets by policy, remove long‑lived static keys where possible, and ensure logs/alerting capture suspicious access attempts.
Operational checklist: how to integrate validity checks into your security process
- Enable secret scanning for repositories and organizations that should be covered.
- Enable the “Automatically verify if a secret is valid” option in Code Security & Analysis settings where policy permits.
- Filter secret scanning alerts by validity status:
- Triage Active immediately.
- Treat Unknown as “potentially active” and queue for follow‑up verification.
- Flag Inactive for lower‑priority review but schedule periodic rechecks for high‑value keys.
- Immediately rotate or revoke any Active credential and update any dependent systems.
- After rotation, trigger on‑demand verification to confirm remediation — use webhooks or the UI to validate the secret was neutralized.
- Automate playbooks where possible:
- Use the secret scanning API and webhooks to create an automated remediation flow.
- Block commits with push protection for high‑confidence patterns.
- Maintain a secrets inventory and enforce short lifetimes and least privilege for tokens.
- Apply network and IAM controls (restrict IP ranges, apply conditional access, bind tokens to specific scopes).
- Audit and log all remediation steps for compliance and post‑mortem analysis.
Developer guidance: minimizing leaks and their impact
- Use secret management (vault services, cloud provider secret stores, GitHub Secrets, or CI secret stores) instead of embedding credentials in code.
- Adopt short‑lived tokens and workload federation (e.g., OIDC for federated identity) so leaked tokens expire fast and can’t be reused.
- Restrict scopes and roles assigned to tokens; avoid broad PATs that cover multiple services.
- Scan pre‑commit and in CI: run local and CI checks (gitleaks, pre‑commit hooks, server‑side scanning) to catch leaks before they reach the central repository.
- Educate teams about the danger of pasting credentials into source, test logs, or screenshots.
Legal and compliance considerations
- Review agreements and data‑processing policies. Validity checks that send secrets to third‑party endpoints may require explicit legal review for regulated industries (healthcare, finance, government).
- For organizations with restrictive data residency controls, use repository‑level opt‑in or disable automatic validation where necessary.
- Maintain clear evidence trails: which tokens were checked, who validated or rotated them, and when remediation occurred.
What this does — and what it doesn’t do
- It does: reduce triage time, highlight live threats, grow the set of validated token types, enable automated prioritization, and integrate with existing GitHub workflows (alerts, webhooks, push protection).
- It doesn’t: automatically revoke tokens, replace the need for rotation and secrets best practices, or remove the requirement for organizational policy review before sharing tokens externally.
The broader picture: why providers partnering on validation matters
Validation requires provider cooperation: GitHub needs a safe, reliable way to ask the token issuer whether a supplied secret is active. That cooperation accelerates detection → triage → remediation at scale and reflects a broader industry push to make secret handling less error‑prone.- Providers get faster notification when their tokens appear in public code.
- Developers get higher‑signal alerts instead of triage by guesswork.
- Enterprise security teams get operational metrics that measure real risk reduction.
Implementation tips for security teams
- Start small: Enable automatic validation for non‑sensitive repos or enable on‑demand verification until you’ve validated provider handling and set internal policy.
- Establish clear playbooks: for each validity state (Active, Unknown, Inactive) define the immediate actions, owner, and SLA for remediation.
- Use push protection: for high‑risk token types, enable push protection so commits containing those patterns are blocked before being pushed.
- Instrument and measure: track time to rotate Active secrets, number of Unknowns per week, and false positive rates — these metrics tell you whether the validity program is reducing risk.
- Communicate to developers: include quick how‑tos on rotating common tokens (Azure PATs, MongoDB URIs, Facebook session info), and keep a repository of rotation commands and automation scripts.
A few edge cases and technical caveats worth calling out
- Some tokens are multi‑part or require pair matching (key ID + secret) for detection. If part of a pair is missing, validity checks may be limited or return Unknown.
- Non‑provider patterns (generic connection strings, private keys) may be detected by secret scanning but currently do not always support validity checks because no external validation endpoint exists.
- Providers may change token formats; GitHub updates pattern versions periodically. Teams should not assume a pattern's behavior is static — revalidate detection rules after major provider changes.
- Rate limiting or provider outages can cause temporary spikes in Unknown statuses; correlate with provider status pages and retry logic.
Conclusion
Expanding secret scanning’s validity checks to include MongoDB Atlas URIs, Facebook session tokens, and multiple Microsoft Azure token types is a meaningful step forward for prioritizing real risk in modern development environments. The capability shifts remediation from a reactive scramble through noisy alerts to a focused program of rapid rotation and policy enforcement for live credentials.That said, validity checks are a tool — not a silver bullet. Organizations must weigh privacy and data‑residency tradeoffs, maintain strong secret hygiene, and integrate validity checking into a broader program of automated rotation, least privilege, and incident response. When implemented thoughtfully, however, validity checks dramatically improve the economics of secrets management: fewer false alarms, faster fixes, and better protection for the systems teams build and maintain.
Source: The GitHub Blog Secret scanning adds validators for MongoDB, Meta, and Microsoft Azure - GitHub Changelog
