When deleted commits are excluded, organisations keep a hidden attack surface. Secrets can remain discoverable in commit objects that are no longer visible in standard history views but are still retrievable through repository object enumeration. That gap leaves teams unable to prove exposure is gone, which weakens incident response, remediation verification, and long-term secret governance.
Why Deleted GitHub Commits Matter to Secret Exposure
When deleted commits are omitted from secret scanning, the repository can look clean while sensitive material still exists in reachable Git objects. That creates a false sense of remediation because the secret may no longer be obvious in the web UI, but it can still be recovered by anyone who can enumerate objects, access forks, or inspect retained history. For secret governance, the problem is not only exposure, but also the inability to prove that exposure has actually been removed.
This is especially important because secrets are often long-lived outside the place they were first found. NHIMG research on The State of Secrets Sprawl 2025 shows that 15% of commit authors have leaked at least one secret in their contribution history, which helps explain why deleted history still matters operationally. In practice, teams usually discover the gap only after they have already rotated a credential and assumed the repository was clean.
How Secret Scanning and Deleted History Interact
Secret scanning is most useful when it evaluates the full set of repository contents that can still be reconstructed, not just the commits visible in the default branch view. If deleted commits are excluded, the scanner may miss secrets that remain in unreachable or partially reachable objects, rewritten history, stale refs, mirrored repositories, or forks. The result is an incomplete verdict: a secret can be marked as resolved in one place while still being retrievable elsewhere in the Git data model.
That matters because Git history is not a simple linear log; it is an object graph. Removing a commit from the branch tip does not automatically remove the object from every clone, cache, fork, backup, or retention layer. A competent remediation workflow therefore needs two checks: whether the secret was rotated, and whether the repository state that contained it is still discoverable.
- Use scanning that covers deleted or rewritten commits when the goal is exposure verification.
- Confirm that forks, mirrors, CI caches, and backup snapshots are also considered during cleanup.
- Treat commit deletion as a hygiene step, not as proof that the secret is no longer recoverable.
The OWASP Non-Human Identity Top 10 is useful here because the exposed material is often a token, key, or machine credential rather than a human password. These controls break down when organisations assume branch cleanup equals eradication, because the secret may still exist in object storage, derivative clones, or retained scans.
Common Failure Patterns and Cleanup Edge Cases
Tighter history coverage often increases operational overhead, requiring teams to balance confidence in exposure removal against scan latency and repository maintenance cost. That tradeoff becomes more visible in large monorepos, high-churn repositories, or organisations with many forks and mirrored workflows.
One common edge case is history rewrite after discovery. If a secret was committed, then later removed with filter-based cleanup, a scanner that ignores deleted commits may report success even though the same credential was already copied into other branches or downstream repositories. Another is partial retention: some platforms purge visible history faster than underlying objects, so the UI changes before the data actually disappears.
Current guidance suggests treating secret-scanning coverage as a verification control, not just a detection control. That means the question is not only “did we find the secret?” but also “can we still retrieve the secret from any retained Git object?” Where teams rely on deletion alone, there is no universal standard for proving complete removal without a follow-up sweep across all repository replicas and access paths.
Risk and Threat Considerations
The material risk is residual secret exposure after remediation. If deleted commits are excluded, organisations may believe a credential has been removed while an attacker, insider, or automated crawler can still recover it from retained Git objects, forks, or mirrors. That creates an exposure gap between apparent cleanup and actual data removal.
Failure mechanism: Git object retention, cloned copies, and incomplete scan scope allow sensitive material to persist after branch deletion or history rewriting. Attackers do not need the secret to remain visible in the main branch; they only need one accessible copy, one overlooked mirror, or one recoverable object reference.
Impact: Incident response loses verification quality, remediation can be falsely closed, and exposed credentials may remain usable long after teams think they have been eliminated. That can prolong compromise windows, complicate audit evidence, and undermine trust in secret lifecycle controls.
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-01 — Secrets and Credential Management | Deleted commits can still expose machine credentials and tokens in Git objects. |
| Recommendation — Scan deleted history and revoke exposed machine credentials before closing the incident. | ||
| CIS Controls v8 | 6 — Access Control Management | Secret exposure creates unauthorized access paths that require rapid removal and verification. |
| 8 — Audit Log Management | Coverage gaps weaken evidence that cleanup actually removed the exposure. | |
| Recommendation — Revoke lingering access paths and verify no retained copies can still authenticate. Retain scan and remediation evidence that proves the secret is no longer recoverable. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Recovered secrets directly affect authentication and access control integrity. |
| Recommendation — Reduce authentication exposure by invalidating credentials associated with deleted commits. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Secrets left in Git history remain recoverable as exposed credentials. |
| Recommendation — Hunt for exposed credentials in repository objects and remove every retrievable copy. | ||
Practitioner Guidance
What to verify: Confirm that your secret-scanning process covers deleted commits, rewritten history, forks, and retained repository objects before declaring a leak closed. If the scanner cannot prove absence across those surfaces, treat the result as incomplete.
Decision rule: If a secret ever existed in Git, rotate or revoke it first, then verify repository cleanup separately. Do not wait for perfect cleanup evidence before removing credential validity, because exposure risk is driven by usability, not just visibility.
What practitioners underestimate: Deletion changes what humans can see faster than it changes what systems can recover. The operational mistake is treating a cleaner interface as evidence of a cleaner backend.
Practitioner takeaway: The real control objective is not removing the commit from view, but proving that no retrievable copy of the secret still exists anywhere the repository can be reconstructed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
