The OWASP Secrets Management Cheat Sheet is the best free reference on handling credentials in software. (If the term itself is new, what secrets management involves is the gentler starting point.) It is also written for organisations with platform teams, and reading it as a team of four can leave you feeling like you are doing everything wrong.
Most of it does apply to you. Some of it genuinely does not. This is a plain-English walkthrough of what it says, and an honest split between the parts a small team should act on this week and the parts that are for companies with a dedicated security function.
What the cheat sheet is
Part of the OWASP Cheat Sheet Series, a community-maintained set of concise security references. This one covers the full lifecycle of a secret: how it is created, stored, accessed, rotated, revoked, audited, and handled across CI/CD, cloud providers, containers and multi-cloud setups. It runs to eleven sections.
"Secret" means anything that grants access: API keys, database credentials, SSH keys, TLS certificates, encryption keys, service account tokens, IAM permissions, OAuth client secrets, signing keys.
The central argument is that secrets should be governed assets, not configuration values you happen to have lying around. That reframing is the useful part, and it applies at any team size.
The core recommendations
Centralise. One place secrets live, rather than scattered across .env files, CI settings, cloud consoles and someone's password manager. OWASP's reasoning is that scattered secrets are harder to protect, audit, rotate and investigate after an incident.
Fine-grained access control. Each secret should be readable only by the people and services that need it, following least privilege. OWASP notes this is the recommendation most often ignored in practice.
Automate rotation. Change credentials on a schedule without a human doing it by hand, and prefer dynamic secrets — credentials generated on demand for one session and expired afterwards — over long-lived static ones.
Audit everything. A log of who read and changed what, so an incident can be investigated.
No secrets in code, images or logs. Not in git, not baked into a container image, not printed in CI output.
Attribution. Shared credentials weaken incident response, because one leaked key could represent several services and you cannot tell which.
TLS everywhere, high availability, backup and restore for the secret store itself.
What applies to a team of 2 to 20
Act on these. They are achievable in a week and they close the gaps that actually bite small teams.
Get secrets out of git. The single highest-value action. Check .gitignore covers .env, and if anything sensitive was ever committed, rotate it and remove it from history. Deleting the file in a later commit is not enough.
Centralise on one thing. It does not have to be a product. Even "all secrets live in this one place and that is the rule" beats four half-remembered locations. If you are using .env files today, what is a .env file covers doing that properly, and the tools comparison covers the managed options.
Separate environments. Development, staging and production credentials should be different values in different places. Most small-team incidents are someone running a script against the wrong environment, not an attacker.
Keep secrets out of CI logs. Use your CI's secret store so values are masked, and never echo a secret after transforming it. Injecting environment variables into builds covers this per platform.
Know who can read what. Not a formal ACL matrix. Just be able to answer "if this person left tomorrow, what could they still access." If the answer is "everything," that is your gap.
Rotate on departure. When someone leaves the team, rotate what they had access to. This is the rotation that matters most and it is event-driven, not scheduled.
What is written for larger organisations
Do not feel behind for skipping these. They solve problems that appear at scale.
Dynamic secrets. Credentials generated per session with a short TTL. Genuinely excellent, and it requires infrastructure — HashiCorp Vault or a cloud provider's equivalent, plus someone to run it. For four people and one database, static credentials rotated on a sensible schedule are a reasonable position.
Automated rotation pipelines. OWASP's own example is a serverless function rotating database credentials. That is a project. Manual rotation on a calendar reminder is a defensible interim step.
Full secret consumer inventory. A live register of every application, pipeline and operator that can read each secret. Sensible at fifty services. At five, you can hold it in your head.
Multi-cloud secret governance. Only relevant if you are multi-cloud.
Kubernetes-specific guidance — mounting secrets as volumes rather than environment variables, encrypting etcd at rest. Only if you run Kubernetes.
The CI/CD section is the one to read
If you read one section properly, make it the CI/CD one. Build and deployment systems sit close to production access, which makes pipeline credentials disproportionately valuable, and small teams tend to be sloppiest exactly here.
OWASP's specific points:
- Log and alert on secret access, so extraction or misuse is detectable
- Forks and copied job definitions must not carry secrets with them
- Document which secrets your CI holds and why
- CI tooling should use designated service accounts scoped to only what a job needs
- A pipeline run should be attributable to whoever triggered it
- Prefer retrieving secrets at runtime over storing them as CI variables
That last one is the meaningful shift. Instead of copying twelve secrets into your CI settings, the pipeline holds one credential for a secrets manager and pulls the rest at run time. Fewer places to update, one thing to rotate, and secrets are not sitting in a settings page.
A short checklist
Things a small team can genuinely tick off:
.envis in.gitignoreand nothing sensitive is in git history- Development, staging and production use different credentials
- Secrets are in one agreed place, not four
- CI secrets are in the CI secret store, not in the workflow file
- Nothing echoes a secret to a log
- You can say who has access to production credentials
- Credentials get rotated when someone leaves
- There is a plan for what to do if a key leaks, even a one-paragraph one
Where tools fit
OWASP is deliberately vendor-neutral. It names the categories — cloud provider secrets managers, dedicated products, encrypted files — and lets you choose.
For a small team the practical options are your cloud provider's native manager if everything runs on one cloud, a hosted secrets manager, or a self-hosted open source one if you are happy running it. The comparison post covers the trade-offs. Krypt, which we build, is one of the hosted options, priced flat rather than per seat.
Being straight about it: a tool gives you centralisation, access control and an audit log for very little effort. It does not give you rotation discipline, environment separation, or the habit of not pasting keys into Slack. Those are process, and no product fixes them.
FAQ
What is the OWASP Secrets Management Cheat Sheet? A free, community-maintained security guide covering the full lifecycle of credentials — creation, storage, access control, rotation, revocation, auditing — across CI/CD, cloud, and containers.
Is it only for large organisations? No, but parts of it are. Centralisation, environment separation and keeping secrets out of git apply to everyone. Dynamic secrets and automated rotation pipelines assume infrastructure most small teams do not have.
What does OWASP say about environment variables? They are acceptable for delivering secrets to an application, with caveats: they can leak through process listings, crash dumps and logs. For Kubernetes specifically, OWASP prefers mounted volumes over environment variables.
How often should secrets be rotated? OWASP prefers short-lived dynamic secrets over a fixed schedule. Where that is not possible, rotate on a defined cadence and always on a departure or suspected leak.
Do I need a secrets manager to follow it? No. You need centralisation, access control and auditability. A tool is the easiest way to get all three, but a disciplined single .env source with strict git hygiene satisfies the principles at very small scale.