Detecting and Remediating Leaked API Keys in Git Repositories

Published April 6, 2026 · Reading time approx. 6 minutes

API keys, passwords, cryptographic secrets — they end up in Git repositories all the time. Usually by accident. And once they're in the history, they stay there, accessible to anyone who knows where to look. This article covers how to find leaked secrets, respond correctly, and prevent future leaks. The recommendations draw on a study with 14 developer interviews and a survey of 109 practitioners, presented at USENIX Security 2023 (Krause et al.).

What Are Code Secrets — and How Do They End Up in Repositories?

Code secrets are credentials living in source code or config files: API keys, database passwords, OAuth tokens, SSH keys, private keys, cloud credentials like AWS Access Keys. They all share one thing: whoever has them, has access.

How they end up in a repository is almost always mundane. A .env file without a .gitignore entry. A tutorial credential that got replaced with a real one. A password added for local testing that nobody removed. No malice — just everyday software development.

Our study confirms it: most developers know the risk. What's missing are systematic processes. Instead of automated tools, many rely on manual reviews and ad-hoc checks.

How Did 39 Million Secrets Leak in a Single Year?

GitHub detected over 39 million secrets in repositories in 2024. The major platforms scan millions of commits daily and consistently find exposed credentials.

What happens after a leak depends on the secret. A telemetry key is annoying. A database password with access to customer data triggers GDPR reporting obligations. Leaked cloud credentials can rack up five-figure costs within minutes — crypto-mining on someone else's tab is a popular business model. And compromised CI/CD tokens? They open the door to supply chain attacks.

In our survey, a significant share of the 109 developers admitted to having committed secrets themselves — or witnessed it on their team. Many underestimate how often it happens.

Why Do Automated Scanners Beat Manual Reviews?

Finding leaked secrets requires tooling. Manual searching doesn't cut it — our study data backs this up. At the time of the study, very few developers used automated scanners, even though they're significantly more effective.

Automated Scanners

• git-secrets (AWS): Checks commits, messages, and merges against prohibited patterns.
• TruffleHog: Scans the entire Git history for high-entropy strings and known formats.
• GitHub Secret Scanning: Checks against 200+ token formats automatically and notifies the provider.
• GitGuardian: Commercial real-time monitoring.
• Gitleaks: Open source, integrates well into CI/CD pipelines.

Pre-Commit Hooks

The best time to catch a secret is before it enters the history. Pre-commit hooks using git-secrets, gitleaks, or the pre-commit framework do exactly that.

Code Reviews

A complement — not a replacement. Reviewers should watch for hardcoded credentials and suspicious strings, but shouldn't count on catching every leak.

Why Isn't Deleting Enough After a Leak?

A common mistake: the file containing the secret gets deleted and a new commit is pushed. Problem solved? No. The secret is still sitting in the Git history, fully accessible.

Immediate Steps

1. Revoke the secret. Deactivate or rotate the key with the provider. This is the most urgent step — everything else can wait.
2. Generate a new secret and store it properly (secret manager, not a Slack message).
3. Check access logs: Has the secret been exploited already?

Our study found that many developers only delete the file after a leak — without revoking the secret itself. The actual risk stays wide open.

Cleaning the Git History

Two established tools:

• BFG Repo-Cleaner: Fast, simple, removes sensitive data from the entire history.
• git filter-repo: Successor to git filter-branch, for targeted removal of files or text patterns.

After cleanup, every team member needs to re-fetch their clone. For public repos: assume the secret has been copied. Revocation isn't optional.

Prevention

Get Secrets Out of the Code

Secrets belong in environment variables or a secret manager — not in source code. Common options:

• HashiCorp Vault: Access control, audit logging, automatic rotation.
• AWS Secrets Manager / Azure Key Vault / Google Secret Manager: Cloud-native solutions.
• .env + .gitignore: For local development, as long as the .env stays excluded reliably.

Configure .gitignore Properly

Sounds trivial. Gets forgotten anyway. .env, *.pem, *.key, credentials.json, *.p12 — all of them. Use templates from github/gitignore and check on every new project.

Pre-Commit Scanning

Set up secret scanners as pre-commit hooks. Add server-side checks in the CI/CD pipeline. Two safety nets catch more than one.

Security Culture

Technology alone won't fix this. What helps: regular training, clear policies, security champions in teams — and a culture where reporting a leak isn't a stigma. Our study shows that organizations with established security policies do significantly better at prevention.

Conclusion

Secret leakage isn't a fringe problem. Four takeaways:

1. Prevent, don't react. Secret managers, .gitignore, pre-commit hooks.
2. Automate. TruffleHog, Gitleaks, GitHub Secret Scanning — don't rely on manual reviews alone.
3. Respond correctly. Revoke, clean the history, assess the damage. Deleting isn't enough.
4. Build culture. Tools only work where secret management is part of the security mindset.

Full study: Krause et al., "Pushed by Accident", USENIX Security 2023.

This article is an AI-generated summary of the scientific publication "Pushed by Accident: A Mixed-Methods Study on Strategies of Handling Secret Information in Source Code Repositories" (USENIX Security 2023). The content has been editorially reviewed.

Want to secure your development processes against secret leakage? Contact me for a consultation. I analyze your current processes and help implement automated protection measures.