Topic starter
19/10/2026 5:39 pm
TL;DR: Truffle Security found that 74% of publicly leaked keys were still live or valid 31 days after exposure, and more than half of secrets removed from GitHub were never rotated. Deleting the file is not revocation, so remediation has to target the credential itself, not just the exposure path.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “74% of publicly leaked keys are never revoked”.
By the numbers:
- 74% of all leaked keys were still live or valid 31 days after they were leaked.
- More than 50% of cases where exposed keys were taken down off GitHub still left the keys live or valid.
Key questions
Q: What breaks when a leaked secret is only removed from the repository?
A: The control fails because file removal does not revoke the credential.
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: What are the signs that a leaked secret has not been remediated properly?
A: A common warning sign is that the exposed file has been removed, but the credential still authenticates successfully.
Practitioner guidance
- Rotate the credential, not just the repository copy Treat every exposed API key, token, or password as valid until the issuing system confirms the value has changed and old copies fail authentication.
- Assign ownership before closing the incident Require a named owner for the leaked secret and make closure contingent on documented revocation or rotation evidence from the system that issued it.
- Check for surviving valid copies Search for the same secret in caches, CI variables, build logs, and duplicated repositories because deleting one public file often leaves other valid copies behind.
Bottom line: Leaked secrets remain an active identity risk until the credential itself is revoked, not merely hidden or deleted from source control.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The 31-day tracking method used to measure whether leaked keys were still valid after exposure
- The difference between unpublishing a file and actually rotating the leaked secret
- How many exposed secrets were still public, still valid, or both at the end of the observation period
- The surrounding Forager and HowToRotate.com context for teams that need remediation workflows
👉 Read Truffle Security's analysis of leaked AWS key validity after exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:39 pm
Secret exposure is not the breach boundary. The breach boundary is the point at which the credential stops authenticating, not the point at which the file disappears. Truffle Security's analysis shows that teams often close the visible exposure while leaving the underlying access path intact. The practitioner implication is that remediation discipline has to be measured in credential state, not repository state.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should teams prioritise rotation or repository cleanup after a secret leak?
A: Rotation should take priority because access risk persists until the secret no longer works. Repository cleanup is still important, but it only reduces exposure. If the credential remains valid, the incident is not fully contained and the attacker may still have a usable path into cloud or application resources.
👉 Read our full editorial: Leaked AWS keys often stay valid after exposure