Secrets Sprawl 2026: What 29 Million Leaked Credentials Mean for Your Business

The Numbers Behind Secrets Sprawl in 2025

According to GitGuardian's State of Secrets Sprawl 2026 report, 29 million new hardcoded secrets were exposed on public GitHub in 2025 alone. That is a 34% increase year on year, and the single largest annual jump since GitGuardian began tracking this problem. To be clear about what these secrets are: API keys, database passwords, private certificates, cloud access tokens, and OAuth credentials embedded directly into source code and then committed to repositories that anyone on the internet can read. This is not a new problem. Developers have been accidentally committing credentials to public repositories for as long as version control has existed. What changed in 2025 is the velocity. The rate of exposure is now outpacing the security controls most organisations have in place to catch it.

Why Is Secrets Sprawl Accelerating So Quickly?

Three forces are driving the acceleration simultaneously, and they reinforce each other. First, AI code generation tools — GitHub Copilot, Cursor, and their competitors — are shipping code faster than ever. That is largely positive for productivity. The problem is that AI-assisted code inherits bad habits from training data. When a developer asks an AI assistant to scaffold a quick integration with an AWS bucket or a payment API, the generated code frequently includes placeholder credential patterns that developers replace with real secrets and then forget to remove before committing. The AI does not flag this. The developer is moving fast. The secret ends up in the repository. Second, the sheer number of repositories has grown. More developers, more projects, more microservices, more internal tools — each one a potential surface for credential exposure. GitGuardian's analysis covered billions of commits, and the density of secrets per repository is not falling. Third, third-party and supply chain code is now deeply embedded in most development workflows. Developers pull packages, fork repositories, and adapt code from external sources constantly. Each handoff is an opportunity for a secret to travel further from its origin and further from the team responsible for rotating it.

• AI code tools generate credential-containing patterns that developers overlook before committing
• Repository volume has grown substantially, expanding the total attack surface
• Supply chain code increases the distance between secrets and the teams who manage them

What Attackers Actually Do With Exposed Secrets

The reason this matters is not academic. Exposed secrets are directly operational for attackers. Unlike a software vulnerability that requires exploitation, a valid API key or cloud access token requires no exploitation at all. An attacker finds it, tests it, and if it is still active, they have the same access as the developer who wrote it. Automated scanning of public GitHub repositories for secrets is a well-established attacker technique. Tools to do this are freely available, and threat actors run them continuously. GitGuardian's own research has previously shown that exposed secrets are tested within minutes of being committed to a public repository. The window between exposure and abuse is not days — it is often less than an hour. The downstream consequences depend on what the secret controls. A leaked database password may expose customer records. A leaked cloud access token may grant an attacker the ability to spin up infrastructure, exfiltrate data, or deploy ransomware payloads. A leaked CI/CD pipeline credential may give an attacker write access to your software build process — which is one of the most damaging positions an attacker can hold, because it allows them to insert malicious code upstream of your entire customer base. For organisations using platforms like Panorays to assess third-party risk, it is worth noting that exposed secrets in a supplier's public repositories represent a concrete, measurable risk signal — not just a theoretical concern.

How Long Do Leaked Secrets Stay Active?

One of the most damaging findings in GitGuardian's historical research is the remediation lag. The majority of exposed secrets are not rotated quickly. Many remain valid for weeks, months, or indefinitely. In some cases, developers are unaware that a secret was committed at all, particularly when it happened deep in a commit history that nobody has reviewed. This creates a compounding problem. A secret exposed today joins the pool of millions of previously exposed secrets that have never been rotated. Each one is a persistent doorway. The 29 million new secrets recorded in 2025 do not replace the secrets from prior years — they add to them. For security teams, this means the problem is not just about stopping new exposures. It requires active discovery and remediation of historical exposures across every repository the organisation owns, has forked, or has contributed to.

• Most exposed secrets are not rotated within 24 hours of discovery
• Historical repository scanning is as important as real-time commit monitoring
• Secrets from decommissioned projects frequently remain valid and unmonitored

What This Means for UK and New Zealand Businesses Specifically

