Because Git preserves earlier snapshots, and the secret can still exist in parent commits, dangling objects, forks, or archived event data. The visible branch tip changes, but the underlying credential may remain recoverable until every copy path has been addressed and the secret itself has been replaced.
Why a deleted commit can still leave a secret reachable
Deleting a commit only moves a branch reference. It does not rewrite every place Git may have stored or replicated that content. If the secret existed in an earlier commit, merge base, reflog entry, packfile, fork, mirror, cache, or export, the credential can still be recoverable until those copies are removed and the secret is rotated.
Git’s design is append-oriented, so history is preserved unless you deliberately rewrite it. That means the security question is not whether the branch tip looks clean, but whether the exposed value has been eliminated from all reachable and semi-reachable objects. Millions of Misconfigured Git Servers Leaking Secrets is a useful illustration of how repository exposure persists beyond a single visible commit.
In practice, a secret may survive in places that ordinary developers do not inspect during cleanup. Even if the offending commit is removed from the main line, clones, CI logs, pull requests, release archives, and third-party mirrors can retain the material. That is why commit deletion and secret remediation are different tasks: one changes history pointers, the other removes the credential from every copy path.
Which Git objects and copy paths keep the secret alive?
The most important concept is reachability. A secret is fully gone only when no current reference, no orphaned object, and no external copy can still surface it. Parent commits can still contain the secret, dangling objects can remain until garbage collection, and forks or archived events can preserve the exact text even after the original repository is fixed.
This is also why token or key rotation must happen immediately after exposure. If the value was ever valid, deletion of history does not invalidate it. The Guide to the Secret Sprawl Challenge and Secrets Management Guide both reinforce the operational point that remediation is about secret lifecycle control, not only repository hygiene.
Forks are especially easy to underestimate. Once a collaborator or automated system has cloned the repository, the old commit may live outside the control of the original maintainer. Archives, caches, and logs can create the same problem, which is why secret cleanup must include discovery, revocation, and replacement rather than a single Git command.
What actually has to happen for the exposure to be closed?
The cleanup sequence has to treat the exposed secret as compromised until proven otherwise. First remove or rewrite the history in the source repository. Then invalidate or rotate the credential itself. Then search for all downstream copies, including forks, mirrors, and logs, and confirm they are purged or no longer useful. Without that second step, the secret still works even if the commit no longer does.
For practitioners, the difficult part is often not rewriting the repository, but proving that every meaningful copy path has been addressed. That includes understanding who had clone access, whether CI systems cached the file, and whether the secret was duplicated into issue trackers, chat, build artifacts, or documentation. 17,000+ Secrets Exposed in Public GitLab Repositories is a strong example of how broad the blast radius can become once a secret enters source control.
Risk and Threat Considerations
The main risk is false closure, teams may believe a deleted commit has fixed the incident while the credential still authenticates in production. That leaves a live access path for whoever copied, cloned, indexed, or archived the repository before cleanup.
Failure mechanism: Git history, forks, reflogs, packfiles, and external mirrors preserve older snapshots, so deleting a commit only hides one reference to the secret rather than invalidating the secret value itself.
Impact: Attackers or insiders may continue to use the exposed credential for repository access, API access, or lateral movement until the secret is rotated and every recoverable copy is removed.
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 CIS Controls v8, NIST SP 800-53 Rev 5 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 | Exposed secrets in Git map directly to leaked identity material. |
| NHI-07 — Long-Lived Secrets | A deleted commit still matters if the secret remains valid for a long time. | |
| Recommendation — Rotate leaked secrets and purge every recoverable copy path. Shorten secret lifetimes and replace any exposed credential immediately. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Source-control secret exposure is an application and repo hygiene failure needing secure handling. |
| Recommendation — Scan repositories continuously and block secrets before they are committed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The core issue is credential lifecycle after exposure, not just code cleanup. |
| SI-4 — System Monitoring | Detecting residual copies and reuse depends on monitoring for continued credential exposure. | |
| Recommendation — Invalidate the exposed authenticator and reissue it under controlled conditions. Monitor for secret reuse and exposure in repositories, logs, and mirrors. | ||
| OWASP ASVS | V14 — Data Protection | Sensitive values in source history are a data protection failure requiring removal and containment. |
| V16 — Security Logging and Error Handling | Recovering from exposure requires traceability across logs and build outputs where secrets may persist. | |
| Recommendation — Treat repository history as sensitive storage and prevent secret persistence. Retain enough evidence to trace where the secret was exposed and copied. | ||
Practitioner Guidance
What to verify: Confirm whether the exposed value was ever issued as a live credential, then verify rotation or revocation before you rely on any history rewrite. If the secret can still authenticate anywhere, the incident is not closed.
What to prioritise: Treat identity-bearing material with the shortest blast-radius first, especially tokens, keys, and credentials that can be reused automatically by tooling or pipelines. History cleanup is important, but invalidating the secret is the control that stops active abuse.
Practitioner takeaway: Deleting the commit is only repository housekeeping; closing the incident requires removing trust in the secret everywhere it was copied or cached.
Related resources from NHI Mgmt Group
- What breaks when organisations only delete the commit that exposed a secret?
- Should organisations prioritise revocation speed or secret storage controls first?
- What breaks when static GitHub tokens are exposed through application errors?
- How should teams govern workload onboarding without creating secret zero risk?
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 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org