Why do dangling commits create real exposure after a secret has been removed from a branch?

Why Dangling Commits Create Real Exposure

Removing a secret from the current branch does not erase the repository history that already captured it. A dangling commit can still preserve the older tree, blob, and commit objects, which means the credential may remain recoverable long after the fix appears merged. That is why secret removal is not the same as secret elimination. NHI Mgmt Group notes that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which shows how often exposed credentials turn into real incidents.

History rewrite is especially risky when teams assume a force-push or branch deletion is a cleanup event. In reality, any clone, fork, cache, mirror, CI job, or local object database may still hold the old commit. Attackers do not need the branch tip if they can recover the object directly, and secret scanners often miss detached or unreferenced history unless that history is explicitly swept and expired.

In practice, many security teams discover the exposure only after a downstream clone, cache, or backup has already preserved the removed secret.

How the Exposure Persists in Practice

Git stores content as objects, not as a single mutable file. When a secret is committed, it can live inside a blob object even after the branch is rewritten to point elsewhere. If no reachable reference points to that commit, it becomes dangling, but dangling does not mean destroyed. Until garbage collection prunes the object and every replica forgets it, the old credential may still be retrievable through local repositories, reflogs, packfiles, backups, or forensic tooling.

The practical control problem is therefore twofold: eliminate the secret from live code and reduce the chance that the historical object remains accessible. That is why response playbooks usually combine revocation, rotation, history rewriting, and repository hygiene rather than relying on a single cleanup action. The Guide to the Secret Sprawl Challenge is a useful reference for understanding how quickly credentials spread beyond the first location where they were exposed.

• Revoke the credential immediately, even if the commit has been rewritten.
• Rewrite history only after deciding what must remain for audit or release continuity.
• Expire reflogs and run garbage collection in every affected clone and mirror.
• Search CI logs, build artifacts, issue trackers, and backup stores for copied secrets.

For distributed teams, this often pairs with repository-wide inspection and the findings documented in 52 NHI Breaches Analysis, because exposed keys frequently reappear in adjacent systems rather than staying isolated in source control. These controls tend to break down in large fork networks and long-lived CI caches because old objects can remain reachable long after the branch rewrite.

Common Edge Cases and Cleanup Mistakes

Tighter cleanup often increases operational overhead, requiring organisations to balance fast remediation against preserving legitimate release history. There is no universal standard for exactly how long a removed commit remains recoverable, because retention depends on Git settings, hosting behaviour, mirrors, and local clones.

A common mistake is treating branch deletion as equivalent to revocation. Another is rewriting history without rotating the credential, which leaves the same secret usable if it was copied elsewhere. Teams also miss hidden copies in webhook payloads, build logs, and developer laptops. If the secret was used outside Git, the exposure extends beyond the repository boundary and the dangling commit is only one copy of a larger problem.

Best practice is evolving toward a simple rule: if a secret touched a commit, assume that commit may still be recoverable until every stored copy is validated as gone. That means history cleanup, credential rotation, and exposure verification must happen together, not sequentially. Where release artifacts are generated from the same repository, the safer approach is to treat them as part of the same incident scope rather than separate systems.

Related resources from NHI Mgmt Group

• How does OneDrive auto-sync create secrets exposure in SharePoint?
• How should security teams reduce secret exposure in public API workspaces and shared collections?
• Why do secrets create disproportionate risk in NHI environments?
• What is the difference between privilege reduction and secret rotation?