API Key Leaks on GitHub: What the Data Shows

GitGuardian's annual State of Secrets Sprawl report is the most comprehensive dataset on credential leakage available publicly. The 2026 edition (covering 2025 activity) found 29 million new secrets detected across public GitHub commits - up from 12.8 million in 2022. The growth is not slowing.

The report scans all public commits in real time. It does not scan private repositories, meaning the 29 million figure is a floor, not a ceiling. Internal research from GitGuardian suggests private repositories contain roughly 4× the density of secrets found in public repos - developers are more careless when they believe code is not publicly visible.

The most commonly leaked credential types in 2025:

The majority of leaks are not caused by deliberate carelessness. They fall into five patterns:

GitGuardian runs automated detection against the GitHub event stream in real time. Their data shows the median time between a secret being pushed to a public repository and the first external use of that secret is 8 minutes. For high-value keys (AWS, OpenAI, Stripe), the median is lower.

This is because the attacker is also automated. Several well-documented botnets continuously monitor the GitHub public event API (the same API that powers GitHub's own notifications). When a commit is pushed, the bot downloads the diff, runs regex against it, and attempts to use any matched credential within seconds. The bot does not care if the commit is immediately reverted. Reverting a commit does not remove the key from git history, and the bot already has a copy.

The important observation here is that detection-and-response is too slow. By the time any notification reaches a developer, the exploit window has already been active for at least 30 minutes. The only effective controls are pre-exposure (preventing the key from being committed) orexposure-tolerance (ensuring the leaked credential is worthless).

79% of leaked secrets are still valid five days after detection. This figure is high because most developers do not know their key was leaked, or they believe that deleting the file and pushing a new commit is sufficient remediation. It is not.

Deleting a file in a git commit only removes it from the working tree. The file still exists in every prior commit. Anyone who clones the repository and runs git log -p can see every version of every file, including the deleted one with the key.

Proper removal requires rewriting git history with git filter-repo (the modern replacement for git filter-branch) and force-pushing. Even then, GitHub caches content via its API, and any fork or clone taken before the rewrite still contains the secret. For any key that was ever in a public repo - even briefly - treat it as permanently compromised and rotate immediately.

# Install git-filter-repo
pip install git-filter-repo

# Remove a specific file from all history
git filter-repo --path .env --invert-paths

# Force push (coordinate with your team first)
git push origin --force --all

# IMPORTANT: Rotate the key regardless.
# History rewriting is not a substitute for rotation.

GitGuardian's 2026 data introduced a new finding: commits generated with AI coding assistant assistance leak secrets at approximately 2× the baseline rate. The mechanism is not fully understood, but several factors are likely contributors:

• ▸AI assistants autocomplete credential placeholders using values from context - clipboard, open files, or recently pasted content. Developers accept suggestions without auditing every line.
• ▸AI-assisted commits tend to be larger (more files, more context) - larger commits are harder for the developer to review before pushing.
• ▸AI tools sometimes generate boilerplate with hardcoded example values that look like real keys but use formats identical to live credentials.
• ▸Developers using AI tools often move faster and skip manual review steps, reducing the likelihood of catching a committed secret before push.

The practical implication: if your team uses AI coding tools, pre-commit scanning is more important, not less. The Gitleaks pre-commit hook runs in under a second and catches most credential patterns before they leave the developer's machine.

The key insight from GitGuardian's dataset is that detection-and-response is a losing strategy for credential leaks. The exploit window is shorter than the detection-to-response cycle by a factor of 5–10×.

The two strategies that actually work are:

Prevention and exposure tolerance are complementary, not alternatives. Prevention reduces the attack surface; exposure tolerance ensures that the residual risk from prevention failures has zero consequence.