What did the Truffle Security GitHub secrets research find?

Truffle Security scanned 224 million public GitHub repositories and 58 billion files as part of a research study published in July 2026. They found 543,699 unique valid credentials that were still active at the time of analysis. The median time a credential had been publicly exposed before being revoked was 784 days. The oldest still-valid credential dated to 2009. Critically, 199,843 credentials (36.8% of the total) were exposed after GitHub enabled Push Protection by default in February 2024, meaning the preventive control was in place but the exposure happened anyway, either through categories Push Protection does not cover or through repositories where the protection was disabled.

Why do npm tokens get revoked but Google Cloud credentials do not?

The difference is automated versus manual revocation. GitHub has a partnership with npm that automatically revokes npm tokens when they are detected in a public repository. The process requires no human decision. Of 101,886 npm tokens found exposed in public repositories, only 1 was still valid at the time of analysis. Google Cloud service account keys do not have an equivalent automatic revocation partnership for all key types. Of 126,963 Google Cloud service account credentials found exposed, 69,041 were still valid, a 54% active rate. The revocation gap is not because Google Cloud credentials are less visible. It is because the remediation action requires a human to decide to revoke and then take the action, while npm revocation is automated. This distinction proves that detection is not the bottleneck for the npm category. The bottleneck for Google Cloud is the manual step between detection and action.

What is the right way for organizations to manage the secrets revocation problem?

Organizations should build automated secrets revocation pipelines rather than relying on human-driven processes. For each credential type in use, the remediation path should be: detect the exposure, automatically revoke the credential, automatically rotate a replacement, and alert the owning team. For credentials where the cloud provider supports automated revocation through a GitHub partnership or webhook integration, enable that integration. For credentials where no automated path exists, build a workflow that routes the detection to an on-call owner with a defined SLA and automated escalation if unaddressed. The 784-day median exposure time in the Truffle Security research is not evidence that detection fails. It is evidence that detection without automated remediation produces an enormous backlog that manual processes cannot clear.

543,000 Working Credentials in Public GitHub Repos: Why Detection Is Not Enough

Q: Why does GitHub Push Protection still allow secrets to be exposed?

GitHub Push Protection blocks commits containing secrets in categories it is configured to detect. When GitHub enabled it by default in February 2024, it covered a defined set of credential types. The Truffle Security research found that more than half of the live credentials in their dataset fell into categories not covered by default Push Protection, specifically database connection strings and Google API keys. Additionally, developers can bypass Push Protection with a manual override in some configurations, and the protection only applies to new commits, not credentials already in repository history. Push Protection reduces new exposure in covered categories but does not address the existing inventory of exposed credentials or categories outside its detection scope.

Executive Answer

Truffle Security scanned 224 million public GitHub repositories and found 543,699 valid credentials still active at time of analysis. The median credential had been publicly visible for 784 days before revocation. One npm token out of 101,886 exposed was still valid. Sixty-nine thousand out of 126,963 exposed Google Cloud service accounts were still valid. The difference is automated revocation versus a manual process that does not scale. The research proves that detection is not the problem for most credential categories. Revocation is. Organizations investing in more scanning are solving the wrong half of the problem.

Key Numbers

543,699 — Unique valid credentials still active at time of analysis across 224 million scanned GitHub repositories.
784 days — Median time a credential was publicly exposed before being revoked. More than two years.
2009 — Year the oldest still-valid credential was first exposed. It remained active as of July 2026.
36.8% — Share of live credentials (199,843) that were exposed after GitHub enabled Push Protection by default in February 2024.
1 / 101,886 — npm tokens still valid out of those found exposed. Automated revocation works.
69,041 / 126,963 — Google Cloud service accounts still valid out of those found exposed. Manual process does not work at scale.

One credential versus sixty-nine thousand. Both exposed publicly on GitHub. Both available to anyone who searched.

The difference is not scanning. Both npm tokens and Google Cloud service account keys are detected by secrets scanning tools. The difference is what happens after detection. For npm tokens, GitHub's partnership with the npm registry triggers automatic revocation the moment a token is detected. The human never needs to act. For Google Cloud service accounts, the detection creates an alert. Then a human must decide to revoke, find the right service account, confirm the credential is the one exposed, assess the potential impact of revoking it, and execute the revocation. At scale, across hundreds of developers and thousands of repositories, that process fails.

Truffle Security published this analysis in July 2026 after scanning 224 million public GitHub repositories and 58 billion individual files. The scale of the dataset makes the findings statistically significant. The credential counts are not projections. They are the result of validation checks run against live provider APIs at the time of the scan. Every one of the 543,699 credentials returned a successful authentication response.

Why Push Protection Did Not Close the Gap

GitHub enabled Push Protection by default in February 2024. The announcement was framed as a major step toward eliminating secrets from public repositories. And it is a meaningful control. For the credential types it covers, Push Protection stops the commit before it reaches the repository.

