securitysecretsengineering

How to Stop Secrets From Leaking Into Your Git History

MicroReview Team··5 min read

A leaked API key is one of the cheapest mistakes to make and one of the most expensive to clean up. Once a secret lands in your Git history, rotating it isn't optional — and if the repo is public, automated scanners will find it within minutes. The good news: almost every leak is preventable at review time.

Why .gitignore Isn't Enough

Ignoring .envfiles stops the obvious case, but secrets leak in dozens of other ways: a hardcoded token in a test fixture, a connection string pasted into a config for "just a quick debug," a private key checked in by accident. None of these are covered by a typical ignore file.

Why Rotating After the Fact Is Painful

Removing a secret from the latest commit does nothing — it's still in the history. You have to rewrite history (disruptive for everyone who cloned the repo) and rotate the credential anyway, because you must assume it was seen. The only cheap fix is to never let it merge.

Catch Secrets at Pull Request Time

The right place to stop a secret is the pull request, before it reaches your main branch. A scanner that reads the diff can flag a hardcoded credential the moment it's added — while it's still trivial to remove with a single edit.

MicroReview scans every diff for 13 categories of secrets— AWS keys, Stripe and OpenAI tokens, GitHub PATs, JWT secrets, private keys, database URLs, and more. When it finds one, it posts an inline comment on the exact line and, if you enable merge blocking, marks the pull request as failing so it can't be merged until the secret is removed.

A Simple Three-Layer Defense

  • Layer 1 — Prevent: keep secrets in environment variables and a secrets manager, never in source.
  • Layer 2 — Detect at review: scan every PR diff so a hardcoded secret is caught before merge.
  • Layer 3 — Block: make critical findings fail a required status check so a leak can't reach main even by accident.

The Bottom Line

Secret leaks aren't a discipline problem — they're a tooling problem. Developers move fast and mistakes happen. The fix is to put a scanner in the pull request path so the mistake gets caught the moment it's made, not weeks later in a security audit. That turns a multi-hour incident into a ten-second edit.

Ready to try MicroReview?

Free for 2 repos. 30-second setup. No credit card required.

Get Started Free →