Secrets Sprawl Statistics 2026

Secrets sprawl is the uncontrolled spread of credentials (API keys, tokens, certificates, database passwords) across the places software gets built, discussed, and shipped.

The problem is not that a key exists. It is that nobody knows how many copies exist, who owns them, or what they still unlock.

I collected data from eight published sources dated between 2023 and July 2026, then reviewed the documentation of every secret scanning tool I track. Every source is listed and linked at the end.

For adjacent data, see my Supply Chain Attack Statistics and Software Vulnerability Statistics pages.

Key statistics at a glance#

What secrets sprawl is#

Secrets sprawl is what happens when an organization creates credentials faster than it can track, own, and retire them.

A single API key rarely stays in one place.

It gets committed to a repository, pasted into a ticket, copied into a CI variable, cached in a local .env file, and shipped inside a container image.

Each copy is a separate exposure with its own lifespan. Scanning finds the copies; governance decides whether they should have existed.

The term covers both the volume problem (how many credentials exist) and the visibility problem (who can answer what each one accesses).

Public GitHub leak volume#

How many secrets leaked on public GitHub in 2025?#

• 28.65 million new hardcoded secrets were added to public GitHub commits in 2025 (GitGuardian, March 2026 )
• That is a 34% increase year over year, and the largest single-year jump GitGuardian has recorded across five editions of its report
• Public GitHub commits reached roughly 1.94 billion in 2025, up 43% year over year
• The active public developer base grew 33% over the same period
• Baseline leak rate across all public GitHub commits: 1.5%

The commit-volume number changes how the headline reads. Commit growth (43%) outpaced secret growth (34%), so detections per commit fell: roughly 1.58% in 2024 against 1.48% in 2025 on the report’s rounded totals.

I would not call that a hygiene win. Detector coverage and repository composition both shifted year over year, so a 6% relative dip sits inside the noise this kind of dataset produces.

The absolute number is what matters operationally. Working back from the 34% figure, about 7.3 million more credentials went public than the year before.

AI services and leaked keys#

How fast are AI credentials leaking?#

• AI service secrets reached 1,275,105 detections in 2025, up 81% year over year (GitGuardian 2026)
• 113,000 DeepSeek API keys leaked publicly, one of the clearest single-provider exposure windows in the dataset
• Eight of the ten fastest-growing detectors were tied to AI services
• LLM infrastructure (orchestration, RAG, vector storage) leaked 5x faster than core model providers
• Commits assisted by Claude Code showed a 3.2% secret-leak rate versus the 1.5% all-commit baseline

The assistant gap is worth reading carefully. GitGuardian frames it as a workflow outcome rather than a tool defect, since developers still choose what to accept and push.

What I keep looking at is where the growth clusters. GitGuardian’s own reading is that new AI providers, wrappers, gateways, and registries enter production workflows before developer protections catch up.

MCP configs and agents#

How many secrets sit in MCP configuration files?#

• 24,008 unique secrets were found in MCP-related configuration files on public GitHub (GitGuardian 2026)
• 2,117 of those were confirmed valid credentials
• That is 8.8% of all MCP-related findings
• GitGuardian attributes much of this to setup documentation that recommends putting API keys directly into config files, CLI arguments, or connection strings

This is a documentation problem before it is a developer problem. When the official quickstart hardcodes a key, the pattern spreads at ecosystem speed.

I found the same shape in my MCP Server Security Audit 2026 . Insecure defaults spread faster than the fixes for them.

This page covers credentials leaking out of AI tooling. For the wider picture on model, prompt, and agent risk, see my AI Security Statistics .

GitLab, Bitbucket, and training data#

GitHub dominates the coverage, but it is not the only place credentials sit in public. Truffle Security ran platform-wide scans that give independent, non-GitHub figures.

What did platform-wide scans find?#

Truffle ran both repository scans with the same tooling and compared them directly: GitLab carries roughly 35% higher secret density per repository than Bitbucket, despite holding about twice as many public repos.

Normalized, that is about 3,100 verified live secrets per million public GitLab repos against 2,360 per million on Bitbucket.

Treat both as floors, not totals. Each figure counts what one scanner verified as live during a single scan window, and the two scans ran roughly two months apart against different platform populations.

