Topic starter
19/10/2026 5:09 pm
TL;DR: Truffle Security's analysis of public repositories used to train AI models finds 543,699 credentials still authenticated, with a median exposure period of more than two years and the oldest dating back to 2009. Teams need revocation and re-verification, because removing a secret from a file does not prove the underlying access is gone.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Why exposed credentials stay live for years”.
Key questions
Q: Why do exposed credentials remain dangerous even when they are old?
A: Because age does not reduce validity.
Q: How do security teams know if exposed secrets are becoming a real risk?
A: The clearest signal is whether the secret can still authenticate and whether it can reach high-value actions after login.
Q: How should security teams monitor for exposed credentials before attackers use them?
A: Security teams should treat credential breach monitoring as a continuous control, not a one-time check.
Practitioner guidance
- Define exposed-secret remediation as revoked and re-verified Do not close a finding when the repository copy is removed.
- Map every exposed credential to its owning NHI Record the service, workload, API, or AI workflow behind each secret so responders know which system can actually revoke it and what access the credential reaches.
- Separate discovery from invalidation in your workflow Treat detection, validation, revocation, and post-revocation testing as distinct steps so a finding does not move to closed before access is actually removed.
Bottom line: The core risk is not exposure alone, but exposed credentials that remain valid long after they are discovered.
Glossary terms: Exposed Credentials, Credential Revocation, Secrets Sprawl, Credential Lifecycle
What's in the full report
Truffle Security's full research covers the operational detail this post intentionally leaves for the source:
- The repository-level analysis method behind the 543,699 still-authenticating credentials
- The verification workflow used to distinguish live secrets from inactive findings
- The revocation and re-check sequence needed to prove remediation actually removed access
- The cross-environment exposure patterns spanning code, CI/CD, SaaS, cloud, and AI workflows
👉 Read Truffle Security's analysis of why exposed credentials stay live for years →
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
Detection is not the control, revocation is. Secret scanning creates awareness, but the risk persists until the credential stops authenticating. That distinction matters because many security programmes still measure discovery volume rather than confirmed invalidation. The practical boundary is simple: if a credential can still log in, the exposure is still active. The implication is that exposed-secret governance must be judged by outcome, not by alert count.
A few things that frame the scale:
- 54% of ransomware victims had credentials exposed before the attack, according to Verizon's 2025 Data Breach Investigations Report.
A question worth separating out:
Q: Should organisations prioritise short-lived credentials over legacy tokens?
A: Yes, when the platform supports both. Short-lived credentials reduce the duration of misuse and force periodic re-validation, while legacy long-lived tokens tend to persist until someone notices them. The right sequencing is to shrink standing access first, then tighten review and revocation around whatever remains.
👉 Read our full editorial: Exposed credentials persist for years without verified revocation
This post was modified 3 days ago by NHI Mgmt Group