Secrets management: the credentials already in your git history

Almost every organisation has credentials in its git history, and most do not know which ones. A secret committed once is compromised permanently - deleting the line in a later commit changes nothing, because the object is still in the history and in every clone anyone ever made.

Where secrets actually accumulate

• Source code and config files - the obvious one, and still the most common.
• CI/CD variables, often long-lived, broadly scoped and readable by anyone who can edit a pipeline.
• Container images baked at build time and then pushed to a registry.
• Infrastructure-as-code state files, which frequently contain credentials in plaintext.
• Local .env files on developer laptops, backed up to who knows where.
• Ticketing systems and chat - pasted during an incident and never removed.
• SaaS integrations where someone generated a token with far more scope than needed.

The hierarchy of fixes

1. Eliminate the secret. The best credential is one that does not exist - workload identity, IAM roles and OIDC federation let a service prove what it is without holding a static key. Prefer this wherever the platform supports it.
2. Make it short-lived. A token valid for fifteen minutes is a far smaller problem than one valid until someone remembers to rotate it.
3. Vault it. Central storage with access control, audit logging and programmatic retrieval - never a file, never a wiki page.
4. Scope it narrowly. Most leaked credentials do damage because they had far more permission than the task required.
5. Rotate it. Routine where it is cheap, and always on exposure or personnel change.

Notice detection is not on that list. Scanning is necessary but it is a backstop - it tells you a secret escaped. The controls above stop it being valuable when it does.

Scanning, done properly

• Pre-commit hooks so the secret never reaches the repository - by far the cheapest intervention.
• CI scanning on every push, failing the build.
• Full history scanning, once, to find what is already there. Expect this to be uncomfortable.
• Provider push protection where your platform offers it.

Tune for false positives early. A scanner that cries wolf gets bypassed within a month, and a bypassed scanner is worse than none because it creates false confidence.

When a secret is exposed

The order matters, and most teams get it wrong:

1. Rotate first. Immediately. Before investigating, before cleaning history.
2. Then check for use - review logs for access with that credential, from unexpected sources or times.
3. Then decide about history. Rewriting git history is disruptive and does not help if the repository was ever public or widely cloned. Rotation is what actually resolves it; history cleanup is hygiene.
4. Then fix the path that allowed it, or it recurs.

Teams that start with history rewriting leave a live credential valid for hours while they do it.

What auditors ask

Evidence that credentials are not stored in code, that access to the vault is controlled and logged, that rotation happens on a defined basis and on personnel change, and that shared credentials are rotated when someone leaves. That last one is the strongest practical argument against having shared accounts at all.

Key takeaways

• A committed secret is compromised permanently - deletion does not undo it.
• Eliminate, shorten, vault, scope, rotate - detection is only a backstop.
• On exposure: rotate first, investigate second, clean history last.
• A noisy scanner gets bypassed and creates false confidence.