Git commits that are no longer part of an active branch but can still be recovered from repository history, pull request refs, or provider APIs. For security teams, these commits matter because sensitive material may remain accessible long after a developer believes it has been removed from the codebase.
Expanded Definition
Deleted Git commits are commits that no longer sit on an active branch, yet may remain reachable through reflogs, pull request metadata, forked copies, mirrors, provider APIs, or cached repository objects. In security terms, “deleted” often means removed from normal developer workflows, not erased from every place the data may still exist.
The boundary that matters is persistence, not visibility. A commit can disappear from the branch history a team reviews every day and still be recoverable by anyone with the right repository access, retained artifact, or platform-level record. That is why deleted commits are best understood as a source of residual exposure rather than as proof that sensitive material is gone.
Definitions vary slightly across Git hosting platforms because retention, garbage collection, and API access differ, but the practical security interpretation is consistent: deletion from a branch is not equivalent to sanitisation. For a deeper NHI and secret-lifecycle lens, the OWASP Non-Human Identity Top 10 is useful because it frames how machine credentials and other secrets remain exploitable after they are “removed” from intended locations.
Examples and Use Cases
In real environments, deleted commits show up whenever teams try to clean up a mistake after the fact. The commit may be gone from the branch tip, but the sensitive content can still exist in places that preserve historical state or event metadata.
- A developer removes an API key from the latest commit, but the earlier commit remains reachable through repository history or an open pull request reference.
- A security team force-pushes rewritten history, yet a fork or mirror still contains the old commit containing a private token.
- A provider API continues to surface the commit object for a period even after branch deletion, which preserves searchability for internal or external actors with access.
- A release or build pipeline has already cloned the repository, so the deleted commit survives in CI caches, local clones, or exported artifacts.
The tradeoff is speed versus certainty: history rewriting can quickly reduce casual exposure, but it does not guarantee immediate eradication across every copy, replica, or retention layer. In practice, teams often need both repository cleanup and downstream secret revocation.
NHIMG research shows how often this problem becomes material: Millions of Misconfigured Git Servers Leaking Secrets illustrates why repository history and exposed Git services remain a recurring source of secret discovery.
Security Implications
Deleted commits create a false sense of closure. If sensitive material was ever committed, removal from the visible branch does not necessarily stop credential use, search discovery, or later recovery by an insider, a downstream integration, or an attacker who already obtained repository access.
Failure mechanism: Git objects, reflogs, forks, mirrors, and hosting-provider retention can preserve commit data long after the branch is rewritten. If the secret remains valid, the security failure is not the deletion event itself but the gap between code removal and credential revocation.
Impact: The practical consequence is prolonged exposure of tokens, keys, or certificates, along with uncertainty about whether every copy has been purged. That can turn a one-time mistake into a durable access path, especially when organisations rely on commit deletion instead of credential rotation and access review.
NHIMG’s research notes that 91.6% of secrets remain valid five days after notification, which is a strong indicator that cleanup is frequently slower than exposure. That gap is exactly where deleted commits become dangerous: the secret may be gone from the branch, but still alive in the environment.
Operationally, the common warning sign is a remediation ticket that says “commit deleted” without an accompanying inventory of where the content may have replicated or which secrets were rotated.
Domain and Governance Relevance
Deleted Git commits matter in NHI governance because many machine identities are embedded in code as API keys, service credentials, deployment tokens, and certificates. When those values appear in a commit, the governance problem is not only source control hygiene but also ownership of the secret lifecycle after exposure.
That changes how teams interpret remediation. The right question is not simply whether the repository branch is clean; it is whether every affected non-human credential has been identified, invalidated, and monitored for reuse. This is why deleted commits sit at the intersection of source control, secrets management, and machine-identity offboarding.
For NHI-heavy environments, commit deletion is often only a first step. Access paths may still exist in build logs, PR discussions, vendor mirrors, or automated scanners, so governance has to account for discovery, containment, rotation, and evidence of removal rather than relying on branch history alone. NHIMG’s Ultimate Guide to Non-Human Identities is a useful reference for the broader lifecycle controls that this term directly touches.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Deleted commits often retain embedded machine secrets and tokens. |
| Recommendation — Rotate any secret exposed in deleted commits and revoke the old credential immediately. | ||
| CIS Controls v8 | 3.4 — Address Unauthorized Assets | Purging exposed commit data requires finding all lingering copies and replicas. |
| 8.1 — Define and Maintain Audit Log Management | Repository history and provider records can preserve evidence after branch deletion. | |
| Recommendation — Inventory every clone, fork, cache, and mirror that may still contain the deleted commit. Retain and review repository audit trails to confirm what was exposed and when. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Attackers search code history and deleted commits for exposed credentials. |
| Recommendation — Hunt for exposed credentials in historic commits and remove any surviving access paths. | ||
| NIST CSF 2.0 | PR.DS-5 — Data at Rest is Protected | Deleted commits still expose sensitive data at rest in repository objects or caches. |
| Recommendation — Apply sanitisation and retention controls so removed secrets do not remain recoverable. | ||
Related resources from NHI Mgmt Group
- Why do deleted Git commits still matter for NHI governance?
- What breaks when a secret is deleted from Git but not rotated?
- What happens when deleted GitHub commits are not included in secret scanning?
- How should security teams scan for secrets in deleted or private GitHub commits without missing hidden attack surface?
