Secret management is the discipline of creating, storing, distributing, rotating and revoking credentials such as API keys, database passwords, tokens and certificates. A good setup keeps secrets out of source code, gives each one a narrow scope and an owner, and makes rotation routine rather than an emergency.
What is a secret?
Anything that proves identity or grants access and must not be public. API keys, database passwords, signing keys, cloud access tokens, and private keys for TLS are all secrets. The risk is not only theft. It is also staleness. A secret nobody rotates and nobody owns becomes a permanent backdoor for whoever once saw it.
What does OWASP recommend?
The OWASP Secrets Management Cheat Sheet organizes the work into a clear set of topics. Its general guidance covers:
- High availability. The system that holds secrets must not become a single point of failure.
- Centralize and standardize. Use one way of handling secrets instead of a different habit in every team.
- Access control. Limit who and what can read each secret.
- Automate. Automate creation and rotation, with patterns such as a sidecar container in Kubernetes or a serverless function that rotates database credentials.
- Handling secrets in memory. Treat memory as a place secrets can leak.
- Auditing. Record who accessed what.
- Secret lifecycle. Creation, rotation, revocation and expiration, each handled on purpose.
- TLS everywhere. Protect secrets in transit.
- Break-glass, backup and restore. Plan for downtime and recovery.
- Policies and metadata. Write rules down, and record enough about each secret to move it later.
- Passwordless authentication and token security. Prefer methods that avoid long-lived shared passwords.
The cheat sheet also has a section for CI and CD pipelines: hardening the pipeline, deciding where a secret should live (in the CI tooling, in a secrets management system, or not touched by CI at all), authentication of the tooling, logging and rotation.
Why does the lifecycle matter most?
Teams tend to invest in storage and forget the other three stages. Creation decides how strong and how scoped a secret is. Rotation limits the time a leaked secret is useful. Revocation lets you cut access fast when someone leaves or a leak is found. Expiration means that forgetting is safe: a credential that lapses on its own cannot linger for years.
A secret you cannot rotate without an outage is a secret you will not rotate. Design for that on day one by letting applications fetch current values at start or on a schedule, not baking values into builds.
A constructed example
A payments service reads its database password from an environment variable set in a deployment file stored in the repository. A developer leaves the company with a local clone. Rotating the password means editing the file, redeploying four services, and coordinating a short outage, so it keeps getting postponed. Two years later the password is unchanged and a laptop that holds it has been sold. If the service had fetched the password from a central store with automated rotation, the stolen clone would have held a credential that expired long ago.
How to check or apply this
- Find where secrets live today: code, config files, CI variables, chat, wikis and old images. Scan repositories and history, not only the current branch.
- Pick a central store and make it the default path for every new secret.
- Give each secret an owner, a scope and a rotation period.
- Automate rotation for the highest-risk secrets first: database credentials, cloud keys and signing keys.
- Replace long-lived static credentials with short-lived ones where your platform allows.
- Enable audit logs on the store and alert on unusual reads.
- Write the response for a leaked secret: revoke, rotate, find use, and check logs for misuse. Rehearse it once.
- Add checks to code review and CI that block commits containing secrets.
Quick check
Is an environment variable a safe place for a secret?
It is better than hard coding, but it is not enough alone. The value still needs a controlled source, limited access, rotation and auditing.
What should happen first when a secret leaks?
Revoke or rotate it so it stops working, then investigate where it was used and whether anyone misused it.
Sources
- OWASP Cheat Sheet Series: Secrets Management, fetched 18 October 2026.
Last reviewed: 18 October 2026.
