secrets in git history" how to clean up safely

"secrets in git history" how to clean up safely

TL;DR

The secret is burned the moment it reaches a remote, so rotate it FIRST, before you touch history. Then find every commit containing it, rewrite history with git filter-repo or BFG, force-push, and tell every collaborator to re-clone. Cleaning history without rotating is theater; rotating without cleaning leaves the secret sitting in the log for the next scraper.

"secrets in git history" how to clean up safely

Use this when

• An API key, password, or token got committed and pushed
• A .env file or credentials file is in the repo history
• A scanner flags a secret in an old commit
• You are doing incident response for an exposed credential

Not for this skill when

• The secret was only ever local and never pushed (just delete it and rotate to be safe)
• You need to pick secret storage going forward (use the secret-storage skill)
• You want to rotate a key that was never in git (use the rotation skill)

Steps

1. Rotate the secret immediately, before anything else

Assume it is compromised from the second it hit the remote. Issue a new credential in the provider dashboard or vault, update the running services to use it, and revoke the old one. Do this before rewriting history, because history rewriting takes time and the secret is live until revoked.

vault kv put secret/myapp api_key [paste the new key value here]

Expected: the new credential is live in your secret store and the old one is revoked at the provider. Until this is done, every other step is cosmetic.

2. Find every commit that contains the secret

Scope the damage: files, commits, branches. A secret often lands in more than one commit.

gitleaks detect --source . -v

Expected: a list of findings with commit SHAs and file paths. Also check: CI logs that echoed it, forks of the repo, and any mirrors; those are outside your push and need separate handling.

3. Rewrite history to remove it

Use git filter-repo or BFG Repo-Cleaner on a fresh clone, and warn every collaborator a force-push is coming.

git clone [repo-url] cleanup-clone && cd cleanup-clone && git filter-repo --strip-blobs-with-ids $(git rev-list --objects --all | grep "[leaked-filename]" | cut -d' ' -f1)

Expected: filter-repo reports rewritten commits and the leaked file no longer appears in git log --all -- [leaked-filename]. For secret strings inside files (rather than whole files), use filter-repo's replace-text mode with a replacements file listing the secret pattern and its replacement.

4. Force-push and clean the remote

Push the rewritten history, then expire the remote's reflog and run garbage collection so the old objects actually die. Old commits linger on the remote until GC runs.

git push --force --all && git push --force --tags

Expected: the remote now matches your rewritten history. Follow up in the hosting provider's settings or support to expire cached refs; on GitHub, old commit SHAs can stay reachable by direct URL for a time even after a force-push.

5. Tell collaborators to re-clone and check the stragglers

Everyone with a clone must re-clone; merging an old clone back reintroduces the secret. Then check forks, CI logs, image layers, and backups for copies.

git log --all -S "[ distinctive fragment of the secret ]" --oneline

Expected: no output. If a fragment still shows up anywhere (fork, log, image), treat that copy as still-live and rotate again if you have any doubt.

Variant: accidentally committed .env

Same flow, and BFG is the fastest path for whole-file removal: bfg --delete-files .env on a mirror clone, then force-push. Afterward add .env to .gitignore and enable push protection so it cant happen again.

Variant: remove api key from git history

If the key was in one commit and you caught it fast: rotate, then filter-repo replace-text for the key string across all refs. Speed matters less than completeness; one missed branch means the key is still in the repo.

Variant: bfg repo cleaner secrets

BFG's --replace-text takes a file of literal replacements; run it on a --mirror clone. Faster than filter-repo on huge repos; either works for secret removal.

Why this happens

Git never forgets: every commit is content-addressed and every clone carries full history, so a secret pushed once is copied to every fork, every CI checkout, and every backup. Deleting the file in a new commit just adds a commit; the secret sits in the parent. Only history rewriting plus rotation actually ends the exposure.

Edge cases and pitfalls

• Rotating after cleanup instead of before: the window between push and rotation is when scrapers strike; always rotate first.
• Forks and mirrors you dont control: you cannot force-push someone else's fork; ask them to delete it, and rotate anyway.
• CI logs: build logs echo env vars more often than you think; scrub or delete the affected builds.
• Commit SHAs cached by URL: hosting providers may serve old commits by SHA after a force-push; confirm expiry.
• Stale clones pushed back reintroduce everything; require fresh clones, not pulls.
• Secrets in multiple repos: the same key often lives in two repos; inventory all of them before declaring victory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gAYgodx728GnqJ3-URgr0w