Secrets Management

Keys, tokens and environment configuration.

Nothing launched in this category yet.

Be the first

About Secrets Management

Secrets management is the discipline of keeping credentials out of your code and controlling who and what can use them. It is unglamorous, it is the source of a large share of real breaches, and the tooling for it is genuinely good — which makes the persistence of API keys in repositories one of the more avoidable problems in software.

The baseline is straightforward: secrets do not go in source control, they are injected at runtime from a store, and every environment has its own. Getting this far removes the most common exposure path, which is a repository becoming public or a laptop being compromised with a full history on it. Scanning tools that block a commit containing something that looks like a key are cheap and catch the mistake at the only point where fixing it is easy.

Rotation is where practice usually falls down. A secret that has never been rotated is one where every person who has ever had access still effectively has it, including people who left. The tooling that makes rotation routine — short-lived credentials issued on demand rather than long-lived keys distributed to services — is a meaningfully better model, because a credential valid for an hour is much less interesting to steal.

For applications, the strongest pattern available now is workload identity: a service proves what it is to the platform and receives a scoped, temporary credential, with no static secret existing anywhere. Where the platform supports it, this eliminates the category of problem rather than managing it.

Access control and audit are what distinguish a secrets manager from an encrypted file. Knowing which service read which secret and when is the difference between a contained incident and a full credential rotation across an entire estate, because without the audit trail you cannot scope the blast radius and must assume the worst.

If a secret is exposed, the order is: revoke first, then investigate. Removing it from the repository history does not help, because it was public and anything public is scraped within minutes. Treat every exposed key as compromised regardless of how briefly it was visible.

For personal credentials rather than machine ones, see [password managers](/categories/password-managers).

From the blog

Reading on launching, ranking and secrets management.

All posts