The GitGuardian data covers public GitHub globally, but the exposure problem does not respect geography. UK and New Zealand businesses using GitHub for development — which includes the vast majority of technology companies and an increasing share of financial services, healthcare, and public sector organisations — are directly exposed to this risk. For UK businesses, the regulatory dimension is clear. Under the UK GDPR, an exposed credential that leads to unauthorised access to personal data constitutes a personal data breach. The Information Commissioner's Office expects notification within 72 hours of becoming aware of a breach that poses a risk to individuals. If an attacker used a leaked API key to access customer data three months before your team discovered the exposure, that is a significant regulatory and reputational problem. For New Zealand and Australian businesses, the Privacy Act 2020 and the Australian Privacy Act carry equivalent obligations. A hardcoded credential that remained valid and undiscovered for months is precisely the kind of failure that regulators examine during post-incident reviews. Beyond compliance, there is a practical risk concentration issue for smaller organisations. A startup or scale-up with a lean security team and high development velocity is more likely to have secrets in public repositories, less likely to have tooling to detect them, and less likely to have a rapid rotation process when they are found. That combination makes smaller businesses disproportionately attractive targets once their exposed secrets are identified by automated scanners.

How to Reduce Your Exposure to Secrets Sprawl

The security controls that address secrets sprawl are known. The challenge for most organisations is implementation at scale and consistency across development teams that may be distributed across multiple time zones and working with a wide range of tools. Pre-commit scanning is the first line of defence. Tools that check code for credential patterns before it reaches a remote repository catch the majority of accidental exposures at the source. However, pre-commit hooks are trivially bypassed or disabled, so they cannot be the only control. Repository scanning — both real-time monitoring of new commits and historical scanning of existing repositories — provides continuous coverage. This needs to extend beyond the repositories your team manages directly to include forks, archived projects, and any open-source contributions made by developers using company credentials. Secret rotation processes matter more than detection. A detected secret that takes three weeks to rotate because the rotation process is manual and poorly documented provides far less protection than one that can be revoked and replaced in minutes. Cloud providers increasingly support short-lived credentials and role-based access that reduce the blast radius of any individual secret exposure. Attack surface visibility is the broader context here. Understanding what is exposed and how it connects to your internal infrastructure is a prerequisite for prioritising remediation. Hadrian's continuous attack surface management capability gives security teams an external attacker's view of their exposed assets — which includes identifying where leaked credentials might provide access to discoverable infrastructure. You can find out more about how Hadrian works on our attack surface management page. For organisations managing third-party supplier risk, Panorays provides the supply chain visibility needed to identify whether your suppliers' development practices are creating credential exposure risks that flow through to your own environment.

• Deploy pre-commit scanning as a first line of defence, not a sole control
• Run historical repository scans, not just real-time commit monitoring
• Build automated rotation processes — manual rotation creates dangerous lag
• Extend monitoring to forks, archived repositories, and open-source contributions
• Use attack surface management to connect exposed credentials to accessible infrastructure

The Bigger Pattern: Developers Are Not the Problem

It would be easy to read the GitGuardian numbers and conclude that this is a developer discipline problem. It is not. The developers committing secrets to public repositories are not generally acting carelessly — they are moving at the pace their organisations reward, using tools that do not adequately surface credential risks in the moment of writing code, and working in environments where the feedback loop between a commit and a security incident is long and indirect. The 34% year-on-year increase in secrets sprawl is a systems problem. It reflects the gap between how fast organisations are shipping code and how fast their security tooling and processes have adapted to that velocity. AI-assisted development has widened that gap substantially in the past two years. Addressing it requires security controls that operate at development speed — embedded in the tools developers actually use, producing signals that are actionable immediately, and supported by rotation infrastructure that does not create a bureaucratic barrier to remediation. Organisations that treat secrets management as a developer education problem will continue to see the numbers climb. Those that treat it as an infrastructure and tooling problem will see different results. If you want to understand the current exposure across your own environment — including what an external attacker can see and access using credentials that may already be in circulation — speak to the Kyanite Blue Labs team. We can walk you through a structured assessment of your attack surface and your current detection and response capability for credential exposure incidents.

Frequently Asked Questions