intermediate
2 min answer
A payments platform's secrets are in environment variables, set once at deployment. What is wrong, and what should replace it?
Show the full answer Hide the answer
What is wrong
- They cannot be rotated without a deployment, so rotation is a release event and therefore rare. Rare rotation means a leaked secret is valid for months.
- They leak into places nobody is watching: crash dumps, logs that print the environment, process listings, container inspection output, CI logs, and error-reporting payloads.
- They are visible to anything running in the container, including a compromised dependency, so a supply chain compromise is immediately a credential compromise.
- There is no audit trail. Nothing records which workload read which secret when, so the blast radius of a suspected leak is unknowable.
What should replace it
- Workload identity rather than shared secrets wherever possible. The workload proves what it is cryptographically and receives short-lived credentials. This eliminates the long-lived secret entirely, which is strictly better than managing it well.
- Fetch at runtime from a secrets manager, with the credential to that manager itself derived from workload identity rather than being another static secret.
- Short lifetimes with automatic renewal, so the exposure window of any leak is minutes rather than months.
- Per-workload scoping, so a compromise yields only what that workload could access.
- Audit logging of every read, which is what makes incident response possible.
The rotation property that matters most
Rotation must be routine, automated and frequent — not an incident response procedure. A rotation capability first exercised during a suspected breach will fail, and the failure will be discovered at the worst moment.
The test is simple: rotate a production credential today, on an ordinary afternoon, and see what breaks. Organisations that cannot do this do not have a rotation capability, whatever their policy says.
The detection layer
Because prevention is never complete: scanning for secrets in code, in build artefacts, in logs and in public repositories, with automated revocation on detection rather than a ticket. The window between a secret appearing publicly and being exploited is short enough that human triage is too slow.