TL;DR: Truffle Security reports that scanning roughly 5.6 million public GitLab repositories produced 17,430 verified live secrets, including 406 GitLab keys, and the density was higher than in Bitbucket, showing that secrets persist where governance never catches up. Credential lifecycle, not discovery alone, is the real control gap.
At a glance
What this is: A large GitLab secrets scan found 17,430 verified live secrets across about 5.6 million public repositories, with 406 GitLab keys and a higher leak density than Bitbucket.
Why it matters: Identity and security teams need to treat public code, leaked tokens, and credential lifecycle as one governance problem because discovery without revocation still leaves standing exposure.
By the numbers:
- The scan found 406 valid GitLab keys in GitLab repositories, according to Truffle Security research.
- The earliest valid secret the research found dated to 2009-12-16, according to Truffle Security research.
👉 Read Truffle Security's analysis of GitLab secret sprawl and leaked credentials
Context
GitLab secret sprawl is a credential governance problem, not just a code scanning problem. When secrets remain valid long after they are committed, leaked tokens become reusable identity artifacts rather than short-lived mistakes.
The article shows how public repository scale, Git history, and platform-local credential reuse create a durable exposure surface for NHI governance. That matters because revocation, ownership, and offboarding are what separate a detected secret from a controlled one.
Key questions
Q: What breaks when secrets are spread across multiple repositories and tools?
A: When secrets sprawl across repositories and toolchains, organisations lose the ability to find, classify, and revoke them quickly. Response slows, ownership becomes unclear, and different copies may survive even after one credential is rotated. That creates avoidable exposure and makes incident response far harder than it should be.
Q: Why do leaked repository secrets keep creating risk after discovery?
A: Because discovery does not remove authority. If the token remains valid, an attacker or unauthorised user can still authenticate until the issuing system revokes it, rotates it, and confirms that dependent integrations have moved to a replacement credential.
Q: How do organisations know whether secret scanning is actually working?
A: Look for fewer valid secrets left in circulation after detection, not just higher detection counts. Working programmes can show fast owner assignment, reliable false-positive suppression, and automated invalidation before a secret can be reused. If alerts do not change credential status, the control is informational rather than protective.
Q: What is the difference between secret scanning and secret governance?
A: Secret scanning finds exposed credentials, while secret governance reduces the chance those credentials remain useful. Governance includes ownership, rotation, expiry, offboarding, and revocation. Without those controls, a detected secret may still be valid and exploitable even after it has been found.
Technical breakdown
Why public Git repositories become credential archives
Git repositories preserve history by design, which means a secret committed once can remain retrievable through old commits, branches, forks, and mirrors. In practice, scanning the latest tree is not enough because the credential may have been removed from the working copy while still existing in history. This is why Git platforms become long-lived secret stores when development workflows do not treat secrets as revocable identity artifacts. The issue is not only exposure at commit time, but persistence across the repository lifecycle.
Practical implication: scan full repository history, not just current files, and tie findings to a revocation workflow.
Why platform-locality increases leaked credential risk
Platform-locality is the pattern where people accidentally commit a platform's own credentials back into that same platform. The article's 406 GitLab keys in GitLab repositories illustrates that developers often reuse the same environment, tooling, and access context that created the secret. That creates a feedback loop between creation and leakage, especially where tokens are easy to copy into scripts, CI jobs, or config files. The result is not random leakage but repeatable identity misuse inside a familiar workflow.
Practical implication: treat platform-local credentials as a distinct risk class and monitor for same-platform token exposure.
Why verified secrets outlast the systems that issued them
A verified secret remains dangerous because its authority continues until the issuing system or organization revokes it. The article's ancient 2009 secret shows that credentials can survive their original context and keep working long after the people and systems around them have changed. In NHI terms, the identity outlives the control plane that should govern it. That is a governance failure, not a detection failure, because the control objective is lifecycle termination as much as discovery.
Practical implication: attach ownership and expiry semantics to every secret so revocation can happen even when the original context is gone.
Threat narrative
Attacker objective: Use exposed repository credentials to access downstream SaaS or cloud services with legitimate-looking authentication.
- Entry occurs when a credential is committed into a public GitLab repository and becomes retrievable through repository history or exposed files.
- Credential access follows when the leaked token is verified and remains usable against the target service until someone revokes it.
- Impact occurs when the token is abused for account access, data exposure, or service impersonation before the organisation can contain it.
Breaches seen in the wild
- 17,000+ Secrets Exposed in Public GitLab Repositories: Over 17,000 secrets including API keys and tokens exposed in public GitLab Cloud repositories.
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential governance fails when a secret is treated as content instead of identity. A token in a public repository is not just leaked text, it is an active authentication artefact with lifecycle, ownership, and revocation requirements. The article's 17,430 verified live secrets show that discovery alone does not close the exposure window. Practitioners should treat secret inventory as identity inventory, not code hygiene.
Platform-locality is a governance signal, not a curiosity. The 406 GitLab keys found in GitLab repositories indicate that developers tend to leak credentials where they work, not only where attackers look. That pattern suggests controls need to follow the workflow boundary, including developer endpoints, repo policies, and automated pre-commit detection. The practical conclusion is that same-platform leakage should be a first-class metric in NHI governance.
Zombie secrets expose the failure of lifecycle thinking. A credential that remains valid years after it was created proves that secret rotation and revocation are not optional cleanup tasks. The article's 2009 secret is a reminder that persistent validity creates governance debt across teams, tools, and ownership changes. The implication is straightforward: secrets without expiry and offboarding semantics are unmanaged identities.
Large-scale scanning only matters when it is paired with ownership resolution. The article describes triage across more than 2,800 domains and disclosure to over 120 organisations, which is the operational bridge between detection and remediation. That bridge is where many programmes break, because they can find exposure faster than they can map who owns the credential. The lesson is that secret governance must include routing, not just detection.
Secret sprawl is a lifecycle problem that cuts across SaaS, cloud, and source control. The same failure pattern appears wherever credentials are copied, reused, and left to persist beyond their intended context. That means NHI governance has to align developer workflow controls, revocation processes, and ownership records in one model. Practitioners should measure how quickly a discovered secret can be traced and invalidated, not just how quickly it can be found.
What this signals
Secret sprawl is really lifecycle sprawl. Discovery tools can tell you where leaked credentials are, but they cannot on their own decide who owns them or when they stop being valid. Identity teams should therefore organise secret management around issuance, ownership, expiry, and revocation rather than around repository cleanup.
Public code scanning becomes materially more useful when it is tied to the revocation path, not just the alert path. The operational question is how quickly a leaked token can be mapped to an owner and invalidated before it is reused in SaaS or cloud access.
Platform-local leakage deserves its own control logic. When credentials are most likely to be committed back into the platform that issued them, generic DLP-style thinking is too shallow. Teams need platform-aware controls that catch same-environment reuse and treat it as a repeated governance defect.
For practitioners
- Inventory secrets across repository history Scan complete Git history, not only current branches, and classify exposed values by service, owner, and last-known validity so remediation can start from the identity, not the file.
- Build immediate revocation routing When a verified secret is detected, route it to the owning team and the issuing service so the token can be revoked before it is reused elsewhere.
- Block same-platform credential reuse Add checks that flag GitLab credentials committed back into GitLab repositories, because platform-local leakage signals a recurring workflow failure.
- Track age and survivability of secrets Measure how long secrets remain valid after exposure and use that data to prioritise the oldest live credentials first.
- Tie disclosures to owner resolution Maintain an escalation path for domains with no published security contact so exposed secrets do not stall in triage.
Key takeaways
- Public GitLab repositories still contain a large volume of live secrets, which means exposure is persistent rather than incidental.
- The strongest evidence in the article is not just the number of secrets, but the fact that some remained valid for years and included GitLab-specific tokens.
- The control gap is lifecycle governance: ownership, rotation, and revocation must be connected to discovery if the finding is to reduce risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on leaked secrets in public repositories and their downstream misuse. |
| NHI-07 — Long-Lived Secrets | The article shows credentials remaining valid for years after exposure. | |
| NHI-01 — Improper Offboarding | Secrets persisted because credentials outlived their original owners and contexts. | |
| Recommendation — Scan repositories for exposed secrets and revoke any leaked credential before it is reused. Shorten secret lifetimes and enforce rotation so exposed credentials expire quickly. Offboard secrets explicitly when projects, teams, or integrations change ownership. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs credential lifecycle, rotation, and revocation for exposed authenticators. |
| Recommendation — Apply authenticator management controls to rotate and invalidate leaked credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article highlights the need to track and disable accounts tied to exposed secrets. |
| Recommendation — Use account management controls to identify and disable accounts linked to leaked tokens. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Leaked repository secrets create a direct credential-access path for attackers. |
| Recommendation — Map exposed secrets to Credential Access and prioritise high-impact token revocation. | ||
Key terms
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Platform-locality: Platform-locality describes the tendency for credentials to leak in the same system they are meant to access, such as GitLab secrets appearing in GitLab repositories. It reflects workflow design, credential reuse, and ownership gaps that make leakage more likely and remediation harder.
- Zombie Secret: A zombie secret is a credential that remains valid long after the people, systems, or projects that created it have changed. The term captures the governance failure where a secret outlives its intended context and keeps its authority until someone actively revokes or replaces it.
- Revocation Path: A revocation path is the complete operational route used to remove access across all systems where a credential or trust relationship exists. For vendor access, this must include connected applications, identity providers, tokens, and any downstream integrations that rely on the original trust.
What's in the full report
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- Repository-scanning automation and Lambda implementation details for large-scale secret discovery
- The triage workflow used to identify disclosure paths across thousands of domains
- Examples of verified Slack and GitLab token analysis that informed vulnerability reporting
- The exact comparison data between GitLab and Bitbucket secret density and payout outcomes
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org