Topic starter
11/07/2026 8:23 pm
TL;DR: Truffle Security's scan of about 5.6 million public GitLab repositories finds 17,430 verified live secrets, including 406 GitLab keys, and a higher leak density than Bitbucket. The finding points to lifecycle governance as the control that must follow discovery if exposed credentials are to lose value.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Scanning 5.6 million public GitLab repositories for secrets”.
By the numbers:
- The scan found 406 valid GitLab keys in GitLab repositories, according to Truffle Security research.
Key questions
Q: Why do leaked repository secrets keep creating risk after discovery?
A: Because discovery does not remove authority.
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.
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.
Practitioner guidance
- 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.
Bottom line: Public GitLab repositories still contain a large volume of live secrets, which means exposure is persistent rather than incidental.
Glossary terms: Secrets Sprawl, Platform-locality, Zombie Secret, Revocation Path
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
👉 Read Truffle Security's analysis of GitLab secret sprawl and leaked credentials →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
11/07/2026 8:53 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: GitLab secret sprawl exposes why credential governance fails