Truffle also found 406 valid GitLab keys leaking on GitLab against 16 on Bitbucket, which they call platform locality. Credentials tend to leak where they are issued.

What was inside the AI training data?#

• 221,303 live unique credentials across 6,003 datasets (Truffle Security, June 2026)
• 349 live GitHub personal access tokens, including 223 with full repo write, 130 able to rewrite CI workflows, 112 with admin:org, and 110 able to publish packages
• 318 Docker Hub tokens with image push rights
• 8,557 GCP service-account keys across 3,811 projects
• 8,594 working database logins, measured at 3.5 TB from metadata alone
• Separately, 51.7 TB sat in S3 buckets configured to block public access
• One live AWS key reached the corpus because someone pasted boto3 code into a chatbot, then got mirrored about 18 times

That last one is the new leak path. A credential now escapes through a conversation, gets captured in a public chat dataset, and outlives the conversation indefinitely.

Leaks outside the repository#

Where do secrets leak besides code?#

• About 28% of incidents originate entirely outside repositories, in tools like Slack, Jira, and Confluence (GitGuardian 2026)
• Out-of-code leaks are 13 percentage points more likely to be categorized as critical than secrets found only in code
• Internal repositories are roughly 6x more likely than public ones to contain hardcoded secrets

The severity skew has a simple cause. Credentials get pasted into chat during incidents and urgent debugging, which is exactly when the highest-privilege keys come out.

Private-by-default thinking creates the internal-repo gap. Teams relax when exposure feels theoretical, and that buildup becomes the material an attacker uses after the first foothold.

The rotation gap#

Do leaked secrets ever get rotated?#

• More than 64% of credentials confirmed valid in 2022 were still valid when retested in January 2026 (GitGuardian 2026)
• The same cohort tested roughly 70% valid in January 2025, so one year of retesting moved the number about six points
• 46% of critical secrets are missed by validation-only prioritization, because they cannot be automatically verified

This is the statistic I would put in front of a board. Detection coverage keeps expanding in this dataset; the share of old credentials still answering barely moves.

A scanner that only surfaces verifiable credentials also inherits a blind spot. Nearly half of critical exposures fall outside what live validation can confirm.

Developer machines and CI runners#

The Shai-Hulud 2 campaign gave researchers an unusual window into what actually sits on build machines.

What was found on compromised machines?#

• 6,943 compromised machines analyzed in GitGuardian’s reprocessing of the dataset for its 2026 report
• 294,842 secret occurrences, corresponding to 33,185 unique secrets, of which 3,760 were still valid at analysis time (GitGuardian incident analysis, 27 Nov 2025 )
• GitGuardian describes the duplication as roughly eight locations per live secret
• 59% of the compromised machines were CI/CD runners rather than personal workstations (GitGuardian 2026)

The machine count comes from the 2026 report’s reanalysis, while the incident write-up counted a snapshot of 20,649 publicly exposed repositories. Same campaign, different denominators.

The runner majority reframes the endpoint problem. A build agent holds broader credentials than a laptop and usually has fewer controls watching it.

Agentic tooling widens this further, since local agents read terminals, files, environment variables, and credential stores by design.

Breach and cost context#

How do secrets rank as a breach cause?#

• 31% of breaches now start with software vulnerabilities, which displaced stolen passwords as the top initial access route (Verizon 2026 DBIR )
• 48% of all breaches involve ransomware, though payouts are shrinking
• 15 distinct attack techniques are now augmented by generative AI
• Global average breach cost hit USD 4.99 million, a 12% increase and a record high (IBM Cost of a Data Breach Report 2026 )
• IBM recorded a 56% increase in AI-driven attacks, led by deepfake impersonation and AI-enabled malware

I include the DBIR number because it cuts against the way secrets data usually gets sold. Stolen passwords lost the top initial-access slot to software vulnerabilities, even as raw credential exposure kept growing.

What the scanners actually cover#

I track 11 active secret scanning tools . I read each one’s vendor or project documentation against two findings above.

Those two: 28% of incidents start outside code, and validation-only triage misses 46% of critical secrets.

