NHI Foundation Level Training Course Launched

17,000+ Secrets Exposed in Public GitLab Repositories — What Went Wrong and How to Fix It

In late November 2025, a major security analysis revealed a startling reality: public repositories on GitLab Cloud have leaked over 17,000 live secrets, including API keys, access tokens, cloud credentials, and more.

The scan covered about 5.6 million public repositories, uncovering exposed secrets across more than 2,800 domains.

This massive exposure underscores how widespread and dangerous “secrets sprawl”, hard-coded credentials in public repos, has become.

What Happened

Security researcher Luke Marshall used the open-source tool TruffleHog to scan every public GitLab Cloud repository. He automated the process: repository names were enumerated via GitLab’s public API, queued in AWS Simple Queue Service (SQS), then scanned by AWS Lambda workers running TruffleHog, all within about 24 hours and costing roughly $770 in cloud compute.

The result: 17,430 verified live secrets, nearly three times the amount found in a similar scan of another platform.

These secrets included sensitive credentials like cloud API keys, tokens for cloud services, and other access credentials.

In short: thousands of developers inadvertently committed real secrets to public repositories, data that is now exposed for anyone to find and misuse.

How It Happened

  • Human error + insecure practices – Many developers or teams treat Git repositories as just code storage, not secret vaults. As a result, credentials (API keys, cloud secrets, tokens) get committed alongside code.
  • Public repository exposure by default or misconfiguration – Some repos are intentionally public (open-source), others may have been mis-marked as private, or visibility changed over time. Once public, everything becomes accessible.
  • Lack of secret hygiene and automated detection – Without automated secret-scanning tools integrated into CI/CD or repository workflows, exposed secrets remain undetected, sometimes for years.
  • Scale & automation exacerbate the risk – With millions of repos and many contributors, the probability of human error is high. Coupled with the fact that secrets often remain valid (long-lived credentials), this creates a large attack surface.

Possible Impact & Risks

The exposure of 17,000+ secrets across public repositories has major implications for both individual developers and organizations:

  • Credential theft leading to account takeover – Cloud API keys, tokens, or credentials could be used by attackers to hijack cloud services, spin up infrastructure, exfiltrate data, or launch attacks.
  • Supply-chain and downstream attacks – Public projects often serve as dependencies for other codebases, leaked secrets in one repo can jeopardize entire downstream ecosystems.
  • Long-term undetected compromise – Since credentials tend to stay valid unless rotated, exposed secrets may have already been harvested, even if no breach has yet been observed.
  • Reputational damage for teams and organizations – Leaks from public repos erode trust and may cause clients or partners to reconsider engagements.
  • Regulatory or compliance fallout for enterprises – Organizations that inadvertently publish credentials tied to sensitive data or infrastructure could face compliance risks, especially in regulated industries.

Recommendations

If you manage code or cloud infrastructure, or create software that depends on public repositories, now is the time to act:

  1. Audit all repositories public and private – Scan for hard-coded secrets, credentials, tokens, API keys. Treat every repo as a potential liability.
  2. Use automated secret-scanning tools – Integrate tools like TruffleHog, secret-scanners, or dedicated secret-management platforms into your CI/CD pipelines to catch leaks before code is merged.
  3. Rotate all exposed credentials immediately – If you find secrets in code, rotate or revoke them. Treat any exposed credential as compromised, even if it seems unused.
  4. Adopt secrets-management best practices – Use vaults / secrets managers rather than hard-coding credentials. Use ephemeral or short-lived tokens where possible.
  5. Enforce least-privilege and zero-trust – Limit what each token or API key can do. Avoid giving broad privileges by default.
  6. Educate developers and teams – Make secret-hygiene part of code reviews and development culture. Ensure everyone understands the risks of committing secrets.

How NHI Mgmt Group Can Help

Incidents like this underscore a critical truth, Non-Human Identities (NHIs) are now at the center of modern cyber risk. OAuth tokens, AWS credentials, service accounts, and AI-driven integrations act as trusted entities inside your environment, yet they’re often the weakest link when it comes to visibility and control.

At NHI Mgmt Group, we specialize in helping organizations understand, secure, and govern their non-human identities across cloud, SaaS, and hybrid environments. Our advisory services are grounded in a risk-based methodology that drives measurable improvements in security, operational alignment, and long-term program sustainability.

We also offer the NHI Foundation Level Training Course, the world’s first structured course dedicated to Non-Human Identity Security. This course gives you the knowledge to detect, prevent, and mitigate NHI risks.

If your organization uses third-party integrations, AI agents, or machine credentials, this training isn’t optional; it’s essential.

Conclusion

The discovery of over 17,000 live secrets exposed in public GitLab repositories is a stark wake-up call. It shows how modern development practices, when paired with human error and outdated credential management, can create massive security risks invisible until it’s too late.

This isn’t a flaw in GitLab itself. It’s a systemic issue of secrets sprawl and lack of hygiene. The silver lining: unlike a software vulnerability, this is a problem teams can fix, by auditing their repos, rotating credentials, and putting real secret management practices in place.

If your organization relies on code repositories, cloud services, or third-party integrations, it’s time to treat every secret as a high-value identity. Because once secrets leak, the attackers don’t need exploits, just access.