Security
Secrets management: climb the maturity ladder
Reading about secret leaks is not the same as remediating one. Start with a service that has a live credential committed to git, treat it as a real breach, and climb the unit’s maturity ladder rung by rung — rotating, centralising, scanning, and shortening lifetimes — with evidence at every step.
Turn the unit’s mental model into a reproducible engineering loop: remediate a leak correctly, move secrets into a manager with access control and audit, gate the repo with a scanner, and reach dynamic short-lived credentials — proving each rung works.
Take a small service with a hardcoded database (and/or third-party) credential committed to git and bring it to a managed, scanned, least-privilege, short-lived-secret setup — treating the existing commit as a real leak and proving each rung of the ladder with evidence.
- A before/after of the leak: the secret visible in git history at the start, and absent from history with the credential rotated (the old value provably rejected) at the end.
- The app authenticates using a secret pulled from the manager at runtime, with an audit-log entry shown naming the reader — no secret in the repo, the image, or a tracked file.
- The scanner blocks a re-introduced test secret at commit time (paste the hook output) and the CI scan passes on the cleaned history.
- A dynamic credential demonstrably expires: a captured session that works inside the TTL and is rejected after it, plus one paragraph mapping each step to its rung on the maturity ladder and why it ranked where it did.
- Add envelope encryption for an at-rest config blob: encrypt locally with a KMS-issued data key, store only the wrapped data key, and show decrypt works while the KMS never sees the payload.
- Wire automatic rotation for one static secret (manager-driven rotation lambda/job) and prove the app picks up the new value with zero downtime.
- Write a one-page incident runbook: detect a leaked key, rotate first, check provider audit/billing logs, scrub history, scan, and verify — with the exact commands for your stack.
- Add a CI gate that fails the build if any service still reads a long-lived static secret where a dynamic one is available, and document the policy.
This is the loop you will run on every real secrets incident and migration: treat a committed secret as leaked and rotate first, scrub history only as hygiene, move the value into a manager with access control and an audit trail, gate the repo with a scanner so the next mistake never lands, enforce least privilege, and climb to dynamic short-lived credentials whose TTL bounds the blast radius. Doing it once on a small service, with evidence at each rung, makes the production version muscle memory.