Topic starter
19/10/2026 5:09 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them.”.
Key questions
Q: What breaks when repository secrets are never recertified?
A: Access drift becomes invisible.
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.
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.
Practitioner guidance
- 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.
Bottom line: Public GitHub repositories can hold secrets that stay valid long after exposure, so discovery by itself does not remove access risk.
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
👉 Read Truffle Security's analysis of live credentials in public GitHub repositories →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:11 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: GitHub repo credentials remain live long after exposure