Topic starter
19/10/2026 5:09 pm
TL;DR: Truffle Security's analysis of 224 million public GitHub repositories from The Stack v3 finds 543,699 unique credentials were still authenticating, with a median age of 784 days and the oldest dating to 2009. Teams need revocation and rotation, because detection alone leaves real access in place.
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: 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.
Q: What breaks when repository secrets are never recertified?
A: Access drift becomes invisible.
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.
Glossary terms: Secrets Leakage, Credential Revocation, Static Secret, Push Protection
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 →
This topic was modified 3 days ago 2 times by NHI Mgmt Group
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
This post was modified 3 days ago by NHI Mgmt Group