Truffle Study Finds 543,699 Live Secrets in Public GitHub Repos: Push Protection Gaps

GitHub, which Microsoft owns, spent most of 2023 and 2024 rolling out automated defenses against this exact problem. The study found that those defenses work. It also found that they only cover part of the problem.

What Truffle Security actually measured​

The details matter here, because the headline figure is easy to misread.

• The corpus is a snapshot, not a live scan of GitHub. Truffle says the dataset's crawl closed on August 7, 2025. It covered 4,096 metadata shards containing 224,553,295 repositories and 58,467,468,698 file entries.
• It only includes default branches. The Stack v3 keeps each repository's default branch as it stood at crawl time. It has no commit history, rewritten history or deleted branches.
• The credentials were tested against the services that issued them. Between 27 and 28 July 2026, Truffle tested each candidate credential against its issuing service, and 543,699 came back live. That was eleven months after the crawl closed, and in most cases years after the credentials were first committed.
• Duplicates were removed. The same key turns up across forks, across files, and sometimes both. Truffle keyed each credential by its own value rather than by the file it sits in, then took the earliest date across every copy. That produced 543,699 dated credentials from 1,103,438 separate exposures.
• Leak dates are estimates. With no commit history available, Truffle used each file's last-modified timestamp as the leak date. The researchers point out that a file edited after the secret was added will look newer than it is. That means their age figures, if anything, understate how long credentials were exposed.

A necessary caveat: "live" means the credential authenticated when tested. The study does not show how many credentials attackers found, what each one could reach, or whether any were abused. BleepingComputer's Bill Toulas makes the same point. The findings show the scale of working-secret exposure, but they don't reveal what percentage of those secrets are actually stolen and abused by attackers.

Section summary: More than half a million unique secrets from a 2025 snapshot of public GitHub default branches still worked in July 2026, and the median one had been public for more than two years.

Corrections to early coverage​

Several numbers have already been garbled in the first round of coverage:

• The density baseline is 2014, not 2015. BleepingComputer reported density rising from 3.72 per million files in 2015 to a peak of 11.62 in 2025. Truffle's own write-up puts the 3.72 figure in 2014: 3.72 live credentials per million files in 2014, 9.54 in 2022, and 11.09 in 2023, then 11.62 in 2025, the highest in the dataset, measured on files touched in the seven months before the crawl closed. Because 2025 covers only a partial year, compare it using density, not raw counts.
• The Gemini figure is 31,374, not 69,041. Cybernews wrote that Google API keys with Gemini access were the most common live secrets, with 69,041 found. In Truffle's breakdown, 69,041 is the number of live Google Cloud service account credentials. Truffle counts 31,374 live Gemini keys and 33,343 live Google API keys overall.
• The test date is July 2026, not July 2025. At least one threat-intelligence aggregator said the credentials were exposed as of July 2025. The crawl closed in August 2025 and the verification ran in July 2026.

Push Protection: effective, but narrow​

GitHub's history here is relevant. Truffle cites these milestones:

In its February 2024 announcement, GitHub said that when a supported secret is detected in a push to a public repository, users can remove it or, if they judge it safe, bypass the block. GitHub also noted the change could take a week or two to reach every account. The same post said GitHub had detected more than a million leaked secrets on public repositories in the first eight weeks of 2024 alone.

Truffle sorted its live credentials into three groups by estimated leak date:

• 245,959 (45.2%) leaked before alerts were free.
• 97,897 (18.0%) leaked while alerts were free and Push Protection was available but opt-in.
• 199,843 (36.8%) leaked after Push Protection became the default.

The good news is that the block works where it applies. Covered credential types fell 53% in the 12 months after default push protection was introduced, while types not covered by default fell just 7% over the same period. Truffle says the drop was spread across many token families rather than driven by one. It also ran the same comparison at earlier cutoff dates and found roughly no gap before August 2023, which suggests the effect comes from the rollout rather than an existing trend.

