Secrets in git repository

Secrets in git repository history are how a temporary .env commit, a pasted API key, or a cloud access key becomes permanent exposure. Forks, CI caches, and old clones keep the value long after you delete the file on main. So stop the bleed first, then build habits that keep the next temporary commit from sticking.

How secrets sneak in

Someone needs the app running tonight. They commit .env, a JSON key file, or a “temporary” password in config. Or they paste a token into a script that lands in the first PR. CI then echoes the secret into logs. Chat dumps the same key into a ticket. I’ve watched London SaaS teams discover the key months later in a forgotten branch, a public fork, or a zip of the repo someone emailed a contractor.

The pattern is the same: short-term convenience, long-term copy you no longer control. API keys in GitHub issues and committed env files are the same class of mistake with different filenames. “Temporary” is how most secrets in git repository leaks start, not how they end.

Why rewriting history hurts

Removing the file on the latest commit does not remove it from history. A history rewrite can scrub known commits, but every clone, mirror, fork, and backup still needs the same treatment. Force-pushes break open PRs and confuse the team. If the repo was ever public, or a contractor had a full clone, assume the secret is already out. Treat rewrite as hygiene after rotation, not as the primary cure. That is why “remove secrets from git history” alone is a weak plan when the key is still live at the provider.

Stop the bleed first

Order matters. Revoke or rotate the exposed credential at the provider before you tidy git. Then check where else that same value was reused: staging, a second cloud account, a partner integration. Invalidate sessions and CI variables that still hold the old secret. Only then clean the tree and decide whether a history scrub is worth the disruption. For many small teams the urgent win is a dead key and a short written order of operations, not a perfect history rewrite on day one. If you reverse that order, an attacker with the old commit still has a live key while you argue about rewrite tooling and force-push etiquette.

Prevention as decisions, not product pitches

Keep secrets out of the repo by category. Local env files stay untracked and never get “just this once” commits. Cloud and API keys live in the host’s secret store or CI’s secret store, injected at runtime. Shared team passwords do not belong in git at all. Pre-commit and CI checks that refuse obvious keys are useful guardrails; they do not replace rotation when someone walks around them. “Just use a vault product” is not a plan if nobody owns who puts values in and who rotates them.

A security audit can still catch what habit missed. This piece is about the git-shaped leak, not another full go-live checklist.

Ownership after the engagement

After a survey and any fixed-price cleanup, you should still own the git hosts, cloud accounts, and secret stores. Eight Mile can help revoke what leaked, scrub what is safe to scrub, and set the habits. You keep the logins and the runbook that says how a new key is created and where it must never be pasted. Founders should be able to name who can rotate production credentials without waiting on a weekend Slack ping. If only the agency can rotate production secrets, you moved the problem, not the risk.

Stop the temporary commit becoming permanent

Assume anything once committed is copied. Rotate first. Then make the next leak boringly rare.

If you want a short secrets and shipping-hygiene survey — what might already be in history, what to rotate first, and which habits will stick — contact Eight Mile and say which repos and clouds matter this week.