Secrets Management: The Part of Security Everyone Ignores Until It's a Breach

The most common security breach pattern in modern software isn’t a sophisticated zero-day exploit. It’s a secret committed to git, or exposed in a log file, or sent in a Slack message and then forgotten. Secrets management is the unsexy foundation of application security that most teams treat as an afterthought.

The Threat Model Most Teams Miss

It’s not just about keeping secrets out of git. Secrets in git is the obvious problem. Less obvious: secrets in application logs (logging request headers that contain auth tokens), secrets in error messages returned to clients, secrets in environment variables that get exported in debugging output, and secrets in container images that are pushed to public registries.

The Modern Secrets Management Stack

For organizations running on AWS: Secrets Manager or Parameter Store, accessed at runtime via IAM roles. For Kubernetes: sealed secrets or external secrets operator backed by Vault or cloud provider secrets services. The key principle: your application should never have secrets baked in at build time. They should be fetched at runtime, with access controlled by identity rather than possession.

Secret Rotation: The Practice Everyone Skips

Rotating secrets regularly limits the blast radius of exposure. If a secret has been compromised but was rotated six weeks ago, the attacker’s access is limited to six weeks. Most organizations rotate secrets never, or only in response to a known breach. Automated rotation with zero-downtime credential updates is achievable for most secret types and worth the engineering investment.