Secrets, .env, and leaks in logs & commits

.env files and cloud credentials are the fastest way to turn a demo into an incident. Leaks rarely happen only in one place—they propagate through shell history, CI output, crash dumps, and forked repos. Design workflows so secrets live in managed stores and short-lived tokens, not in long-lived strings in your tree.

This lesson’s layout: nested rings show where secrets sit in depth; code-explorer dissects a risky file; timeline walks through a classic leak arc; the table compares storage options; grid cards list concrete mitigations.

Where the secret actually lives
Outer ring is what humans see first—inner rings are where recovery gets harder.
Layers
Working copyGit historyAutomation
Outer ring is what humans see first—inner rings are where recovery gets harder.
Smell-test: a dangerous .env fragment
Line by line—what would you rotate first after a leak?
bash
1
DATABASE_URL=postgres://svc:SuperSecret@db.internal:5432/app
▼
2
AWS_ACCESS_KEY_ID=AKIA...
▼
3
SLACK_WEBHOOK=https://hooks.slack.com/...
▼
4
# committed by mistake — rotate everything below
▼
How a leak unfolds over time
Click each point—use it when writing your incident retrospectives.
Where should configuration live?
No single answer—combine approaches: dev convenience vs blast radius.
ApproachTypical use
.env (gitignored)Local dev only—never rely on it in production runtime.
Secret managerVault, AWS SM, GCP SM—audited access and rotation hooks.
CI secrets / OIDCPipelines need credentials—prefer federated identity over static keys.
Hardening checklist
Pick one improvement per sprint—compound gains beat one-off panic fixes.
If a secret touched a public branch, assume it is burned—rotate and audit access logs, not just delete the file in HEAD.