Topic starter
06/11/2026 6:38 pm
TL;DR: Truffle Security reports that it has confirmed 1.4 million live API keys leaked across GitHub, Docker Hub, npm, Hugging Face and other sources, while 81% of the keys it reported last year still worked six months later. Notification alone is not an adequate control when leaked secrets remain valid long after discovery.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Introducing the Secrets Revocation Program: revoking 1.4 million live API keys”.
By the numbers:
- 81% of the keys reported last year still worked six months later.
Key questions
Q: What should teams do first when they find an API key in source code?
A: Treat the discovery as a live credential incident, not a code defect.
Q: Why does a leaked API key remain dangerous after the code is removed?
A: A leaked key stays dangerous because copies can persist in forks, clones, package mirrors, commit history, and other downstream systems outside your control.
Q: How should teams scan for exposed secrets across software supply chains?
A: Teams should scan source code, build artefacts, container images, dependency manifests, logs, object storage and CI/CD outputs for exposed secrets such as API keys, tokens and certificates.
Practitioner guidance
- Make revocation the default response Define a standing process where every verified leaked API key is disabled at the issuer before any notification workflow is considered complete.
- Map issuer-side kill paths Document which systems can disable keys immediately, which require manual intervention and which have no external revocation path at all.
- Extend scanning beyond source control Include container images, package registries, AI tool configs and datasets in the same leak detection and response workflow.
Bottom line: Leaked API keys are still active identities until the issuer disables them, so discovery alone does not remove the risk.
What's in the full report
Truffle Security's full post covers the operational detail this analysis intentionally leaves for the source:
- How the Secrets Revocation Program handles issuer-side revocation requests and webhook delivery
- The scan sources and detection pipeline behind the 1.4 million live key count
- The empirical comparison between notification-only handling and automatic disabling
- Examples of participating issuers and the onboarding model for the revocation programme
👉 Read Truffle Security's analysis of revoking leaked API keys at source →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Leaked API key exposure is an offboarding failure, not just a detection failure: once a secret is public, the real question is whether the issuer can reliably invalidate it before reuse. Truffle Security's data shows that many reported keys remain live long after disclosure, which means discovery alone does not close the identity risk. The practitioner conclusion is simple: revocation is the control boundary, not notification.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do organisations know whether their secrets governance is actually working?
A: Look for fewer identities with decrypt rights, fewer hardcoded credentials in code and state, and clear evidence that retired workloads can no longer access secret paths. If secret use still depends on manual exceptions or shared automation roles, governance is present in theory but not in practice.
👉 Read our full editorial: Revocation, not notification, is the real control for leaked API keys