How should security teams remove secrets from Git history after a leak is discovered?

Why This Matters for Security Teams

Removing a secret from the latest commit is not enough because Git preserves historical snapshots, and those snapshots often outlive the incident response window. Once a credential has been committed, assume it has been copied into local clones, forks, CI logs, build artifacts, and cached runners. The practical issue is not just exposure, but trust: downstream systems may continue using the leaked value until every dependency on it is found and replaced.

This is why current guidance favors history rewriting plus credential rotation, rather than cosmetic cleanup. Security teams should also treat the leak as an access-control event, not only a source-code hygiene issue. If the secret belonged to a non-human identity such as a service account, API key, or deployment token, the governance burden is higher because the secret may authenticate automation across multiple environments. The OWASP Non-Human Identity Top 10 is a useful reference for understanding how secret sprawl becomes an operational risk rather than a one-off mistake. In practice, many security teams encounter the leak first through an unexplained downstream access pattern rather than through intentional secret discovery.

How It Works in Practice

The incident response sequence should start with containment, then cleanup, then verification. Containment means disabling or rotating the exposed secret immediately, even before the repository rewrite is complete. Cleanup means removing the secret from all relevant commits, tags, and branches using a history-rewriting tool, then force-pushing the sanitized branch and coordinating with every contributor who may have cloned the repository. Verification means checking whether the secret was replicated into pull requests, release archives, container images, CI logs, or mirrored repositories.

Security teams should pair the Git operation with a broader evidence sweep. Search for the exact value, partial prefixes, and nearby context in source control, build output, issue trackers, and telemetry. If the secret was tied to automation, review whether the credential was scoped narrowly enough in the first place. NIST guidance on digital identity and access assurance is relevant here because leaked secrets are often the practical substitute for weak or missing identity controls, especially where a human workflow has been replaced by a machine-to-machine trust path. When the exposure touches AI-enabled tooling or agents, the operational concern expands further because a compromised token can authorize prompts, retrieval, deployment, or data access at machine speed.

Useful implementation steps typically include:

• Invalidate the exposed secret before attempting cleanup, to reduce the window of misuse.
• Rewrite history on the affected branch, then verify that the secret no longer appears in reachable commits.
• Force-push the cleaned history and notify collaborators to rebase or reclone.
• Inspect forks, mirrors, CI caches, release bundles, and artifact registries for residual copies.
• Replace the secret with a new credential, and reduce standing access where possible.

For broader incident handling, teams can map the event to NIST CSF containment and recovery outcomes and use CISA guidance on credential exposure as a response baseline. These controls tend to break down when the secret has already been embedded in third-party build systems or published release artifacts because those copies are outside the repository rewrite boundary.

Common Variations and Edge Cases

Tighter cleanup often increases operational overhead, requiring organisations to balance rapid recovery against the risk of breaking active deployments. That tradeoff is especially visible when the leaked secret is shared by multiple services, because revocation can interrupt production paths while teams hunt for every dependency.

Best practice is evolving for mono-repos, long-lived release branches, and distributed fork networks. In those environments, history rewriting may not fully erase exposure because downstream clones can retain the original objects indefinitely. There is no universal standard for guaranteeing complete removal from every external copy, so the realistic goal is to remove trust in the leaked value, not to assume the bytes can be recalled from the internet.

Edge cases also arise when the secret is stored in generated files, test fixtures, or archived logs rather than plain source code. In those cases, the same response logic applies, but the cleanup surface is wider and may require separate retention controls. If the exposure involved an NHI credential used by CI/CD or an agentic workflow, the follow-up should include secret inventorying, rotation cadence review, and narrower privilege design so the next leak is less useful to an attacker. The incident is not complete until the old credential is dead everywhere it could authenticate.

Related resources from NHI Mgmt Group

• How should security teams remove secrets from production MCP deployments?
• How should security teams handle secrets that are valid after they leave a vault?
• How should security teams prevent secrets from reaching shared Git repositories?
• How should security teams handle exposed developer secrets after a supply chain attack?