TL;DR: Truffle Security research found 543,699 unique credentials still authenticating in 224 million public GitHub repositories from The Stack v3, with the median secret sitting in public code for 784 days and the oldest dating to 2009. The core issue is not discovery alone but revocation discipline: push protection blocks some leaks, but it cannot retire the half million already exposed or the many patterns it does not recognise.
At a glance
What this is: Truffle Security reports that hundreds of thousands of credentials exposed in public GitHub repositories were still live when tested, showing that detection without revocation leaves real access in place.
Why it matters: This matters because IAM, PAM, and NHI teams cannot treat repository scanning as a complete control if exposed secrets remain valid for months or years after disclosure.
👉 Read Truffle Security's analysis of live credentials in public GitHub repositories
Context
Public source repositories become an identity problem when credentials are committed into code and remain valid after exposure. That turns a code hygiene issue into a live access-control failure across service accounts, API keys, tokens, and other non-human identities.
The article’s central finding is that secret discovery only reduces risk when it is paired with revocation and replacement. In public code, the relevant control boundary is not whether the secret was seen, but whether the credential still works after it is found.
Key questions
Q: What breaks when repository secrets are never recertified?
A: Access drift becomes invisible. Teams lose track of which workflow still needs a credential, whether the permission scope is still valid, and whether the secret survives after the original use case ends. The result is stale automation that can keep acting long after the business owner has moved on.
Q: Why do public-code secrets create long-term access risk?
A: Public-code secrets are dangerous because repository exposure can last far longer than the original commit event. If the secret is still valid, every copy in forks, mirrors, or cached history can continue to represent active access. The risk persists until the credential is rotated or revoked at the source.
Q: How should teams prioritise exposed credentials for cleanup?
A: Start with the oldest live secrets, the credentials that still authenticate, and the secret types that can reach production systems or cloud control planes. Age, liveness, and privilege scope together give a much better triage order than simply counting how many leaks were found.
Q: Should organisations rely on push protection alone to stop secret exposure?
A: No. Push protection reduces accidental leakage for recognised patterns, but it does not remove secrets already exposed, and it does not cover every credential shape. Organisations still need revocation, rotation, inventory, and recovery processes for anything that reaches public code.
Technical breakdown
Why pushed secrets stay live after detection
A detected secret is only a risk signal until the issuer revokes it. In this dataset, credentials were found in public default branches and then tested against the issuing service, which means liveness depended on the external provider’s lifecycle controls, not on GitHub alone. That is the key mechanism: repository scanning can surface exposure, but it cannot invalidate the credential. When a token, key, or connection string has no downstream kill switch, the exposure remains usable until someone rotates, revokes, or replaces it. Read Guide to the Secret Sprawl Challenge.
Practical implication: Treat secret scanning as discovery, not containment, unless the issuing system can revoke the credential automatically.
Why push protection only covers part of the exposure surface
Push protection is a prevention control for recognised secret shapes at commit time. It blocks some credentials before they reach public code, but only if the pattern is known and only for the data shapes the system is willing to stop. Generic connection strings, private keys, and provider-specific formats outside the block list can still land in repositories. That means the control is shape-dependent, not universal, and its coverage gap is structural rather than accidental. See the API Key Management Guide.
Practical implication: Map which credential formats your controls actually block, then assume everything else can still be committed publicly.
Why secret age is a governance signal, not just a metric
The age of a leaked credential shows how long identity risk can persist when no revocation event occurs. A median age of years, and some values surviving more than a decade, indicates that exposure often outlives the original repository event by a wide margin. For NHI governance, that means lifecycle management is the control plane, not the repository alone. If the credential is still valid, the issue is not historical leakage but current access entitlement. Read Guide to NHI Rotation Challenges.
Practical implication: Use leak age to prioritise revocation queues, because older exposed credentials are evidence of failed lifecycle ownership.
Threat narrative
Attacker objective: Obtain and keep working access to services, APIs, and cloud resources through credentials left in public code.
- Entry occurred when credentials were committed into public GitHub repositories and became available to anyone who could read the code.
- Credential access persisted because many of those secrets were still valid when Truffle Security tested them against the issuing services.
- Impact followed as exposed service accounts, API keys, and tokens remained usable long after the original disclosure, extending the blast radius of each leak.
Breaches seen in the wild
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Revocation, not discovery, is the decisive control. Secret scanning finds exposure, but revocation determines whether that exposure becomes real access. This dataset shows that public code can contain credentials that remain valid long after the repository event, which means the security boundary sits with the issuing system, not the scanner. Practitioners should treat leaked credentials as active identity events until proven otherwise.
Long-lived secrets create identity blast radius. The older a credential remains valid after exposure, the more it demonstrates that lifecycle ownership is broken. A secret committed years ago is not a historical artefact if it still authenticates today; it is an unresolved entitlement. This is why secret age is a governance signal, not just a reporting metric, and why credential lifespan must be managed as an access-control issue rather than a cleanup task.
Push protection is necessary but incomplete. The control blocks only the secret shapes it recognises, so it reduces one class of exposure while leaving broad coverage gaps for other formats. That is not a failure of the mechanism; it is a reminder that prevention alone cannot replace revocation, inventory, and issuer-side lifecycle controls. Static vs dynamic secrets becomes the practical dividing line here.
Provider-side kill switches determine the real survival rate. Tokens that are automatically revoked after leak behave very differently from credentials whose issuers do nothing. That gap explains why some families collapse quickly while others remain live for years. The implication for identity governance is straightforward: if the issuer cannot invalidate a secret, the organisation has outsourced risk containment to history rather than control.
What this signals
Credential revocation has become the governing control plane for public-code exposure. When a secret is live after publication, the security question shifts from whether the leak was detected to whether the issuer can invalidate it immediately. That is the operational difference between an alert and an access-control outcome.
Static secrets are carrying too much residual trust. Public repositories can persist for years, forks can multiply exposure, and default branches can outlive the personnel who created the secret. Programmes that still depend on static credentials need a stronger boundary between code publication and runtime entitlement.
Secret scanning should now be measured by time-to-invalidated, not just time-to-found. If a leaked credential stays active for months, the programme has discovered exposure without reducing it. The useful metric is whether the organisation can close the access path before the secret becomes part of the public record.
For practitioners
- Automate revocation on leak detection Connect secret scanning alerts to issuer-side revocation workflows so exposed credentials are disabled before they continue authenticating.
- Inventory public-code exposures continuously Re-scan repository history and default branches for secrets that predate current protection settings, then prioritise the oldest surviving credentials.
- Separate blocking from invalidation Document which secret formats push protection blocks and which ones still rely on developer hygiene, manual review, or partner revocation.
- Prefer expiring credentials over static keys Where a workload can use short-lived or dynamically issued credentials, replace standing secrets that can survive in code for years.
Key takeaways
- Public GitHub repositories can hold secrets that stay valid long after exposure, so discovery by itself does not remove access risk.
- The evidence in this research points to revocation failure, not merely secret leakage, as the control gap that keeps exposure live.
- Identity teams should treat leaked credentials as current entitlements until they are invalidated, replaced, or expired at the source.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · API Key Management Guide · Secrets Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is about secrets exposed in public code and whether they remain live after discovery. |
| NHI-07 — Long-Lived Secrets | The research shows exposed credentials surviving for years without rotation or expiry. | |
| Recommendation — Treat leaked repository secrets as compromised and revoke them at the source immediately. Replace static credentials with short-lived alternatives wherever a workload can support them. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs the lifecycle of authenticators, including rotation and invalidation after exposure. |
| Recommendation — Enforce authenticator rotation and revocation workflows for every leaked secret. | ||
| CIS Controls v8 | CIS-5 — Account Management | Leaked service credentials remain active accounts unless account lifecycle is managed correctly. |
| Recommendation — Audit account and token lifecycle processes so exposed credentials are disabled without delay. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is the continued usability of credentials after exposure in public repositories. |
| Recommendation — Map exposed secrets to credential-access scenarios and hunt for downstream misuse. | ||
Key terms
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
- Static Secret: A secret, such as an API key or password, that does not change automatically over time. Static secrets require manual or scheduled rotation and represent a higher security risk than dynamic secrets or managed identities.
- Push Protection: Push protection is a preventive control that blocks some secrets from being committed to public repositories. It reduces accidental exposure during development workflows, but it is not a complete safeguard across all Git-based surfaces. Coverage gaps matter, especially where content can still be published outside the protected path.
What's in the full report
Truffle Security's full research covers the operational detail this post intentionally leaves for the source:
- The full methodology for scanning 224,553,295 repositories and verifying liveness against issuing providers
- Family-by-family survival data showing which credential types still authenticate and which are rapidly revoked
- The provider-side revocation comparison that separates blocking at commit time from invalidation after exposure
- The dated exposure analysis that explains how some credentials remained live for years after publication
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org