Security teams have more ways than ever to catch exposed credentials. So why are so many of them still working years after they leak?
In our analysis of 224 million public repositories used to train AI models, we found 543,699 credentials that still authenticated. The median had been exposed for more than two years. The oldest had been sitting in public code since 2009.
Every one of those credentials was sitting somewhere anyone could find it. Most of the organizations they belong to still don’t know.
And this isn’t the first time we’ve seen it. When we tracked more than 22,000 verified secrets across Bitbucket and GitLab, more than 80% were still live months after exposure.
The problem isn’t that secret scanning doesn’t work. It’s that finding an exposed credential is only one step toward removing the risk.
Detection alone doesn’t guarantee any of the things that actually reduce risk. A credential can be flagged and never rotated, scrubbed from a repository and still authenticate, or sit in a queue while no one can say who owns it or what it reaches.
Because of this, the gap between finding an exposed credential and proving it has been revoked is where secrets programs need to evolve.
Prevent what you can. Find what gets through.
Preventive controls reduce the number of credentials that become exposed in the first place. In our recent analysis of public repositories, the rate at which credential types covered by default push protection fell by roughly half after the control was enabled.
But credentials still get through, whether they fall outside the coverage of preventive controls or were exposed before those controls existed. And the secrets tied to non-human identities (NHIs) extend beyond source code into CI/CD systems, SaaS applications, cloud environments, collaboration tools, developer workstations, and AI workflows.
Know which credentials still work
Finding something that looks like a secret doesn’t tell you whether it represents active exposure. It could be an example value, a credential revoked years ago, or something an attacker could use right now. Verification answers the question that matters: does the credential still work? By testing it against the service that issued it, teams can distinguish inactive findings from credentials that still provide access.
Knowing which credentials still work helps teams focus on active exposure. But it leaves another question unanswered: what can the credential actually access?
Understand the access behind the credential
A live credential tells you there’s active exposure, but not what that exposure means. One credential might reach a test environment, while another could provide access to production infrastructure, sensitive data, or additional systems. Understanding the NHI behind the credential, including its owner, permissions, and accessible resources, gives security teams the context to assess its impact and take action.
That context becomes even more important as more secrets belong to NHIs, such as workloads, services, and AI agents, rather than individual people. Recent NIST guidance on protecting tokens and assertions emphasizes verification and lifecycle management, including the use of short-lived credentials for workload identities.
Without this context, even a verified credential can require additional investigation to understand what it can access and who needs to remediate it.
Removing the secret doesn’t remove the access
Deleting a repository, overwriting a file, or rewriting Git history can remove a secret from where it was found without revoking the underlying credential. All it does is make the exposure look resolved, when in reality the key is still exposed and still granting access.
Revocation is what removes the access. Until the exposed credential is revoked, remediation isn’t complete, regardless of whether the secret has been removed from where it was found.
But revocation also needs to be verified, because closing a ticket, merging a PR, or marking a finding as resolved doesn’t prove the credential can no longer authenticate. Re-verifying the credential confirms that remediation actually removed the access and the exposed credential can no longer be used.
The person who leaks a credential usually can’t revoke it
Revocation requires access to the service that issued the credential. The developer who committed a key to a public repository often isn’t the person who created it, and the researcher or scanner who finds it almost never is. That mismatch is why so many credentials in public sources stay live: everyone who can see the exposure lacks the ability to act on it, and the party who can act doesn’t know it happened.
At the scale of the public internet, this isn’t something individual organizations can solve one credential at a time. The services that issue credentials are the only ones positioned to revoke them, and they’re the ones with the most to lose when their customers’ keys stay valid in public.
Build around the outcome
A secrets program shouldn’t end at detection. Finding an exposed credential starts the process, but reducing risk requires knowing whether it’s active, understanding the access behind it, and making sure that access is removed. That means building a secrets program around the full lifecycle of an exposed credential:
Prevent credentials from leaking where possible.
Detect and verify exposures across the environments where secrets live, separating active credentials from those that no longer work.
Understand the NHI behind each credential, including its ownership, permissions, and access.
Remediate and confirm by getting the credential revoked and re-verifying that it no longer authenticates.
This works inside an environment you control. Exposure that reaches public sources needs a different path, and it runs through the providers who issued the credentials in the first place.
Together, these steps move the focus from finding secrets to eliminating the access they expose. The goal is to reduce the time from exposure to verified revocation. For credentials exposed in public, that clock only stops when the issuer acts, and we think that’s where the next meaningful reduction in live exposed credentials comes from.
