Deleting a secret from a file does not remove it from your repository. Git keeps history, so a key committed last month is still there in an old commit, fully readable to anyone who can clone the repo. Scanning only the current files misses it entirely.
Why "I already removed it" isn't enough
When you edit a file to delete an API key and commit, you've added a new commit — the old one with the key is untouched and still reachable. Anyone with the repository (including every fork and clone) can check out that commit and read the secret. For public repositories, assume automated scrapers found it within minutes.
What to actually do when a secret is committed
- Rotate first. Treat the credential as compromised and rotate it immediately. Removing it from history is secondary — rotation is what stops the bleeding.
- Then purge history if needed (tools like
git filter-repo), and force-push. Coordinate with your team, since this rewrites history. - Check what the secret could reach. Scope the blast radius: what did that key have access to, and was it used?
Scan history, not just the tree
A good secret scan looks at the full git history, not only the working tree. OpenRouting runs Gitleaks across history as part of a scan, so a key that was "removed" but never rotated still shows up. It also redacts secret values before anything is sent to an AI model for review — the scanner handles the secret, the model never sees it.
Prevent the next one
- Keep secrets in a secrets manager or environment variables, never in committed files.
- Add a pre-commit secret scan so leaks are caught before they're pushed.
- Scan on every push so a slip is found in minutes, not months.
The cheapest leak to handle is the one that never gets committed. The second cheapest is the one you find today instead of after an incident.