Because a force push moves the branch pointer, but it does not guarantee that the old objects are gone. Dangling commits can remain recoverable for a period of time, so secrets in those commits may still be exposed even though the branch looks clean.
Why deleted commits can still expose secrets
A force push rewrites what the branch points to, but it does not instantly erase the underlying Git objects. Until garbage collection prunes unreachable data, those commits can still exist in the repository and in local clones, reflogs, backups, mirrors, and build systems that fetched them. That is why a “deleted” secret can remain recoverable even after the history looks clean.
For practitioners, the important distinction is between hiding a commit from the branch view and actually eliminating the data everywhere it was copied. A secret that was committed once may already have reached multiple caches and clones before the rewrite, so the exposure window is often broader than the visible branch history suggests. Git history surgery reduces discoverability, it does not retroactively guarantee destruction.
What makes the old commit recoverable
Git objects are content-addressed and can remain reachable through alternate references long after the branch tip moves. A commit may survive in reflogs, dangling objects, packfiles, pull caches, CI workspaces, forks, or downstream clones that have not pruned their copies. Even when the original branch no longer references the commit, anyone with a copy of the object database may still be able to inspect or restore it.
This is why history rewrite is only one part of remediation. If a secret was present in the deleted commit, you should assume it may still be retrievable somewhere unless you have verified pruning, rotation, and downstream cleanup. The practical question is not whether the commit is still on the branch, but whether the credential material has been invalidated and the exposed copies can no longer be used.
Why teams underestimate the blast radius
The common failure is treating Git as if the branch pointer is the source of truth for secrecy. In reality, exposure can persist in developer laptops, automated build agents, artifact logs, mirrored repositories, and access tokens stored in issue attachments or chat exports. That is why a secret-in-commit event should be handled as a credential incident, not just a version-control cleanup task. The remediation burden is broader than the repository rewrite itself.
When a secret reaches source control, the risk is not limited to the commit author or the active branch. Reviewers, CI jobs, dependency scanners, and anyone with repository access may already have seen or indexed the value. If the secret was high privilege, the exposure can become immediate abuse rather than a theoretical recovery risk.
Risk and Threat Considerations
Force-pushed commits matter because the objects can survive long enough to be recovered from history, clones, or recovery tooling, which means a deleted secret may still be exploitable after the branch looks clean. The risk increases when the secret grants production access, because the attacker does not need the branch to remain visible, only one surviving copy of the leaked material.
Failure mechanism: A rewrite changes references, not necessarily the lifetime of the underlying objects, and remote or local copies may continue to retain the secret until pruning and rotation happen everywhere.
Impact: Credentials, tokens, or keys may remain usable after deletion, enabling unauthorized access, lateral movement, or repeated exposure across downstream systems that cloned the repository.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Deleted commits can still expose leaked secrets in recoverable Git objects. |
| Recommendation — Rotate exposed secrets immediately and search for leaked values across reachable history and clones. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Leaked Git secrets are authenticators that must be revoked or replaced after exposure. |
| SI-4 — System Monitoring | History rewrites and secret exposure require monitoring for continued access and reuse. | |
| Recommendation — Revoke compromised authenticators and enforce lifecycle controls for secret rotation. Monitor for reuse of exposed credentials and alert on suspicious access after disclosure. | ||
| CIS Controls v8 | CIS-5 — Account Management | Recovered secrets often enable account access, so exposed credentials need rapid lifecycle action. |
| Recommendation — Disable or rotate any account material exposed in source control without delay. | ||
| OWASP ASVS | V14 — Data Protection | Secrets in source history are a data-protection failure that must be prevented and remediated. |
| Recommendation — Protect sensitive values from source control and treat leaked values as compromised data. | ||
Practitioner Guidance
What to prioritise: Treat the event as secret compromise first and repository cleanup second. Revoke or rotate any credential that appeared in the deleted commit before relying on history rewriting, because the usable secret is the real exposure.
What to verify: Confirm where the commit may have propagated, including forks, CI caches, mirrors, developer clones, and reflogs, then check that retention and pruning expectations are documented rather than assumed. A clean branch tip is not sufficient evidence that the value is gone.
Common mistake: Teams often stop after a force push and a quick scan of the main branch. That misses the operational reality that secret recovery can happen from any surviving copy, so the remediation standard must be broader than “it no longer shows up on HEAD.”
Practitioner takeaway: If a secret ever reached Git, assume it may have escaped the branch history itself, and prove containment by invalidating the secret and checking every place the old object could still exist.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 15, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org