This is a documentation review, not a benchmark. It records what each product says it does, current as of August 2026.

Which scanners verify secrets are live?#

Eight of the eleven document live validation, meaning the scanner calls the issuing provider to confirm a credential still works. Coverage is per-detector in every case, never universal across all secret types.

Kingfisher’s rule inventory moves fast. It listed 1,051 rules with 516 validating and 52 supporting direct revocation on 5 August 2026.

Collaboration-tool and edition claims above come from each vendor’s own documentation: Kingfisher , TruffleHog Slack and Confluence , GitGuardian , Spectral Jira and Confluence , and GitHub validity checks .

The collaboration-tool coverage gap#

Four of the eleven document scanning collaboration tools. Three of those four are commercial, or gate the connectors behind a paid tier.

Among the eleven I reviewed, that leaves Kingfisher as the only fully open-source scanner with native Slack, Jira, and Confluence sources.

I did not survey every scanner on the market. Read this as a coverage comparison across these eleven, not a census.

I would not read GitGuardian’s 28% as “28% of incidents happen in Slack.” Their figure covers all non-repository environments, and a scanner without a native connector can still inspect exported content.

If you are picking between the two most-compared open-source options, my Gitleaks vs TruffleHog breakdown covers the verification tradeoff in detail.

What independent testing says#

Vendor documentation measures advertised capability, not accuracy. The strongest independent measurement I found is Basak, Cox, Reaves and Williams (2023) , who evaluated five open-source and four proprietary scanners against a shared benchmark.

Their results, as published:

• Best precision: GitHub Secret Scanner 75%, Gitleaks 46%, an unnamed commercial tool 25%
• Best recall: Gitleaks 88%, SpectralOps 67%, TruffleHog 52%
• False positives traced mainly to generic regular expressions and weak entropy calculation
• False negatives traced to faulty regexes, skipped file types, and thin rulesets

Treat those rankings as historical. Detection rulesets have moved substantially since 2023, so the numbers date the field rather than describe it today.

The durable finding is the spread. The most precise tool did not have the best recall, so the tradeoff you are actually buying is a false-positive rate against a miss rate.

What these numbers can’t tell you#

Almost every figure here comes from a vendor that sells secret scanning. Detection counts reflect each vendor’s detector coverage, so a rise can mean more leaks, better detectors, or both.

Public-surface scans are floors, not totals. They count what one scanner verified as live at one moment, and a credential rotated the next day still counted.

My scanner table reads documented capability from vendor and project documentation. It is not a bench test, and advertised coverage is a weak proxy for detection accuracy.

The GitLab and Bitbucket density comparison is Truffle Security’s, published in their GitLab write-up. I reproduced the arithmetic rather than originating the finding.

Detector counts age within weeks. Kingfisher’s ruleset moved by more than a hundred rules between my earlier reading and 5 August 2026.

Sources & methodology#

Every source used here is listed and linked below, and each statistic names the report it came from. If I cannot trace a number to a primary source, I leave it out.

Primary reports:

• GitGuardian State of Secrets Sprawl 2026 — fifth edition, published 17 March 2026, covering public GitHub, internal repositories, and collaboration tools
• Truffle Security: 7.6 Petabytes of Hugging Face Training Data — 187 million files scanned, June 2026
• Truffle Security: 5.6 million public GitLab repositories — November 2025
• Truffle Security: 2.6 million public Bitbucket Cloud repositories — November 2025
• Verizon 2026 Data Breach Investigations Report — initial access vectors and ransomware share
• IBM Cost of a Data Breach Report 2026 — global average breach cost, AI-driven attack growth
• GitGuardian: Shai-Hulud 2.0 analysis — incident write-up published 27 November 2025, covering a snapshot of 20,649 exposed repositories
• Basak, Cox, Reaves & Williams: A Comparative Study of Software Secrets Reporting by Secret Detection Tools — peer-reviewed benchmark of nine scanners, 2023

My contribution:

• A documentation review of 11 active secret scanning tools covering live validation, collaboration-tool coverage, and required edition, read from vendor and project documentation on 5 August 2026
• No scanner was executed for this page. Where the reviewed documentation and the vendor site disagreed, I used the vendor site.

Frequently Asked Questions