Key takeaway: A secret committed to a repository must be considered compromised the moment it is pushed. Rewriting history without rotating the credential is theatre.
The Timeline Is Shorter Than You Think
Automated scanners monitor public repository event streams continuously. Measured time-to-exploitation for a live cloud access key pushed to a public repository is frequently under five minutes, and attacks have been observed starting in under sixty seconds.
That window is far too short for a human to notice, escalate and respond. By the time anyone opens the incident channel, the key has been used to enumerate permissions and often to launch compute.
Why History Rewriting Is Not Remediation
git filter-repo and BFG can genuinely remove a blob from history. What they cannot do is retract copies:
- Every clone and fork already on someone else’s disk retains it
- CI caches, build artefacts and Docker layers may embed it
- Platform APIs can still serve orphaned commit objects by SHA for a period
- Anyone watching the event stream captured it before the rewrite
Rewriting shared history also breaks every collaborator’s working copy and requires coordinated force pushes. Doing that work while the credential remains valid is spending your incident response budget on the wrong task.
The Correct Order of Operations
- Revoke the credential. Not rotate-later, not rotate-after-review. Revoke it now, before anything else. This is the only step that actually stops the bleeding.
- Issue a replacement and deploy it through your secrets manager.
- Audit for use. Pull access logs for the credential across its full validity window and look for calls from unfamiliar addresses.
- Then consider history rewriting, weighing the collaboration disruption against the marginal benefit.
- Fix the pathway so it cannot recur.
Prevention That Actually Holds
| Control | Catches | Limitation |
|---|---|---|
| Pre-commit hook scan | Before it leaves the machine | Bypassable, needs local setup |
| Server-side push protection | Before it enters history | Requires platform support |
| CI secret scanning | After commit | Too late, still valuable |
| Short-lived OIDC tokens | Removes long-lived secrets | Requires infrastructure work |
The structural fix is eliminating long-lived credentials. Workload identity federation lets CI jobs exchange a short-lived OIDC token for cloud credentials valid for minutes. A leaked fifteen-minute token is a nuisance rather than an incident.
Push protection at the server is the strongest single gate for repository content, because it rejects the push rather than reporting it afterwards, and it cannot be skipped by a developer who did not install the hook.
The Bottom Line
Write the runbook so step one is revoke, and rehearse it. Then invest in short-lived credentials so that the next leak is survivable by construction rather than by response speed.
