Overview
Security researchers have identified 543,699 unique credentials that remained active after appearing in public GitHub repositories, highlighting a persistent weakness in how organisations manage secrets throughout their lifecycle. The research analysed a large snapshot of public GitHub code originally assembled for AI training and then tested discovered credentials against the services that issued them. Some credentials had remained valid for years after exposure, demonstrating that publishing a secret is only the beginning of the security problem. The greater risk emerges when exposed credentials are detected but never revoked.
A Secret Does Not Become Safe When It Is Deleted
One of the most important lessons from the research is that removing a credential from a repository does not invalidate it. Once a secret has appeared publicly, automated scanners, attackers, search engines or data-collection systems may already have copied it. Deleting the file, rewriting Git history or removing the credential from the latest branch can reduce future visibility, but the original credential may continue providing access until it expires or is explicitly revoked. This creates an important distinction between repository remediation and credential remediation. Cleaning the repository addresses the exposure location. Rotating or revoking the credential closes the actual access path.
Prevention Helps, but Coverage Matters
GitHub provides secret scanning and push protection designed to identify supported credentials before they reach public repositories. These controls have clearly reduced the rate at which recognised credential formats are published. However, secret detection depends on knowing what a credential looks like. Database connection strings, private keys, internally generated credentials and certain API keys may not always match recognised patterns. Developers can also bypass some push-protection warnings where permitted. This means secret scanning should be treated as one layer of defence rather than the complete secrets-management strategy.
Long-Lived Credentials Increase the Blast Radius
The research identified live credentials linked to cloud platforms, databases, APIs and service accounts. These credentials can become particularly dangerous when used by automated systems because they may operate continuously without interactive authentication or regular human review. A long-lived service credential committed several years ago may still have access to infrastructure that has evolved significantly since it was created. Cloud architectures increasingly benefit from short-lived identities, managed identities, workload federation and dynamically issued tokens because they reduce the value of a credential that is accidentally exposed. The longer a credential remains valid, the longer an attacker potentially has to discover and abuse it.
Secret Management Requires a Lifecycle
Effective secret management begins before code is committed and continues after a credential is issued. Repositories should be protected with secret scanning and push controls, but organisations should also maintain centralised secrets management, restrict credential scope, monitor credential usage and automate rotation wherever possible. An exposed credential should be treated as compromised immediately. Revocation should occur before repository cleanup, followed by investigation of associated systems to determine whether the secret was used unexpectedly.
Expert in the Cloud Insight
The significance of more than half a million active exposed credentials is not simply that developers accidentally committed secrets. It demonstrates a broader governance problem:
organisations are often better at detecting leaked credentials than completing the final step of invalidating them.
Security controls can identify a secret. GitHub can warn that it has been committed. Monitoring platforms can generate an alert. None of those actions automatically guarantee that the credential can no longer be used. This makes revocation and expiration critical parts of modern identity architecture. Detection tells an organisation that a door has been left open. Revocation is what actually closes it.
Leave a Reply