Secrets management: rotation, scope and the credentials already in your git history

01Git history is forever

Removing a secret in a later commit does not remove it. It remains in history, in every clone, in every fork, and in the caches of hosting providers. If a credential was ever committed to a repository that anyone else could read, treat it as compromised regardless of how quickly it was deleted.

Rewriting history is possible and disruptive - it invalidates every existing clone and breaks references. It is worth doing for genuinely sensitive material in a repository with restricted access. It is not a substitute for rotation, which is the only action that actually revokes the exposure. Rotate first, then decide whether rewriting is worth the disruption.

• Scan full history, not just the working tree.
• Rotate immediately - deletion does not revoke anything.
• Assume public repository exposure means immediate automated harvesting.
• Check provider logs for use of the credential before you rotated it.

02Scope is the primary control

Rotation limits how long a leaked credential is useful. Scope limits how much damage it can do while valid, and it is the more powerful of the two because it applies before you know anything has leaked.

A database credential with read access to one schema is a far smaller incident than an admin credential. An API key restricted to specific operations, specific source addresses and a short expiry is meaningfully less dangerous than a long-lived key with full permissions. Most organisations issue credentials far broader than the task requires, because narrow scoping is more work at issuance time.

03Move up the maturity ladder

Secrets handling improves along a fairly predictable path. Knowing where you are makes the next step obvious, and skipping steps rarely works because each one depends on the discipline established by the previous.

04Eliminate the secret where possible

The strongest position is having no credential to leak. Cloud workload identity lets a service authenticate based on what it is rather than a secret it holds - the platform attests the workload's identity and issues short-lived tokens automatically. There is nothing to commit, nothing to rotate and nothing to exfiltrate.

This works within a cloud provider and increasingly across providers via federation. It does not cover third-party services that only issue static API keys, so those still need a secret store. But every credential you can eliminate entirely is one you never have to manage, and this should be the default for internal service-to-service authentication.

05Detection and automation

Pre-commit hooks catch secrets before they are committed, but they run on developer machines and can be bypassed. Server-side scanning on push is the enforceable layer. Run both, and scan history periodically rather than only new commits, because the largest exposures are usually old.

Rotation must be automated to actually happen. Manual rotation is scheduled, deferred, and eventually forgotten, and a credential nobody has rotated in three years is one nobody dares rotate because the blast radius is unknown. Automated rotation on a short cycle also proves your systems handle credential changes gracefully - which is exactly what you need to be true during an incident.

• Scan on the server side; developer-side hooks are advisory.
• Periodically scan full history, not only incoming commits.
• Automate rotation so it is routine rather than an event.
• Alert on credential use from unexpected addresses or regions.