Security2 publishers2 min readPublished Updated
Truffle Security finds 543,699 live credentials left public on GitHub for a median 784 days
Truffle Security scanned 224 million public GitHub repositories and found 543,699 credentials still working in July, exposed for a median 784 days. Push Protection screens only new pushes in known formats, so owners have to rotate the backlog themselves.
The Watch · Security desk
What happened
- GitHub's Push Protection scans incoming code for secret patterns and blocks the upload on a match, but it does not revoke credentials that were already public.
- Truffle counts 199,843 of the live credentials, about 36.8% of the total, as exposed after GitHub turned Push Protection on for all users in February 2024.
- More than half the working credentials, 51.8%, fall in categories the default Push Protection does not block, including database connection strings and Google API keys.
- Of 126,963 Google Cloud service account credentials found committed, 69,041 were still valid when Truffle ran its analysis.
- The scanned corpus was a dataset assembled to train large language models, built from a crawl that closed on August 7, 2025.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint Roughly 343,856 live keys went public before February 2024, out of reach of a push-time gate; they stay usable until each owner rotates them.
- exposure An attacker who finds a committed Google Cloud service account key has better than even odds it works, with 54.4% of them still valid.
- decision Teams on GitHub's default settings have to run their own history scans for database connection strings and Google API keys, because the platform filter passes those formats.
Push Protection checks commits as they arrive. A key that was already public when the check switched on stays public until someone rotates it, and it stays valid for the same period. Truffle's data holds a long tail of those. About 10% of the working credentials are older than 6.3 years, and the oldest dates from 2009 [4].
Within the patterns it recognises, the check has worked. Truffle measured a 53% fall in the rate of exposed credentials in protected categories after GitHub made the feature a default [10]. Applying the 51.8% share of uncovered categories to the full count gives roughly 282,000 working secrets in formats the default settings let through [5].
According to Truffle, the odds that a leaked credential gets revoked depend heavily on the issuing service [13]. Of 101,886 committed npm tokens, it found one that still worked [11]. Google Cloud went the other way. Its 69,041 live service account keys are 12.7% of every working credential in the study [3].
Secret density is rising. Working credentials per million files went from 3.72 in 2015 to a peak of 11.62 in 2025 [6], roughly a threefold increase [4]. The GitHub total is more than double the 221,303 working credentials Truffle found when it scanned Hugging Face in August [14].
Truffle counted each unique key once, but the keys appeared repeatedly, across more than 1.1 million files and repositories, forks included [3]. BleepingComputer's recommended response is to rotate exposed credentials immediately, clean up repositories, scan history and set automatic expiration for all active secrets [15]. Rotation acts on the key itself, so it covers every copy, including the ones in forks [3][15].
The research measures exposure. It does not show what share of these keys attackers have found or used [16].
What to watch
- Whether GitHub adds database connection strings and Google API keys to the patterns Push Protection blocks by default.
- Any report tying abuse to keys in this LLM training corpus, the share Truffle's study does not measure.
- A rescan showing how many of the 69,041 live Google Cloud service account keys get revoked after publication.