Secrets management: why a key in git is already a breach

A junior pushes a quick fix to a public repo. Buried in the diff is an AWS access key that was “just for testing.” Within a minute an automated scanner watching GitHub’s public event stream has it; within eleven minutes someone spins up a fleet of GPU instances for crypto mining on the company’s account. The dev panics and force-pushes a commit deleting the line. The key still works — it is still live in git history, and rotating it, not deleting it, is the only thing that ends the breach.

A hardcoded credential is a leaked credential

The instinct is to treat a key in source code as untidy — something to clean up before the demo. It is not untidy; it is exposed. The moment a credential lives in a repo, everyone with read access has it, every clone carries it, every CI log can print it, and if the repo is ever made public it is broadcast to the internet. GitHub recorded over 39 million leaked secrets in 2024, a 67% jump year over year, and GitGuardian counted 28.65 million new hardcoded secrets pushed to public repos in 2025 alone. This is not a rare slip — it is the single most common way real systems get breached, which is why OWASP treats secrets management as a first-class concern.

The numbers on exploitation are the part that scares people into changing. Researchers planting honeypot AWS keys saw automated bots find and abuse them in about one minute, and security firms have measured scanners grabbing exposed keys within eleven minutes and immediately launching GPU instances. You do not get a grace period. By the time you notice the bad commit, the attacker has already used the key.

Git history is append-only, so deletion is a lie

The trap that catches most engineers: they git rm the file or delete the line, push, and believe the secret is gone. It is not. Git’s data model is append-only — every commit is preserved, and the secret sits in the history of every clone and fork forever. Anyone who runs git log -p or any scanner that walks full history (and they all do) reads it as easily as the current code.

So the cleanup has two parts, and only one of them actually matters. You can rewrite history with git filter-repo to scrub the blob from every commit — but that does not help anyone who already cloned, and you can never be sure no copy escaped. The step that ends the breach is rotation: revoke the leaked credential at its source so the value an attacker holds becomes worthless. Treat every secret that has ever touched a repo as compromised and rotate it. History rewriting is hygiene; rotation is the fix.

The maturity ladder: hardcoded → dotenv → managed

There is a clear progression in how teams handle secrets, and most outages happen because a team stalled on a lower rung.

The visual below is the ladder a senior climbs deliberately:

The big jump is from .env to a secrets manager. A .env file is genuinely better than hardcoding — it keeps the value out of the commit — but it is still plaintext sitting on every developer’s laptop and CI runner, readable by anyone with the box and invisible to any audit. A manager like HashiCorp Vault, AWS Secrets Manager, or SOPS adds the three things a .env can never give you: encryption at rest, access control (this service may read this secret and no other), and an audit trail of every read. When an incident happens, the audit log is what tells you whose credential to rotate and what it touched.

Short-lived beats long-lived: the TTL is the blast radius

The top rung is where senior teams aim, and it changes the math of a leak. A static, long-lived credential is the most common attack vector precisely because it stays valid until a human remembers to rotate it — which, after a leak, is often never. A dynamic secret is generated on demand with a built-in TTL and revoked automatically when it expires. Vault’s database engine, for example, mints a unique database user per request with a one-hour TTL in production; a leaked credential is dead within sixty minutes whether or not anyone noticed.

Two more properties fall out of this. Because each consumer gets a unique credential, the audit log can name the exact service instance that did something — you are not staring at one shared username used by everything. And dynamic creds make least privilege enforceable: each lease is scoped to exactly the permissions that role needs, so a stolen key for the read-only reporting service cannot delete the production database. The senior tradeoff is real — dynamic secrets cost the most to set up and need the app to fetch and renew leases — but for anything protecting production data, a one-hour blast radius beats an indefinite one.