Secret management continues to be one of the most challenging aspects of modern application security. While many security teams focus their attention on monitoring public repositories, and for good reason, the real danger often lurks in places you might consider safe. This misconception can lead to significant vulnerabilities within an organization's development ecosystem.

The numbers from the GitGuardian State of Secrets Sprawl 2025 report tell a compelling story that might surprise you. While public repositories certainly present risks, with 23.7 million new secrets detected there, which were added in 2024 alone, our research shows that over a third of private repositories, 35%, contain at least one plaintext secret, compared to just 4.6% of public repositories. This means internal code repositories leak secrets approximately eight times more frequently than the code pushed publicly.

This points to a world where developers assume private repos are inherently more secure. The data clearly shows this assumption is dangerously flawed. Once an attacker gains a foothold, all of those plaintext credentials will give them access to exactly what they want: your resources and your data. 

Secrets Waiting To Be Exploited

The term "private" creates a false sense of security that often leads to complacency. Many developers and DevOps professionals believe private repos are invisible to attackers, but this ignores several attack vectors. Phishing campaigns targeting developers, compromised employee credentials, and insider threats can all provide malicious actors with direct access to your private source code.

Private repositories often serve as the backbone of an organization's development infrastructure, with contributions coming from diverse teams including support engineers, DevOps specialists, contractors, and third-party vendors. Many of these contributors lack formal secure coding training, increasing the likelihood of credential leakage.

Focusing On Leaked Code And Overlooking Breached Code

Public repositories tend to benefit from a spotlight effect. Developers understand that anything pushed to public repositories becomes permanently searchable and visible to the world. This knowledge naturally encourages better security hygiene. Conversely, private repositories can feel sheltered from this scrutiny, creating an environment where developers might take shortcuts or implement quick-and-dirty solutions, such as hardcoding credentials.

The types of secrets found in private repositories further illustrate this problem. Our research indicates that AWS IAM keys appear in private repositories five times more frequently than in public ones. Secrets we detect with our generic detectors, like passwords, which typically lack the distinctive predetermined patterns that make them easy to detect with simple pattern matching, are three times more common in private repositories. For example, ODBC strings look like:

Extended Properties="Driver=SQL Server;uid= MyName;pwd= MySuper$ecretP4ssword"

This makes it very hard to write the needed regular expression to account for all variations.

Plaintext Credentials Are Not Just A Security Issue

This secret sprawl creates significant challenges beyond just the security risk. It imposes a form of toil on development teams; a workflow tax of sorts. When secrets are discovered late in the development lifecycle, perhaps months after being merged into the codebase, organizations face expensive rework. Teams must create hotfix branches, perform emergency credential rotations, and conduct time-consuming incident reviews that disrupt normal development activities.

Additionally, when security scans only run in production environments, developers receive alerts about issues in code they wrote weeks or months ago. This disconnect between the act of writing code and receiving security feedback creates a bad feeling for developers who are continually told to deliver features more rapidly. Developers can become desensitized to security warnings, viewing them as an annoying interruption rather than valuable guidance.

Tools Sprawl Is Real And Exhausting To Deal With

Many organizations compound these problems by implementing different scanning tools for different environments. They might use one scanner for public GitHub repositories, another for on-premises GitLab instances, and yet another for Azure DevOps. This tool sprawl forces engineers to juggle multiple dashboards and learn different systems instead of focusing on improving the security of the application itself.

Trying to get developers on board with any security tooling is hard enough. Getting them to use project-specific security tools is a non-starter. We need a unified way to address this problem at scale. 

Giving Developers Guardrails To Speed Them Along

At GitGuardian, we've taken a pro-developer approach by integrating security directly into the developer workflow. We believe effective secret detection must happen where developers actually work and when they make decisions about their code. This philosophy guides all our product features.

Our pre-commit hooks with ggshield and VSCode extension provide instant feedback to developers, allowing them to fix secrets before they ever reach the repository. This eliminates rework cycles and builds security awareness at the moment of creation. By catching issues at this stage, we prevent secrets from entering the codebase in the first place, which is always more efficient than removing them later.

Catching Leaks In Shared Code Early

For code that does make it to a shared repository, you can implement our pull request and merge request scanning capabilities, such as with GitHub Check Runs. This means secrets can block merges just like failed tests would, reinforcing the idea that security is part of the "definition of done" for any code change. This integration helps teams build a culture where security becomes a natural part of the development process rather than an afterthought.

As a check before deployment, our CI/CD pipeline scans through ggshield catch any secrets that might have slipped through earlier stages. These integrations can fail builds automatically if secrets are detected, without requiring custom scripting or complex configuration. This multilayered approach ensures that secrets have multiple opportunities to be caught before reaching production.

When organizations first implement GitGuardian, it automatically does a full historical scan throughout all the commits and branches in a repository to give you a baseline of existing issues. This retrospective analysis often uncovers many more hidden secrets than teams expect to find in their private repositories. More importantly for our customers, we typically see a steady decline in new secrets over time as engineers internalize better security practices and develop new habits.

Finding All The Secrets Beyond The Code

For many security teams, secrets security is something that only pertains to code repositories. This is part of the reason there is so much focus on enterprise secrets management as part of the solution. While adopting these vaults is a vital step towards mature secrets security, unfortunately, there are many more places where secrets can leak. Namely, every tool your team touches as they work through the code making, delivery, and debugging process. 

According to our research from the 2025 State of Secrets Sprawl Report, 38% of secrets found in collaboration tools were classified as critical or urgent, compared to 31% in source code. And alarmingly, only 7% of secrets overlap between the code base and these supporting collaboration platforms. These are mostly completely separate exposures.

Communication platforms like Slack and Teams, as well as project management tools like Jira and ServiceNow, are often used to pass the needed credentials for a project, even if the secret is properly vaulted. Some teams even use internal wikis as a way to 'back up' secrets. 

Focus On Real Leaks, Not False Alarms

By focusing on actionable findings rather than overwhelming developers with duplicate alerts, we reduce alert fatigue and keep teams engaged with security. When a credential does slip through, our audit trail shows exactly where it first appeared, who committed it, and which repositories still reference it. This detailed information cuts incident response time from days to minutes, allowing security teams to respond quickly and effectively.

Solve Secrets Sprawl Wheverver It May Leak

If your secret scanning strategy has only focused on public visibility of a leak, you're ignoring the larger risks in case of breach, and we would love to help you tackle this issue. Private repositories leak credentials more frequently, often contain higher-value secrets, and these leaks typically happen without the scrutiny that public repositories receive. Beyond the code, these secrets, even when properly stored, end up being copied to other systems in plaintext far too often. 

GitGuardian can meet your scanning needs throughout the developer workflow, from the IDE all the way through the CI/CD pipeline and container registries. We can help you transform secret detection from an occasional noisy audit into a continuous quality gate. 

We want developers to ship code faster because they avoid security-related rework. We want SREs to sleep better at night knowing credentials aren't being exposed. Security teams finally close the gap between scanning production environments and achieving comprehensive security across the entire development lifecycle.

It's time to pay attention to leaks happening in your private repositories and other platforms around the code. By doing so, you can transform secret sprawl from an overwhelming challenge into a manageable issue, protecting your organization's most sensitive credentials regardless of where they might be hiding in plaintext.