But 199,843 credentials in the Truffle Security dataset, over a third of the total, were exposed after February 2024. Push Protection was running. The credentials got through anyway.

The reason is scope. Push Protection covers the credential types GitHub has integrated with provider partners. Database connection strings and Google API keys, two of the largest categories in the live credentials dataset, are not in the default coverage set. A developer who commits a PostgreSQL connection string with embedded credentials will not be blocked. A developer who commits a Google Maps API key will not be blocked. These categories account for more than half of the live credentials Truffle Security found.

There is also a reduction in coverage that went underreported. After GitHub enabled Push Protection by default, the number of credential types in its covered categories dropped by 53%. The default-on protection covers fewer types than the opt-in version previously did. Organizations that assumed they were getting broader coverage when the default changed were actually getting narrower coverage on a larger installed base.

The npm Proof of Concept

The npm result is the most important finding in the research, and it is not receiving enough attention.

101,886 npm tokens were found exposed in public GitHub repositories. One was still valid at the time of analysis. That is a revocation rate of 99.999%. The detection mechanism for npm tokens is not meaningfully better than the detection mechanism for Google Cloud service accounts. Both are detectable by secrets scanners. Both show up in the same repositories. The near-perfect revocation rate for npm tokens exists because the revocation is automated. GitHub detects the token, calls the npm API, the npm registry revokes the token. No human decision required.

Compare that to Google Cloud. 126,963 service account credentials exposed. 69,041 still valid. The 54% active rate does not mean Google's detection is worse. It means the path from detection to revocation requires human action that does not happen fast enough, or at all, for most exposed credentials.

This is the clearest possible evidence that the secrets management problem is not a detection problem. It is a remediation automation problem.

The 784-Day Number Is an Organizational Failure

A credential exposed for 784 days is not a detection failure. No detection system can claim to catch something and then take 784 days to act on it. The number reflects what happens when detection produces alerts that require manual remediation and no one is accountable for closing them.

The lifecycle of an exposed credential in a manual process typically looks like this. Secrets scanning detects the exposure and creates a ticket or alert. The ticket is routed to the owning team based on the repository owner. The owning team reviews the credential, assesses whether it is still in use, tries to determine what the credential accesses, evaluates the risk of revoking and rotating it versus the risk of leaving it. If the credential is connected to a production system, the team escalates for review. The escalation sits in a queue. Three weeks later, someone follows up. The credential is still valid. The team says they are planning to address it in the next sprint.

Multiply that by hundreds of findings per month across a large organization and you get the 784-day median. Not negligence. Process failure at scale.

What CISOs Need to Build

Audit your current secrets revocation pipeline. For each credential type your organization uses, document the path from detection to revocation. Is it automated, or does it require human decision? How many days does the manual path take on average? How many open findings are currently unresolved? The answers tell you where the bottleneck is.

Enable GitHub's partner integrations for automated revocation. GitHub has established revocation partnerships with a growing number of providers. npm is the most mature example. For all providers where an automated revocation integration exists, it should be enabled by default. This is the single highest-leverage configuration change available for secrets management programs.

Build automated revocation workflows for credentials without partner integrations. For Google Cloud service accounts, AWS IAM keys, and other credential types without automated revocation, build a workflow that triggers on detection, immediately disables the credential via API, creates a replacement, and notifies the owning team. The goal is to reduce time-to-revocation from days or weeks to minutes, without requiring a human approval step for standard credential types.

Extend Push Protection coverage beyond defaults. GitHub's default Push Protection covers a subset of credential types. Configure additional patterns for the credential types your organization uses that are not in the default set, including database connection strings, internal API keys, and service account credentials for any cloud provider or internal system. Custom patterns can be added at the organization level.

Inventory historical exposure, not just new commits. Push Protection stops new exposure. It does not address credentials already in repository history. Run a one-time scan of your entire repository history using a secrets scanning tool, triage every live credential found, and revoke them. This is the remediation for the backlog. The ongoing program addresses new exposure.

Measure time-to-revocation, not just detection count. Most secrets management programs measure how many exposed credentials were detected. That metric reflects detection capability. The metric that reflects security posture is how quickly detected credentials are revoked. If your average time-to-revocation is more than 24 hours for any credential type, you have a process problem, not a tooling problem.

Asaf's Take

The comparison between npm and Google Cloud in this research is one of the clearest data points I have seen on the difference between security controls that work and security controls that look like they work. Both categories are detectable. Both are detected. One has a 99.999% revocation rate. The other has a 46% revocation rate. The variable is not the scanning tool. It is whether the path from detection to remediation requires a human decision or not. CISOs who are evaluating their secrets management program should ask one question: for each credential type, if it appears in a public repository right now, how long does it take to stop being valid? If the honest answer is "it depends on who sees the alert and whether they have time to act," then the program has a structural gap that additional scanning will not close.