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?

razorpaysecretsrotationworkload-identityleakage
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.