🔐 Secret Handling Checklist
Intro: Secrets are rarely lost because encryption exists. They are lost because storage, injection, rotation, and observation are inconsistent across pipelines and services.
Best time to use this checklist
Use it for new services, CI/CD changes, secret manager migrations, and incident follow-up after any credential exposure.
Stop-the-line conditions
- plaintext secrets in repository, image, manifest, or ticket;
- long-lived shared credentials where federation or short-lived auth is feasible;
- secrets injected into logs, crash output, or client-side storage;
- no owner or rotation plan for privileged credentials.
Text-first review prompts
- Where is the secret stored at rest, and who can read it?
- How is it delivered to the service or job at runtime?
- Can the same secret be replaced with short-lived credentials or federation?
- How is rotation tested, and how often does it happen?
- Which logs, alerts, and scans would detect accidental exposure?
- Does the secret appear anywhere it should never appear: client, repo, image, or ticket?
Evidence table
| Control area | What to verify | Typical evidence |
|---|---|---|
| Storage | Secret storage is centralized and access-controlled | vault policy, cloud secret manager config |
| Delivery | Injection method avoids plaintext sprawl | pipeline config, workload definition |
| Rotation | Owner, cadence, and fallback plan exist | runbook, rotation record |
| Exposure control | Secrets are redacted from logs and not baked into images | log config, Dockerfile review |
| Detection | Secret scanning and audit logs cover common leak paths | scan config, audit dashboard |
Common misses
- using environment variables everywhere without checking where they get copied or dumped;
- baking cloud credentials into CI variables long after OIDC is available;
- rotating a secret without testing dependent services;
- thinking a secret manager solves exposure if access policy is still broad.
Related pages
---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.