The branch can look clean while the old commit objects still exist in a hidden part of the repository’s history. That creates a mismatch between operational reality and security reality. Teams may believe the secret is gone, but anyone who can locate the dangling commit may still retrieve the exposed data and use it until the secret is rotated.
Why This Matters for Security Teams
A force-push can make a repository look fixed while the leaked object still exists in GitHub’s object store or reachable history. That gap matters because attackers do not need the commit to stay on the main branch to exploit it; they only need a path to recover the blob before rotation occurs. NHIMG’s research on secrets exposure shows why this is not a theoretical edge case: the average estimated time to remediate a leaked secret is 27 days, even though confidence in secrets management is often high. See The State of Secrets in AppSec for the broader remediation picture.
For security teams, the real risk is false closure. A clean branch, a reverted PR, or a rewritten commit history can create the impression that the incident is over when the exposed secret may still be valid. That means incident response must treat history rewriting as a hygiene step, not a containment step. Secrets must be rotated, access reviewed, and downstream caches, forks, and mirrors considered before declaring the exposure closed. In practice, many teams discover the lingering commit only after the secret has already been replayed from another location.
How It Works in Practice
When a leaked commit is force-pushed out of the main branch, Git updates the branch pointer, but the old commit object may remain in the repository until GitHub’s garbage collection and retention processes eventually remove it. In the meantime, anyone who knows the SHA, has a local clone, or can find the object through refs, forks, or cached views may still retrieve the exposed content. This is why history rewrite is not a substitute for secret invalidation.
Operationally, teams should assume the secret is compromised as soon as it appears in any commit, even if that commit is later removed from the visible branch. A practical response usually includes:
- Rotate the exposed secret immediately, rather than waiting for repository cleanup.
- Search the full repository history, not just the current branch tip.
- Check forks, mirrors, CI logs, and developer clones for copies of the commit or secret.
- Verify whether the token, key, or certificate had scopes broad enough to affect other systems.
- Record the incident as a secret exposure event, not merely a Git mistake.
GitHub’s own guidance on recovering from a compromised secret emphasises revocation and replacement over history editing, and NHIMG’s Guide to the Secret Sprawl Challenge explains why duplicated credentials often outlive the original leak. This is also where supply chain incidents become relevant: once a secret has appeared in code, automation may have copied it into build systems, logs, or deployment artifacts. These controls tend to break down when repositories are mirrored into multiple environments because the leaked object can persist outside the branch that was force-pushed.
Common Variations and Edge Cases
Tighter cleanup often increases response overhead, requiring organisations to balance fast history rewriting against the operational reality of distributed copies. In some cases, a force-push is enough to hide the commit from casual view, but current guidance suggests that teams should not rely on that alone unless they can prove the secret never propagated elsewhere.
There is no universal standard for how long GitHub retains unreferenced objects in every situation, so practitioners should treat retention as uncertain rather than assume immediate deletion. Forks are a common edge case: a commit removed from the upstream branch may still be present in a fork owned by a contractor, automation account, or open-source contributor. Another edge case is a secret embedded in a commit message, build output, or issue tracker reference, which can preserve the exposure even after the commit body is rewritten.
For that reason, the correct response is layered: revoke first, then investigate reachability, then confirm eradication across all repositories and downstream systems. A history rewrite is helpful for reducing exposure surface, but it does not by itself prove the secret is gone.
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 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers exposed non-human credentials that remain usable after history rewrite. |
| NIST CSF 2.0 | RS.MI-1 | Incident mitigation requires containment and recovery after a code leak. |
| NIST AI RMF | Risk management must account for residual exposure after repository state changes. | |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero trust limits reliance on repository visibility as proof of safety. |
| NIST SP 800-63 | Leaked secrets are authentication materials that should be reissued after exposure. |
Rotate the leaked secret immediately and validate every place the credential may have been copied.
Related resources from NHI Mgmt Group
- What happens when phishing resistant authentication is only rolled out to some employees?
- What breaks when a Composer package uses eager autoloaded files and a tag is force-pushed to a malicious commit?
- What happens when SAML assertions are accepted without matching the service provider configuration?
- What do teams get wrong about proving the impact of a leaked key?
