Secrets leak through repos, logs, CI output, and chat threads long before sophisticated attackers arrive. This checklist is the minimum that keeps a small team safe.
Where secrets actually leak
Git history, pull request logs, CI variables echoed in build output, local dotenv files synced to cloud drives, screenshots, and support tickets are the common paths.
Assume anything pasted into a chat tool is stored. Design processes so the secret never needs to be pasted.
Minimum viable setup
A managed secret store (cloud KMS/Secrets Manager or equivalent), short-lived credentials where possible, and injection into runtime environments without writing secrets to disk.
Long-lived API keys should be rare, inventoried, and rotated on a schedule you can actually keep.
- Inventory every production secret: owner, system, last rotation.
- Block high-entropy strings in CI with pre-commit and secret scanning.
- Separate environments; never reuse production keys in staging.
- Use workload identity over shared static keys when the platform supports it.
Rotation and break-glass
Rotation that has never been tested is not rotation. Practice rotating each critical credential at least once with the team that would do it at 2 a.m.
Break-glass access to production secrets should be rare, logged, and reviewed after use.
A secret that cannot be rotated cannot be considered managed.
Habits when a secret leaks
Rotate first, investigate second. Preserve logs, revoke the credential everywhere it was used, and write down the path it took.
Post-incident, close the leak path with a control (scanning, TTL, injection) rather than a reminder to "be careful."
Key takeaways
- Map leak paths before buying more tools.
- Prefer short-lived credentials and workload identity.
- Inventory and rehearse rotation.
- Break-glass access must be logged and reviewed.
- On leak: rotate first, then fix the path with a control.