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.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Git, History, and Hidden Mistakes: Why Deleting a Commit Isn't Enough”.
Key questions
Q: What should teams do first when a secret has already been committed to Git history?
A: Revoke or rotate the secret immediately and treat the credential as compromised, even if the bad commit has been removed from the latest branch.
Q: Why does deleting a commit not fully remove an exposed secret?
A: Because Git preserves earlier snapshots, and the secret can still exist in parent commits, dangling objects, forks, or archived event data.
Q: What signs suggest a Git secret leak may still be active after cleanup?
A: A lingering commit hash in a fork, a clone made before the force push, or preserved push metadata can indicate the exposure still exists outside the origin repository.
Practitioner guidance
- Treat any committed secret as compromised Revoke or rotate the credential immediately after discovery, even if the offending commit has been removed from the branch tip.
- Rewrite history only after revocation Use history-rewriting tools to remove the object from reachable Git history, then force-push the cleaned branch and tags.
- Check forks and cloned copies Ask collaborators to re-clone the repository and investigate forks, mirrors, and any CI or GitHub workflow logs that may still contain the hash or secret material.
Bottom line: Git history can keep secrets reachable after deletion, so removing a file or rewriting a branch does not restore credential safety.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 3:18 am
Git history creates exposure persistence, not just version control. Once a secret is committed and pushed, the governance problem changes from file removal to credential lifecycle control. Branch cleanup, force-pushes, and commit rewriting may hide the secret from normal views, but they do not guarantee that every copy, fork, or log has disappeared. The practitioner conclusion is simple: history is not a safe hiding place for secrets.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should organisations govern secret exposure across Git, forks, and archives?
A: Use an NHI lifecycle approach that ties secret ownership to revocation, rotation, and offboarding of the underlying credential. The control boundary is the exposed secret and every copy of it, not the repository where it first appeared.
👉 Read our full editorial: Git history exposes secrets long after deletion on GitHub
This post was modified 1 day ago by NHI Mgmt Group