Notifications
Clear all
Topic starter
06/06/2026 1:56 am
TL;DR: Git preserves commit history, dangling objects, and forked copies long after a secret is deleted, so a removed commit can still expose credentials if it was ever pushed to GitHub, according to Oasis Security’s analysis. The governance problem is not deletion but exposure management: once a secret enters Git history, it should be treated as compromised.
NHIMG editorial — based on content published by Oasis Security: Git, History, and Hidden Mistakes: Why Deleting a Commit Isn't Enough
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: What breaks when a secret is deleted from Git but not rotated?
A: Deletion only removes the latest visible copy.
Q: Why do Git-based secrets create lasting NHI risk?
A: Git preserves history by design, which means a committed token can survive long after the file is gone.
Q: What do teams get wrong about force-pushing a cleaned branch?
A: They often assume force-push removes all risk.
Practitioner guidance
- Rotate the exposed secret immediately Revoke the credential as soon as the commit is discovered, and treat every committed secret as compromised even if the file has been deleted from the latest branch.
- Rewrite repository history with a scrub tool Use a history-rewriting tool such as git filter-repo or BFG Repo-Cleaner to remove the secret from commit objects, then force-push the cleaned history only after validating the rewrite.
- Inventory forks, clones, and mirrors Identify upstream forks, developer clones, and any mirrored repositories that may still retain the old commit, then notify owners to re-clone from the cleaned source.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of git rm, git reset, and force-push behaviour in real repositories
- Practical guidance on using git filter-repo and BFG Repo-Cleaner to remove secrets from history
- How GH Archive and GitHub event data can preserve commit hashes after branch cleanup
- The vendor's secret scanning and identity-correlation workflow for mapping leaked credentials to NHIs
👉 Read Oasis Security's analysis of why deleted Git commits can still expose secrets →
Git history and leaked secrets: why deleting a commit fails?
Explore further
06/06/2026 3:18 am
Git history creates identity persistence debt: Once a secret is committed, the exposure outlives the visible file state. Git’s object model preserves prior snapshots, so the credential’s lifecycle is no longer tied to the application’s current codebase. For NHI governance, that means the control problem is not hiding the latest copy. The practitioner implication is to treat source control as an identity-bearing system that must be covered by lifecycle, detection, and revocation discipline.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which makes secret-to-identity mapping and owner attribution harder to sustain at scale.
A question worth separating out:
Q: How should organisations respond when a secret appears in Git history?
A: They should treat the secret as already exposed, revoke it, rewrite the repository history where possible, and check for forks or mirrors that may preserve the old commit. Source control cleanup is necessary, but secret rotation is the control that matters most.
👉 Read our full editorial: Git history exposes secrets long after deletion on GitHub
