Git history exposes secrets long after deletion on GitHub

At a glance

What this is: This analysis shows why deleting a sensitive Git commit does not reliably remove the secret from reachable history, forks, or archive data.

Why it matters: It matters because Git-based exposure is an NHI governance problem, not just a developer hygiene issue, and it demands secret rotation, history rewriting, and ownership clarity across machine identities and supporting human workflows.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Oasis Security's analysis of why deleted Git commits can still expose secrets

Context

Git commit history is a governance surface, not just a developer convenience. When credentials or API keys are committed, the exposure can persist in prior revisions, forks, cached clones, and event logs even after the latest file is removed. For NHI programmes, that means source control must be treated as part of secret lifecycle management from the first commit.

The article’s central point is simple: deletion is not revocation. In practice, a secret that has appeared in Git should be assumed exposed until it is rotated, history is rewritten where possible, and downstream copies are assessed. That starting position is typical for modern software teams, but it is still frequently handled as an exception rather than a permanent control requirement.

Key questions

Q: What breaks when a secret is deleted from Git but not rotated?

A: Deletion only removes the latest visible copy. Earlier commits, forks, clones, and retained object data can still expose the secret, so the associated non-human identity remains at risk until the credential is revoked and replaced.

Q: Why do Git-based secrets create lasting NHI risk?

A: Git preserves history by design, which means a committed token can survive long after the file is gone. That matters because the secret may continue to authenticate the underlying service account or workload until the organisation rotates it.

Q: What do teams get wrong about force-pushing a cleaned branch?

A: They often assume force-push removes all risk. In reality, anyone with a prior clone or fork may still retain the bad commit, and external metadata can still point to the exposure path, so cleanup must extend beyond the main branch.

Q: How should organisations respond when a secret appears in Git history?

A: They should treat the secret as already exposed, revoke it, rewrite the repository history where possible, and check for forks or mirrors that may preserve the old commit. Source control cleanup is necessary, but secret rotation is the control that matters most.

Technical breakdown

Why Git history preserves exposed secrets

Git records project state as a chain of commits, each pointing to previous snapshots. Removing a file in a later commit only changes the latest view, not the earlier object history. That is why a secret committed to a repository can remain recoverable through older commits, cloned copies, tags, or references that still point to the object store. On hosted platforms, unreachable objects may also linger for a period before garbage collection. The key technical point is that Git is designed for durable history, so accidental credential exposure becomes a persistence problem, not a simple file deletion problem.

Practical implication: treat a pushed secret as exposed in every historical reference until it is rotated and the repository history is scrubbed where feasible.

Why force-pushing does not guarantee removal

A hard reset plus force push rewrites the visible branch tip, but it does not instantly erase all copies of the removed commit. Anyone who cloned, forked, mirrored, or indexed the repository before the rewrite may still retain the old object. Even after the origin history changes, commit hashes can remain discoverable through external metadata, activity logs, or retained garbage-collected objects. This is why secret exposure in Git is an identity problem as much as a source-control problem: the credential may continue to authenticate even when the code that exposed it is no longer visible.

Practical implication: pair history rewriting with secret rotation and downstream repository inventory, including forks and mirrors.

Why archive and event data extend the exposure window

Public event streams and archive systems can preserve enough metadata to reconstruct where a secret lived, even after the repository appears cleaned. That means the existence of a commit hash, push event, or fork record can outlast the sensitive content itself. For NHI governance, this widens the incident scope from code cleanup to exposure management across the broader ecosystem. The technical issue is not just whether the bytes still exist, but whether the credential remains valid, discoverable, or reusable somewhere else in the chain.

Practical implication: assume the exposure trail survives the deletion event and validate both the secret’s validity and its residual discoverability.

Threat narrative

Attacker objective: The attacker’s objective is to recover a valid secret from historical Git data and use it to access the associated non-human identity before the organisation revokes it.

1. Entry occurred when a sensitive secret was committed into Git and pushed into repository history, making the credential discoverable through the commit graph.
2. Credential access persisted because the secret remained recoverable in earlier commits, forked repositories, cached clones, or retained commit objects even after deletion.
3. Impact followed when the exposed credential could still be used against the associated non-human identity until rotation, revocation, and downstream cleanup completed.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Git history creates identity persistence debt: Once a secret is committed, the exposure outlives the visible file state. Git’s object model preserves prior snapshots, so the credential’s lifecycle is no longer tied to the application’s current codebase. For NHI governance, that means the control problem is not hiding the latest copy. The practitioner implication is to treat source control as an identity-bearing system that must be covered by lifecycle, detection, and revocation discipline.