The researchers also list reasons to be cautious about that result:

• The decline happened gradually from March to July 2024, not on one date.
• Some organizations turn on generic patterns themselves, which makes 53% more of a floor than a precise figure.
• AWS and Google were pushing customers toward short-lived credentials during the same period.

The bad news is coverage. Truffle found that 51.8 percent of what is still live is a shape push protection does not recognise, and nothing about it helps the half million already there. Truffle says the largest gaps are:

• MongoDB connection strings: 51,067 live, not blocked by default.
• Google API keys: 33,343 live, listed by GitHub as not push-protected.
• Private keys and database connection strings in general: treated as "generic patterns," which are off by default unless an organization enables them.

The Google gap is intentional. Gemini keys and Maps keys share the same AIzaSy prefix. A Gemini key is a billable credential, while a Maps key is designed to sit in a web page. A single pattern can't tell them apart, so GitHub doesn't block either. Truffle's 31,374 live Gemini keys have a median leak date of February 2025, so all of them leaked after Push Protection became the default.

Section summary: Push Protection roughly halved leaks of the token types it recognizes. It does not cover database strings, Google API keys or private keys by default, and it does nothing about secrets that were already public.

Revocation, not detection, decides whether a leak matters​

For admins and developers, this is the most useful part of the study. Truffle compared how often committed credentials survive, grouped by issuer:

The pattern is clear. Providers that automatically revoke leaked tokens, such as npm, GitHub and Hugging Face, have almost no survivors. Nobody revokes a Postgres URL on your behalf, so about 88% of those still work. Truffle notes that a "not live" result can mean a key was revoked or that the account behind it was deleted. It also left MongoDB out of these survival rates, because its detector only reports a URI after connecting successfully, which would make every MongoDB result look live.

GitHub runs a secret scanning partner program that passes leaked tokens to the issuing provider. Truffle points out that the program leaves the next step up to the provider and doesn't require revocation.

Deleting a leaked file doesn't fix the problem either. Truffle's 2024 research on GitHub repository networks found that as long as one fork exists, any commit to that repository network will exist forever. The firm's conclusion: the only way to securely remediate a leaked key on a public GitHub repository is through key rotation.

What to do this week​

Here is the practical checklist, based on Truffle's recommendations and GitHub's guidance:

1. Rotate first, clean up second. Treat any committed secret as compromised once it lands, whether or not a tool flagged it. Revoke or rotate it with the issuer before you touch Git history.
2. Scan your full history. Anything committed before February 2024 was never covered by default blocking. Tools like the open-source TruffleHog can scan repositories. One public project's setup notes recommend running its GitHub Action with extra_args: --only-verified to cut false positives.
3. Check your Push Protection settings. GitHub says you can verify its status in your code security and analysis settings. Organizations on GitHub Advanced Security should consider enabling generic patterns to cover connection strings and private keys.
4. Prefer credentials that expire. Short-lived tokens and workload identity limit the damage. Truffle notes that most of what it found would have expired harmlessly if it had been given a lifetime.
5. Confirm the fix worked. Closing a ticket doesn't prove a key is dead. Test again to confirm the rotated credential no longer authenticates.
6. Pay extra attention to Google and database secrets. Gemini keys, GCP service account JSON files and Postgres/MySQL/MongoDB connection strings are among the most likely to survive in Truffle's data.

Analysis: who owns the fix?​

Keep in mind that Truffle Security sells secret-scanning products, and its companion post ends with a pitch for its enterprise tooling. Even so, its methodology is unusually open about its own limits, including undercounting from non-default branches and history that was force-pushed away. On balance, those limits suggest the real number of live leaked credentials is higher.

The bigger point is structural. The developer who leaks a key often isn't the one who can revoke it, and the scanner that finds it almost never can. GitHub's block is effective, but it only prevents new leaks and does nothing about secrets already in public code. The providers that automated revocation fixed their share of the problem. Everyone else still depends on individual repository owners to rotate their own keys.