When a secrets scanner flags a credential in git history, rotate or revoke it first, then check logs for use you did not make, then fix the cause so it does not repeat. Rewriting history is the last and least important step. GitHub's own guidance says it is time consuming and often unnecessary once the credential is revoked.
Step 1: treat it as public
Assume anyone who could read the repository, any fork or any clone has the secret. Deleting the file in a later commit does nothing for that. The scanner reads full history across branches, which is the same view an attacker with access has.
Step 2: rotate
Create a new credential, deploy it where it is needed, then revoke the old one. Order matters, so services do not break. If the secret is a cloud key, also review what permissions it had and whether a narrower scope would do.
Step 3: check for misuse
Look at the provider's access logs from the commit time to now. Watch for calls from unfamiliar addresses, unusual regions, new resources, or permission changes. If the secret belongs to a partner service, GitHub notes that detected partner secrets are sent to the provider, who may revoke them, so you may already see an alert or a disabled key.
Step 4: find out how it got there
Common causes:
- A local config file committed by accident.
- A test fixture with a real value.
- A credential pasted into a script during debugging.
- A secret in a build argument that ended up in an image layer.
Pick the fix that matches: ignore rules, environment variables, a secrets manager, or a pre-commit check. Add push protection if your platform supports it.
Step 5: decide on history cleanup
Rewrite history only if the repository holds other sensitive data that cannot be rotated, such as personal records. Rewriting breaks every clone and open branch and does not remove copies already made.
Step 6: record it
Write down what leaked, when, who rotated it, what you found in logs, and what changed. If you handle regulated data, check whether your obligations require notification, and take advice if unsure.
Quick check
Do I need to rewrite git history?
Usually no, once the credential is revoked. Rewriting is slow and cannot recall copies that already exist.
What if the scanner says the secret is already revoked?
Still check logs for use before revocation, and confirm the cause is fixed.
Sources
Last reviewed: 19 October 2026.
