GitLab Secret Leaks Put Public Repositories At High Security Risk

Public GitLab repositories contained a large set of exposed credentials that created real security risk. A full scan of all 5.6 million public GitLab Cloud repositories uncovered more than 17000 live secrets tied to over 2800 domains. The findings show a higher exposure rate than similar scans on Bitbucket and Common Crawl. The data highlights a long running problem with credential hygiene in development environments.

Relevant Source (Truffle Security): Scanning 5.6 Million Public GitLab Repositories For Secrets
Security engineer Luke Marshall details how he scanned every public GitLab Cloud repository with TruffleHog, verified over 17,000 live secrets across 2,800+ domains, and analyzed the scope and impact of this large-scale credential exposure.

Quick Facts

• 17000 live secrets found across GitLab Cloud
• 5.6 million repositories scanned in 24 hours
• Google Cloud Platform keys were the most exposed
• Bitbucket had one third as many leaked secrets
• Some leaked keys dated back to 2009 and still worked
• Researcher earned 9000 dollars in bug bounties

Inside The GitLab Secrets Scan

A security engineer scanned every public GitLab Cloud repository using an automated pipeline built on AWS services. The researcher relied on TruffleHog to search for credentials including API keys, cloud tokens, and database connection strings. The process showed that secret leakage is persistent across the software ecosystem and often goes unnoticed for years.

• Exposed secrets were tied to more than 2800 unique domains.
• The density of secrets per repository was higher than Bitbucket.
• Google Cloud Platform, MongoDB, Telegram, and OpenAI were common sources.

Developers continue to commit credentials by accident even with modern scanning tools and CI checks. This pattern suggests that teams still struggle with secure development habits and automated detection.

Relevant Source (GitGuardian): The State Of Secrets Sprawl 2025
GitGuardian’s 2025 report shows that leaked secrets in public repos are widespread and often remain valid for years, reinforcing how persistent this exposure problem is.

Why Exposed Secrets Create Critical Risk

Leaked secrets let attackers bypass authentication and reach live systems. A single token can provide access to cloud services, databases, or internal dashboards. Old credentials remain dangerous when they have not been revoked. Organizations that rely on public repositories or open collaboration face higher exposure without strict hygiene and regular scanning.

• Cloud keys can permit administrative control.
• Database secrets enable data theft or manipulation.
• Bot tokens can be weaponized for spam or fraud.
• AI platform keys can be abused for expensive API calls.
• GitLab keys can allow direct access to code or CI pipelines.

Many organizations revoked exposed keys after receiving notifications. Others ignored them, leaving live attack surfaces open to exploitation.

Relevant Source (MITRE ATT&CK): Credential Access Overview
MITRE explains how attackers exploit exposed or stolen credentials to move laterally, escalate privileges, and access sensitive systems, matching the risks created by leaked GitLab secrets.

Practical Steps To Reduce Exposure

Any team using GitLab or similar platforms should treat secret scanning as a mandatory control. Automated checks should run in local development, pre-commit hooks, and CI. Credential rotation and centralized secret managers reduce the chance that a single leak leads to compromise.

Steps to take:

1. Scan all repositories with tools like TruffleHog or GitGuardian
2. Rotate any key stored in code history or committed by mistake
3. Adopt secret managers such as AWS Secrets Manager or Vault
4. Enforce pre-commit hooks to block sensitive patterns
5. Review repository permissions and reduce public exposure

Routine audits limit long term damage and keep teams ahead of potential threats.

Relevant Source (CISA): Using Rigorous Credential Control To Mitigate Trusted Network Exploitation
CISA details how strict credential management, rotation, and access controls reduce the impact of compromised accounts, aligning with secret-scanning and hardening steps for Git platforms.

Relevant Source (AWS): Best Practices For Managing AWS Access Keys
AWS outlines concrete guidance for avoiding hardcoded keys, rotating credentials, and using centralized secret management, which supports the mitigation steps recommended for exposed GitLab secrets.

Secrets Sprawl Across Modern Dev Stacks

The discovery shows how common insecure coding habits remain across open development platforms. Even experienced teams commit credentials when working quickly, switching contexts, or misconfiguring local workflows. Cloud services make it easy to generate new tokens, so many developers forget to track or revoke them. Public repositories then become long term storage for forgotten secrets.

The issue spans cloud platforms, AI services, databases, and CI tools. Attackers know this and routinely scrape public code for live tokens. Any scalable service with a token based model becomes a target. The GitLab results show that cloud native environments still rely heavily on credentials that are easy to expose and difficult to monitor.

Relevant Source (Wiz): Leading AI Companies Keep Leaking Their Own Information On GitHub
Wiz’s research on AI companies leaking API keys and credentials on GitHub illustrates how even advanced organizations routinely expose secrets across code, forks, and developer repos.

Smart Security Wrap Up

Effective secret hygiene depends on habits and automation. Public platforms like GitLab will keep growing, and credential leaks will continue unless teams build guardrails into every stage of development. Regular scans, rapid revocation, and centralized secret management create a safer development environment with less room for human error.

FAQ

How many secrets were exposed on GitLab?
About 17430 live secrets were verified across 5.6 million public repositories.

Which services had the most leaked credentials?
Google Cloud Platform keys led the list followed by MongoDB, Telegram bot tokens, and OpenAI keys.

How old were the oldest exposed secrets?
Some valid keys dated back to 2009.

Did organizations revoke their leaked keys?
Many did after receiving notifications, but a number of secrets remained active.

How long did the scan take?
The researcher completed the scan in just over 24 hours using AWS Lambda with high concurrency.

How JENI Strengthens Security Hygiene

JENI helps organizations reduce risk by tightening everyday system performance and improving the consistency of security practices. Clean, optimized machines make it easier to maintain predictable development environments where secret scanning and secure workflows run without friction. Stable systems also reduce configuration drift that often leads to accidental credential exposure.

What JENI Improves:

• Streamlined system performance that supports reliable security tooling
• Reduced clutter and conflicts that cause unstable development environments
• Better visibility into machine conditions that influence secure coding habits

JENI fits naturally into a disciplined security posture because strong hygiene starts with well-maintained systems. Developers work faster when their machines stay stable, which lowers the chance of rushed mistakes that leak credentials. Security tools also behave more consistently when the underlying system is clean and optimized. JENI supports those conditions by helping teams keep their devices running smoothly and free of the issues that often contribute to preventable security lapses.

Geoffrey Wenger

Geoffrey has decades of hands-on experience in IT, software development, and cybersecurity, bringing expert technical insight to every article. He holds two IT bachelor’s degrees, a business degree, and a master’s degree in Cybersecurity and Information Assurance.