Security tip of the day: your old commits still have your keys

Security tip for the day: once you decide to get serious, prune your historical git commits.

I'm working with a couple of companies on security and architecture, which mostly means data modeling. One pattern came up at every one of them.

How it happens

Most repositories start as a local project with credentials (AWS, npm, email and so on) embedded in the code. That's natural, and it's easier in the beginning.

As the company grew, they cleaned the credentials out of the code and moved them into CI/CD or another orchestration layer. But they never rotated them. There's always a fear of unknown failures, so no one took the risk.

Deleting a secret from the code doesn't delete it from the history.

The problem

Unfortunately, those credentials were still sitting in plain text in the historical commits. It doesn't take a rogue agent to find them; read-only git access is enough.

The fix

Rotate first. Rotation is the only step that makes a leaked credential useless. Anyone who has cloned or forked the repo, CI caches and old backups still hold the old history, and on hosted platforms removed commits can stay reachable for a while.

Then prune. Once the keys are rotated, accept losing a bit of history and remove those commits from your repository so the old secrets stop spreading to every new clone.