What breaks when organisations only delete the commit that exposed a secret?

Why This Matters for Security Teams

Deleting the commit changes history only in the narrowest sense. The exposed value can still exist in cloned repos, forks, CI logs, cached artefacts, package mirrors, and developer laptops, which means the credential lifecycle has not actually been closed. Security teams usually miss the distinction between removing evidence of exposure and removing the ability to use the exposed secret. The result is a false sense of remediation, especially when repositories are public or widely mirrored. The operational issue is that a secret is only safe when it is no longer valid anywhere it can be used. If the commit contained an API key, token, certificate, or private credential, the right question is whether that credential has been rotated, revoked, and replaced at every place that still trusts it. In practice, teams often discover the lingering exposure only after access patterns, fraud, or unexpected automation activity reveal that the old value still works. If a real secret was exposed, deleting the commit removes the symptom, not the trust relationship that made the exposure dangerous in the first place.

How It Works in Practice

A commit deletion or force-push can remove the secret from the visible branch tip, but it does not reliably remove every copy of the data. Git history is distributed by design, so once a secret is committed, the value may already exist in prior clones, review systems, forks, mirrors, build outputs, and archive services. That is why “we deleted it” is a repository hygiene action, not a complete remediation. A proper response sequence usually has three parts:

• Revoke or rotate the exposed credential so the old value stops working.
• Search for every place the secret may have propagated, including forks, CI/CD systems, logs, and packaged artefacts.
• Confirm that the replacement credential is deployed everywhere that depended on the old one, without reusing the same value.

For codebases with broad distribution, the hardest part is not the original leak but the persistence of trust in downstream copies. Public forks and mirrored package sources can outlive the source repository, and some consumers may never pull the rewritten history. Even where secret scanning detects the problem, the scanner only identifies exposure; it does not invalidate the credential. The most important technical point is that remediation must break the credential’s usefulness, not just its visibility. The NHIMG guide to the secret sprawl challenge is a useful companion here because it frames how exposed secrets spread across code, CI/CD, and operational tooling. These controls tend to break down when the secret has already been cloned into multiple independent systems, because no single repository fix can reach every inherited copy.

Common Variations and Edge Cases

Tighter history rewriting often increases operational overhead, so teams have to balance repository cleanliness against the practical limits of distributed copies. In internal-only systems, a history rewrite may be enough to reduce casual discovery, but that is still different from eliminating the secret’s blast radius. The edge cases are usually about propagation, not deletion:

• Forks and mirrors may keep the old commit even after the origin is cleaned up.
• Package registries and container layers can preserve an exposed value long after the source repository changes.
• Credential rotation may fail if downstream services were never updated to trust the replacement secret.
• Old commits may remain recoverable through backups, archives, or developer clones even when the branch history looks clean.

Current guidance suggests treating exposed secrets as compromised the moment they are discovered, unless you can prove they were inert, expired, or otherwise unusable. That is especially important for long-lived API keys and automation credentials, where a deleted commit can still leave an attacker with an active authentication path. The relevant question is not whether the record is gone from Git, but whether any live system can still authenticate with it.

Risk and Threat Considerations

The risk is credential persistence after disclosure. Once a secret has been committed, an attacker does not need the original branch tip to find it, and deletion does not invalidate copies already made elsewhere. The exposure becomes worse when secrets are reusable across environments or embedded in automation, because a single leaked value can provide durable access. Failure mechanism: The exposed value survives in forks, mirrors, caches, logs, and packaged artefacts, then remains accepted because the backing service still trusts it. Attackers typically exploit the gap between source cleanup and credential revocation, using search tools or copied history to retrieve the old secret and authenticate before defenders fully rotate it. Impact: Unauthorized access can continue after the repository appears fixed. That can lead to data exposure, service abuse, lateral movement through connected systems, or silent automation misuse that is hard to distinguish from legitimate activity.

Practitioner Guidance

What to prioritise: Treat the exposed secret as compromised first, then verify whether any active system still accepts it. If the answer is uncertain, assume the credential remains usable until rotation and revocation are complete.

What to verify: Confirm that all inherited copies have been addressed, especially forks, CI/CD variables, build artefacts, package mirrors, and developer clones. The practical test is whether the old value can still authenticate anywhere, not whether it still appears in the main repository.

Common mistake: Teams often stop at history rewriting because it is visible and fast. That creates a remediation gap when the real control failure is credential validity, distribution, and downstream trust.

Practitioner takeaway: Deleting the commit is housekeeping; revoking the secret is remediation. If the old credential can still work in any live system, the incident is still open.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• What breaks when organisations rely on traditional IAM alone for cloud entitlement management?
• Why is proactive secret scanning important for NHI security?
• When does secret exposure become a broader identity risk?