Deleted commits matter because the hidden content can still contain valid credentials, and those credentials can still be used if the account or token remains active. Security teams need to treat commit deletion as a code-history event, not as proof that the secret lifecycle is closed.
Why deleted commits still matter in security investigations
Deleted commits can preserve the same risk as any other leaked code artifact because Git history, forks, caches, mirrors, and local clones may still expose the content even after a branch rewrite or force-push. For security teams, deletion changes visibility, not necessarily exposure. If the commit ever contained a credential, the practical question is whether that secret was rotated or revoked.
The key issue is that code history is part of the control surface. A removed commit may no longer be easy to find in the primary repository, but it can still be recoverable in a range of places that defenders do not fully control. That is why security review should treat secret exposure in Git as an incident, not a housekeeping issue.
In practice, the deleted object matters because it may have been indexed, replicated, or copied before removal. A token, API key, SSH key, or certificate embedded in a commit can remain useful to an attacker until the underlying identity or secret is invalidated. If the secret is still accepted by a live service, the deletion event does not reduce the operational blast radius.
Why deletion is not the same as revocation
Git deletion removes a pointer, not the trust relationship created when the secret was exposed. That distinction is what security teams need to preserve in triage. The commit may be gone from the main branch, but the credential it revealed is still governed by its own lifecycle. If the account, key, or token remains active, the exposure is still actionable.
This is especially important when the commit contained credentials for deployment, cloud administration, CI/CD, or third-party services. Those credentials are often long-lived, reused, or embedded in automation, which means one leaked value can unlock more than one system. The event therefore has both confidentiality impact and access-control impact, even if the repository appears clean afterward.
Tools and processes that focus only on the latest branch state can miss the real security question: whether the exposed secret was ever made unusable. The most reliable response is to pair repository cleanup with access review, rotation, and verification that the old value no longer authenticates anywhere it was accepted.
What security teams should inspect after a deleted-secret event
Deleted commits should trigger a history and exposure review, not just a code-review cleanup. Teams should inspect whether the content was copied into forks, pull requests, build logs, developer laptops, backup systems, or package artifacts. If the secret reached any of those locations, deletion from the origin repo is only one part of the containment work.
- Confirm what type of secret was exposed and what systems it can access.
- Rotate or revoke the secret before treating the incident as closed.
- Check for reuse of the same value in other repositories or environments.
- Validate whether the commit was replicated into mirrors, forks, caches, or logs.
- Retain evidence of the deletion, rotation, and access review for incident records.
Security teams also need to watch for false reassurance. A deleted commit can look like remediation when the real issue is still live access. If the secret was embedded in automation, the team should verify that replacement credentials were deployed cleanly and that dependent jobs did not fall back to the old value. EmeraldWhale Git config credential theft shows how exposed Git content can lead directly to credential abuse, while CI/CD pipeline exploitation case study shows how exposed repository material can be turned into a broader takeover path. Millions of Misconfigured Git Servers Leaking Secrets reinforces the scale of this exposure when Git content is left accessible.
Risk and Threat Considerations
Deleted commits are a security risk because adversaries do not need the commit to remain visible in the primary repo, they only need one surviving copy of the secret. Once a valid credential has escaped into history, the attacker can use it until rotation or revocation breaks it, even if defenders believe the repository has been cleaned up.
Failure mechanism: The secret survives in a fork, clone, cache, log, backup, or external index after the commit is deleted, and the active credential continues to authenticate.
Impact: Attackers can access source control, cloud resources, or deployment systems, and defenders may underestimate the blast radius because the original commit no longer appears in the main branch.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Deleted commits expose credentials that still need lifecycle control and revocation. |
| Recommendation — Rotate and revoke exposed credentials immediately, then verify all dependent systems reject the old value. | ||
| CIS Controls v8 | CIS-5 — Account Management | Leaked secrets can remain active until accounts and service access are removed or changed. |
| Recommendation — Review exposed secrets against active accounts and remove any unnecessary access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The question is about secrets persisting after code history deletion and remaining usable. |
| Recommendation — Treat leaked repository secrets as an incident and invalidate the exposed material, not just the commit. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Deleted commits can still leak credentials that attackers later abuse. |
| Recommendation — Hunt for exposed credentials across repos, logs, and artifacts, then contain and rotate them. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | Deleted commits affect authentication material management and access control outcomes. |
| Recommendation — Enforce credential rotation and verification when source history exposes authentication material. | ||
Practitioner Guidance
What to verify: Treat the deletion event as evidence handling plus access handling. Verify that the exposed secret has been revoked or rotated, that dependent systems no longer accept the old value, and that the same material does not exist elsewhere in the repository history or supporting tooling.
Decision rule: If the deleted commit contained a credential capable of authenticating to any production or privileged system, prioritise secret invalidation and scope assessment before you spend time on repository cleanup. Cleanup without revocation leaves the useful part of the exposure intact.
Practitioner takeaway: The security signal is not whether a commit was deleted, but whether the secret it exposed can still be used; until that answer is no, the incident is not over.
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 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org