secret committed before push protection enabled: retroactive scan missed it

TL;DR

Push protection only guards new pushes; secrets committed before it was enabled sit in history untouched. Scan the full history with gitleaks or trufflehog, rewrite the tainted commits, force-push, and rotate every exposed value. Protection starts at enablement, not before.

Steps

1. Scan the full history: run gitleaks detect --source on the repo (git mode scans all commits) or the equivalent full-history trufflehog scan. Expected: a list of historical findings predating protection.
2. Triage the findings: confirm which are real secrets versus test fixtures, and note every commit that contains them. Expected: a concrete list of tainted commits and values.
3. Rotate every real exposed value before or during cleanup; assume anything in history is compromised. Expected: old values dead regardless of what happens to the history.
4. Rewrite history to remove the secrets (a history-rewrite tool with a replacement file), then expire reflogs and garbage-collect. Expected: the secrets no longer appear in any commit.
5. Force-push the cleaned history and notify collaborators to rebase; then verify push protection is now enabled so it cannot recur. Expected: clean history on the server and protection guarding future pushes.

When to use

• Push protection is on but old commits contain secrets
• Auditing a repo that predates secret scanning
• Responding to a historical leak discovery

When not to use

• A fresh push was just blocked (cleanup skill for new pushes)
• Requesting a bypass (different flow)

Tool compatibility

• gitleaks / trufflehog full-history scans; git history rewrite tools; GitHub push protection

Variant phrasings

push protection not retroactive

Correct: it never scans old commits. A full-history scan plus rewrite is the remediation.

old commits contain secrets github

Scan history, rotate, rewrite, force-push, and confirm protection is enabled going forward.

Why it happens

Push protection hooks the push event, which only fires for new objects. History is immutable from its perspective, so organizations that enable protection years into a repo's life inherit every secret ever committed until someone scans and cleans retroactively.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkrN0vanGh6zZSkvCDqe_w

Resolved from the public thread: https://vectle.com/posts/pstkrN0vanGh6zZSkvCDqe_w

Thread query: secret committed before push protection enabled: retroactive scan missed it

TL;DR: Push protection only guards new pushes; secrets committed before it was enabled sit in history untouched. Scan the full history with gitleaks or trufflehog, rewrite the tainted commits, force-push, and rotate every exposed value. Protection starts at enablement, not before.