Stop Committing Secrets: A Practical Guide to Secret Management

API keys, passwords, and tokens end up in git history, logs, screenshots, and chat threads with depressing regularity, and every one of them is a breach waiting for its moment. This guide shows how to stop committing secrets for good: find what is already exposed, move everything into a vault, scope and rotate with discipline, block recurrence automatically, and run a calm leak response when prevention fails anyway.

The principle is simple. Secrets do not belong in places built for sharing. Code, logs, chat, and screenshots are shared by design, so anything sensitive that touches them is already halfway leaked. Move secrets into systems built for secrecy, and most of the problem disappears before willpower gets involved.

Here is the sequence:

1. Learn how secrets actually leak

2. Find what is already exposed

3. Move everything into one vault

4. Scope tightly and rotate on schedule

5. Block recurrence automatically

6. Run the leak-response runbook

7. Connect it to the rest of your defenses

How Secrets Actually Leak

Ask a team where their secrets live and you will hear "the vault" while the truth sprawls across five other places. The commit history holds the classic: an AWS key pasted for a quick test in 2021, still retrievable by anyone who clones the repo today. Deleting the file later does not help. Git never forgets unless you rewrite history and rotate the key, and most teams do neither.

Logs are the quiet second source. Full API keys printed in debug output, tokens echoed in CI logs, database URLs in error pages. Anyone with log access holds the keys, which usually means far more people than intended. Then come the human channels: screenshots of config screens posted for debugging help, secrets pasted into chat threads that persist forever, environment files backed up to places with different access controls than production.

Notice the pattern. Every leak path is a sharing system doing its job. The fix is never "be more careful," because careful people under deadline paste secrets too. The fix is making the careless path hard: secrets that cannot be pasted because developers never see them, and systems that refuse to accept them in the wrong places.

Find What Is Already Exposed

Before building the new system, confront the old one. Assume exposure and go looking, because attackers with tooling certainly will.

Start with your own history. This command searches every commit your repo has ever seen for a private key header:

git log --all --oneline -S 'BEGIN RSA PRIVATE KEY' -- .

It prints each commit that added or removed that string. Extend the same technique to the usual suspects: AKIA for AWS keys, sk_live for Stripe-style tokens, BEGIN OPENSSH PRIVATE KEY for modern keys, and your own product's token prefixes. No matches is good news about that pattern, not proof of cleanliness, so treat scanning as sampling, not certification.

Do not stop at git. Search chat history and wikis for the same patterns, check CI logs for echoed secrets, and look at the backup from the restore drill with fresh eyes: environment files ride along in backups with different access controls than production. Every finding triggers the same response, which is section 6 of this guide, not a quiet deletion. A deleted secret that was never rotated is still a live credential in someone else's copy of history.

Move Everything Into One Vault

Scattered secrets cannot be managed, so consolidate first. Pick one secrets manager for the team, whether a hosted vault service or your platform's native secret store, and migrate every credential into it. One home means one access log, one rotation point, and one place to lock down, instead of a dozen files and wikis of varying permissions.

Change how applications receive secrets at the same time. Code reads from the environment or the vault at runtime. Nothing sensitive lives in source files, container images, or deployment scripts. This single rule eliminates the largest leak class at a stroke: a repo with no secrets in it cannot leak them, no matter who clones it or screenshots it.

Handle the transition deliberately. Inventory every secret first, because the ones you forget are the ones that break at 2am after migration. Move in waves by blast radius, smallest first, verifying each service still starts and serves. Keep the old locations readable-but-deprecated during the move, then delete them and rotate everything that ever lived there. End state: developers never see production secrets at all. They reference names, the platform injects values, and the actual bytes exist in exactly one place.

Scope Tightly and Rotate on Schedule

A vault full of master keys is a single point of failure wearing a fancy lock. Give every credential the minimum power it needs, following the least-privilege discipline: read-only where reading suffices, single-service where one service suffices, short-lived where temporary suffices. Narrow scopes turn a leaked key from a catastrophe into a bounded incident.

Then rotate before you must. Scheduled rotation converts stale credentials from ticking bombs into expired trivia: quarterly for most keys, faster for high-value ones, immediate on any suspicion or personnel change. Automate rotation where the platform supports it, because manual rotations get postponed exactly when they matter most. Each rotation should be boring and uneventful, which is how you know the system works: services pick up new credentials without downtime, because that path was designed and tested.

Track expiry like inventory. Every secret gets an owner, a scope note, and a rotation date in one register. Unknown secrets are unrotated secrets, so the register doubles as the audit list. When someone leaves, one page tells you exactly which credentials their access touched, and revoking becomes an afternoon instead of an archaeology expedition.

Block Recurrence Automatically

Humans under deadline will always take the shortest path, so make the safe path the short one and the unsafe path a wall. Three guardrails, layered, catch what discipline misses.

First, pre-commit hooks that refuse secrets before they enter history. A hook that scans staged changes for key patterns and blocks the commit turns "oops" into a thirty-second fix instead of a rotation incident. Install it team-wide through a shared config, not as optional advice, because the one repo without it is where the leak lands.

Second, CI scanning on every push as the backstop for everything hooks miss: force-pushed history, unusual file types, contractors' machines without the hooks installed. Fail the build loudly on findings, and route the alert to someone who owns the response, not into a dashboard nobody reads. A scanner whose alerts go nowhere is decoration.

Third, make the review norm explicit: secret-shaped strings in diffs get flagged, every time, no matter how senior the author. Normalize calling it out kindly and fixing it instantly. Culture is what happens when nobody is watching, so write this one into the contributing guide where newcomers read it on day one.

Run the Leak-Response Runbook

Despite everything, assume a leak will eventually happen, because it will. What separates teams is not perfection but the practiced response, straight from the runbooks shelf: trigger, steps, owners, in writing, before the adrenaline starts.

Revoke first, investigate second. Disable the exposed credential immediately, before assessing blast radius, because every minute of validity is a minute of exposure. Then assess: what did it access, what logs cover the exposure window, what else used the same secret. Then rotate everything in the blast radius, not just the leaked key, since shared and derived credentials fall together.

Notify honestly and proportionally. Internal stakeholders get the full timeline. Customers get told when their data was actually at risk, plainly and promptly, with what you did about it. Cover-ups that surface later cost multiples of the original incident in trust. File the postmortem, update the runbook with what the response taught you, and close the loop by fixing the guardrail gap that let it through.

Connect It to the Rest of Your Defenses

Secrets management is not a standalone practice. Scoped keys are the least-privilege layer from the hardening guide, made concrete. The vault migration follows the same rehearsed-change discipline as the deploy playbook minus the outage: stage, verify, switch, watch. The leak runbook lives next to the incident runbooks, because a leaked master key is an incident wearing a different hat.

Start this week with the scan. Run the history search on your most important repo, and let whatever you find set the agenda: rotation first if it is dirty, vault migration if it is merely fragile. One afternoon of honest inventory beats a year of assuming the best. Secrets you cannot see are secrets you cannot protect, and after today, you will have seen yours.

Featured image: title card generated for this post.