Secrets management

A secret is any credential an application needs to authenticate: a database password, an API key, a signing certificate, a token for another service. Secrets management puts these in a dedicated store rather than in source code or config files. The store enforces access control (only the identities that need a secret can read it), keeps an audit trail of who read what, and supports rotation so a leaked secret has a short useful life. An application fetches the secret at run time and uses it. This is the key difference from a KMS: a secrets manager gives the secret back so the application can read and use it, whereas a KMS keeps key material and returns only the results of operations.

Secrets escape the store far more often than the store fails. On the estates we test, credentials are hard-coded in source, committed to repositories (and preserved in the history even after being deleted from the current file), baked into container images, left in environment variables that leak through logs, and embedded in Terraform state. The other recurring problem is the long-lived access key that never rotates, so a secret exposed once stays valid indefinitely. From the attacker’s seat, the first hour on any target is spent searching exactly these places, because a found secret skips every other control and authenticates directly.

We hunt for secrets where they actually leak: source and its full history, CI and build pipelines, container images, configuration, and infrastructure state. Any secret found is reported with its scope and validity, and the finding pushes towards a managed store with rotation and least-privilege access rather than a one-off cleanup, since deleting the current copy leaves the history intact. The fix is tied back to infrastructure as code where templates carry the secret. This is part of how we hunt for secrets in code and pipelines.