Secret Leaked to Git? Rotate Before Rewriting History

A secret leaked to Git is first an access problem. Repository cleanup matters, but deleting a file or rewriting a commit does not revoke a credential at the system that accepts it. Start by containing what the exposed secret can authorize.

GitHub explicitly recommends revoking or rotating exposed credentials before considering history rewriting. Its guidance also explains the coordination risks of rewriting history, including reintroducing old commits from existing clones. GitHub sensitive-data removal guide.

The following is a response design for your own systems. Exact revocation behavior depends on the credential issuer, so use the issuer's procedure and preserve an incident record without copying the secret into it.

Establish scope without spreading the value

Identify the credential type, issuing system, owner, intended consumers, granted authority, and first known exposure. Record an identifier or fingerprint where supported. Do not paste the raw value into chat, tickets, or screenshots to make the incident easier to discuss.

Distinguish known exposure from inferred exposure. “The token appeared in this public commit at this time” is an observation. “Nobody used it” requires evidence you may not have. If logs are unavailable or retention is insufficient, record that limitation instead of converting missing evidence into reassurance.

An initial incident note could contain:

Credential identifier: provider-side ID, never the secret value
Known exposure: repository and commit reference
Authority: resources and operations granted
Containment owner: named responder
Revocation status: pending / confirmed, with time
Consumer inventory: services, jobs, integrations
Evidence gaps: missing logs, uncertain first exposure

This small record gives multiple responders a shared picture while keeping the compromised material out of additional systems.

Choose containment before convenience

For a credential with dangerous authority, immediate revocation may be the right response even if it interrupts a service. For a lower-risk credential where the issuer supports a controlled overlap, a replacement can sometimes be deployed before the old credential is revoked. Make that a conscious incident decision, not an undocumented preference for uninterrupted builds.

The decision needs an owner who can weigh continued unauthorized access against operational disruption. It should also consider derived access: replacing an original key may not automatically terminate every session, token, or artifact created with it. Verify the provider's semantics and investigate relevant activity.

My default runbook would require an explicit “old credential no longer accepted” checkpoint. “New key created” is not equivalent. Nor is “application restarted”: it may still be reading the old secret from a different configuration source.

Where possible, validate revocation through provider status and controlled, non-destructive checks. Avoid generating unnecessary production activity merely to demonstrate failure.

Rotate the consumers, not just the secret store

List every legitimate consumer before declaring rotation complete: production services, scheduled jobs, preview environments, developer tooling, and third-party integrations. Assign a status to each one.

OWASP recommends managing the secret lifecycle with access control, auditing, rotation, and metadata such as ownership and intended use. Those practices make an exposure response easier because the consumer inventory already exists. OWASP secrets management guidance.

For each consumer, update the approved secret source and confirm the process has actually loaded the replacement. A configuration update may require a redeploy, restart, or explicit reload depending on the application. Record the mechanism rather than assuming every platform propagates secrets identically.

Use the incident to question oversized credentials. If one token serves unrelated jobs, replacing it with separate scoped credentials can make future rotation easier. Do not turn an urgent containment step into a sprawling redesign, though. Contain first; schedule structural improvements with owners afterward.

Review activity and downstream artifacts

Inspect the issuer's audit trail for unexpected use during the exposure window. Review resource changes and additional credentials created by the compromised identity where relevant. Treat the investigation as a separate workstream from deploying the replacement, so service recovery does not erase unanswered security questions.

Also identify copies under your control: CI logs, release archives, container images, generated frontend assets, package bundles, documentation previews, and build caches. The applicable locations depend on how the secret entered the repository and what subsequently built from it.

A useful distinction is between invalid credential copies, which no longer grant access, and sensitive non-credential data, which may remain sensitive even after a token is revoked. Repository history cleanup can have different urgency in those cases. Ask the responsible security or data owner when the exposure includes additional confidential material.

Coordinate history cleanup deliberately

If rewriting history is warranted, designate one owner and communicate the affected branches and clone-handling instructions. Pause conflicting repository updates as needed. Follow the hosting provider's current cleanup procedure, including any steps for references or cached views that a local rewrite cannot address.

Do not force-push a rewritten repository as an isolated act and assume the team will work it out. Existing clones, open pull requests, tags, and automation may still refer to earlier commits. Plan how collaborators resume work without reintroducing the material.

Close the incident only when the access decision is verified, legitimate consumers work, relevant activity has been reviewed or explicitly marked unresolved, and cleanup has an accountable status. Add prevention that addresses the actual route of exposure, such as scanning generated artifacts or removing a credential from build inputs.

The OIDC deployment guide describes a way to reduce reliance on stored cloud keys. The hardcoded credential incident illustrates why deleting a visible secret is insufficient. Prove the old credential has lost its authority before celebrating a clean diff.