If a scan finds credentials in a target's git history, the fix is to revoke and rotate them, not to rewrite history. A removed commit does not make a leaked key safe, because copies and clones may exist. Rewriting history can come later, as clean up. Rotation comes first.
Why history matters
Git keeps every commit. A developer who commits an API key and deletes it the next day has left it in the history for anyone with read access, including forks and local clones. GitHub's secret scanning documentation says its scanning covers the entire git history on all branches, plus issues, pull requests, discussions and wikis, and it advises rotating the affected credential immediately. It also notes that removing a secret from history is time-intensive and often unnecessary if the credential is already revoked.
What to do during diligence
- Ask for read access or a scan result. With the seller's agreement, run a secret scanner over full history, or ask the seller to share a report.
- Classify each finding. Is it live, expired, a test value or a placeholder? Do not test live credentials against production systems without written permission.
- Ask for the rotation record. Who revoked it, when, and what did the access log show before that?
- Check scope. What could the credential reach: a single service, a cloud account, customer data?
- Look at prevention. Is there a pre-commit hook, push protection or a CI check?
Questions for the target
- How many findings were live when first detected?
- Has any credential in history ever been used from an unexpected address?
- Which systems share keys across environments?
- Who owns the secrets inventory?
Honest answers sound specific. "We have never had that problem" without a scan behind it is not an answer.
Severity table
| Finding | Priority |
|---|---|
| Live cloud or database credential | Revoke now, review logs |
| Live third party API key | Revoke, assess data exposed |
| Expired or revoked token | Note, confirm it is dead |
| Test fixture or placeholder | Ignore after confirming |
After rotation
Rewriting history with a filter tool is possible, but it breaks existing clones and does nothing about copies already taken. Do it only if there is a reason beyond the secret, such as removing a large file, and coordinate it with every contributor.
Put the real effort into prevention: push protection, short-lived credentials and a secrets manager, so the next key never reaches a commit.
Safeguard's zero-day discovery and dependency scanning cover the code and package side of diligence, and a free scan is a gentle way to start on your own repositories.
Quick check
Does deleting the file remove the risk?
No. The value remains in history and in any copy. Revoke it.
Should I rewrite history before signing?
Rotate first. Rewriting is optional clean up, and it disrupts everyone with a clone.
Sources
Last reviewed: 19 October 2026.