Deletion is not revocation, and that assumption fails operationally: The common governance assumption is that removing a file or rewriting a branch eliminates the risk. That assumption was designed for visible code, not for durable commit graphs, forks, cached clones, and archive data. The implication is that secret exposure in Git must be managed as a distributed identity event, not a file cleanup task.

Exposure in Git reveals a named concept: commit-history secret residue: A secret can vanish from the working tree and still remain in historical objects, forks, and metadata trails. That residue turns a one-time mistake into a long-tail access problem because the secret may remain valid after the code is cleaned. Practitioners should regard commit-history secret residue as a distinct failure mode, separate from simple misplacement of credentials.

Source control has become part of NHI lifecycle governance: The article shows why secret rotation, ownership mapping, and offboarding cannot stop at the secrets manager boundary. When a token or key appears in Git, the governance task spans code repositories, developer clones, forks, and any external indexing that could preserve the exposure. The practitioner implication is to expand NHI lifecycle control to the repository layer.

The strongest control is assumption shift, not cleanup theatre: Teams often focus on deleting commits because it feels definitive, but the durable risk sits in the validity of the secret itself. Once a credential has entered Git, the safer operating model is to assume it is known and usable until proven otherwise. Practitioners should anchor response on credential revocation, not on the false comfort of repository deletion.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, which makes secret-to-identity mapping and owner attribution harder to sustain at scale.
• Forward pivot: The governance answer is broader than detection alone, and Top 10 NHI Issues shows why visibility, ownership, and lifecycle control must be designed together.

What this signals

Commit-history secret residue is now a governance pattern, not an edge case. When code repositories preserve prior states, teams need to assume that exposure can survive file deletion, branch cleanup, and even some history rewrites. The operational shift is to manage Git as part of the NHI lifecycle, not as a separate developer concern.

Because 91.6% of secrets remain valid five days after the targeted organisation is notified, according to our Ultimate Guide to NHIs, speed of revocation remains the decisive control when repository exposure is discovered. The programme signal is clear: if ownership, rotation, and fork inventory are not already mapped, the response window is too slow to matter.

For practitioners

• Rotate the exposed secret immediately Revoke the credential as soon as the commit is discovered, and treat every committed secret as compromised even if the file has been deleted from the latest branch.
• Rewrite repository history with a scrub tool Use a history-rewriting tool such as git filter-repo or BFG Repo-Cleaner to remove the secret from commit objects, then force-push the cleaned history only after validating the rewrite.
• Inventory forks, clones, and mirrors Identify upstream forks, developer clones, and any mirrored repositories that may still retain the old commit, then notify owners to re-clone from the cleaned source.
• Audit GitHub activity and archive trails Check repository event logs, fork history, and archive sources for commit hashes that can still reveal the exposure path, because metadata can outlast the visible secret.
• Map each leaked secret to its NHI owner Tie every exposed token or key back to the service account, API identity, or workload it authenticates so the revocation path is owned and measurable.

Key takeaways

• Git history can preserve sensitive credentials long after the latest file is removed, so deletion alone does not end exposure.
• The scale of the problem is structural, with secrets commonly stored in code and many organisations lacking full service-account visibility.
• Practitioners should rotate the credential, scrub the repository history, and extend the incident scope to forks, clones, and archive metadata.

Key terms

• Dangling Commit: A dangling commit is a Git object that still exists in the repository database but is no longer referenced by a branch or tag. It may be invisible in normal history views, yet still recoverable until garbage collection removes it or a hosting platform discards it.
• Commit-history Secret Residue: Commit-history secret residue is the state where a secret appears removed from current code but remains recoverable in older commits, forks, cached clones, or metadata trails. For NHI governance, it means exposure persists beyond the visible remediation point and must be treated as an active identity risk.
• Secret Rotation: Secret rotation is the process of replacing a credential, token, or key so the old value can no longer authenticate. In practice, it is the control that closes the risk window after exposure, because cleanup alone does not invalidate a secret that may already be known or copied.
• Repository History Rewrite: Repository history rewrite is the deliberate removal or replacement of sensitive content from Git objects, usually through tools that scrub commits before a force push. It reduces exposure in the origin repository, but it does not automatically purge forks, mirrors, or external archives.

Deepen your knowledge

Git history exposure and secret recovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with source control leaks or credential reuse, it is a practical place to start.

This post draws on content published by Oasis Security: Git, History, and Hidden Mistakes: Why Deleting a Commit Isn't Enough. Read the original.