Secrets Management Standard Template (OWASP, NIST SP 800-57)

Secrets Management Standard: [Organisation name]

Organisation standard for secrets: what counts as a secret, inventory and classes, approved stores, issuance, rotation, dynamic short-lived credentials, workload identity in place of static keys, CI/CD and container rules, secret scanning, leak detection and revocation, break-glass access and audit. Informed by the OWASP Secrets Management Cheat Sheet (CC BY-SA 4.0), NIST SP 800-57 Part 1 Rev. 5 Recommendation for Key Management: Part 1, General (May 2020) for key lifecycle and cryptoperiods, and NIST SP 800-53 Rev. 5 (Release 5.2.0, August 2025) controls IA-5 (authenticator management), SC-12 (cryptographic key establishment and management) and SC-28 (protection of information at rest). Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Roles and responsibilities
3. Principles
4. Secret classes and inventory
5. Policy statements summary
6. Approved stores
7. Issuance and access
8. Rotation and expiry
9. Dynamic credentials and workload identity
10. CI/CD, containers and Kubernetes
11. Secret scanning and leak response
12. Break-glass access
13. Audit, logging and compliance measurement
14. Exceptions and risk acceptance
15. Related documents and control mapping
16. Glossary and references

1. Purpose and scope

1.1 Purpose

This standard sets the minimum rules for creating, storing, distributing, using, rotating, revoking and auditing secrets so that:

• no secret is stored in plain text where unauthorised people or systems can read it;
• every secret has an owner, a class, a store and a lifetime;
• static long-lived credentials are replaced by short-lived or identity-based access wherever the platform supports it;
• a leaked secret is detected quickly and revoked before it can be abused.

1.2 What is a secret

A secret is any value that grants access, proves identity or protects data and must stay confidential. Examples: passwords, API keys and tokens, OAuth client secrets, cloud access keys, database credentials, private keys (TLS, SSH, signing, encryption), symmetric data keys, webhook signing secrets, session signing secrets, recovery codes, and connection strings that embed credentials.

1.3 Scope

2. Roles and responsibilities

R = responsible, A = accountable, C = consulted, I = informed.

3. Principles

1. Eliminate before you protect. Prefer an identity-based or short-lived credential over any stored secret.
2. Centralise. Secrets live in an approved store, never in code, configuration files, images, tickets or chat.
3. Least privilege and least lifetime. Each secret grants the minimum access for the minimum time.
4. One secret, one purpose. Never share a secret between applications, environments or people.
5. Assume leakage. Design so that a leaked secret is detected, revoked and replaced without an outage.
6. Automate the lifecycle. Manual rotation is the exception, documented and scheduled.
7. Audit every access. Reads of high-value secrets are logged and reviewable.

4. Secret classes and inventory

4.1 Secret classes

4.2 Inventory record

Each S1 to S3 secret MUST have an inventory record, generated where possible from store metadata.

5. Policy statements summary

6. Approved stores

Requirements for every approved store:

1. Encryption at rest with keys under SM-11, and TLS for all access.
2. Fine-grained access policies per path or secret, managed as code and reviewed.
3. Audit logs of reads, writes and policy changes forwarded to the SIEM.
4. Versioning, so a rotation can roll back within the overlap window.
5. High availability and a tested recovery procedure; loss of the store is a severity-1 incident risk.
6. Removal of secrets from memory and temporary files on consumer hosts is the responsibility of the consuming application.

7. Issuance and access

7.1 Issuance rules

1. Generate secrets in the store or by the target system using a cryptographically secure random generator. Humans MUST NOT choose secret values for S1 to S3.
2. Minimum strength (Example): random API secrets of at least 256 bits of entropy; passwords for service accounts at least 32 random characters; key sizes and algorithms per the cryptography standard.
3. Register the inventory record (section 4.2) at creation, ideally by the same automation.
4. Deliver the secret only to the consuming identity through the store's access policy. If a human must transfer a secret to an external party, use a one-time, expiring share from the approved password manager.
5. Scope each secret to the narrowest permission the target system offers (read-only, single resource, IP or network restrictions where available).

7.2 Access control

• Access policies are granted to workload or human identities, versioned in a repository and approved by the secret owner.
• Human read access to S1 and S2 production secrets is not standing; it uses just-in-time elevation with a ticket reference.
• Access reviews: quarterly for S1, semi-annually for S2 (Example). Record results in the access review process.

8. Rotation and expiry

8.1 Rotation periods

All values are Example values. Adjust them to your risk assessment and the capabilities of the target systems.

8.2 Rotation method

1. Use dual-secret overlap: create the new secret, deploy it to consumers, verify use, then revoke the old one.
2. Automate rotation in the store where a rotation integration exists for the target system.
3. Record each rotation (date, method, operator or automation) in the store metadata.
4. Treat a rotation that fails, or that is more than 14 days overdue (metric in section 13.2), as a finding; fix it within 30 days (Example), or within the leak response target in section 11.3 if exposure is suspected.
5. When a secret cannot be rotated without downtime, record it as a design defect and plan a fix; do not extend the period silently.

9. Dynamic credentials and workload identity

9.1 Target patterns

9.2 Migration register

Cross-reference: posture reviews measure static key counts in Cloud Security Posture Review (security/cloud-security-posture-review), section 5.

10. CI/CD, containers and Kubernetes

10.1 CI/CD rules

1. Pipelines MUST obtain cloud and vault access by OIDC federation where supported (SM-05); stored CI secrets are limited to S3 (ST-04).
2. Scope credentials to the environment and protected branches; jobs from forks or untrusted pull requests MUST NOT receive secrets.
3. Do not print secrets, pass them as command-line arguments, or write them to artefacts or caches. Enable log masking as a backstop, not a control.
4. Pin third-party actions and plugins to a full commit hash or verified digest; a compromised dependency can read every secret the job holds. See Software Supply Chain Security Assessment Template (SLSA) (security/supply-chain-security).
5. Self-hosted runners for production deployments MUST be ephemeral, so no credential persists between jobs.

10.2 Container rules

1. Container images MUST NOT contain secrets in any layer, including layers deleted later; build-time secrets use the build tool's secret mount feature.
2. Do not pass S1 or S2 secrets as plain environment variables where a mounted file or runtime fetch is available; environment variables leak through crash dumps, debug endpoints and child processes.
3. Scan images for secrets in the registry and block promotion on a confirmed finding.

10.3 Kubernetes rules

1. Enable encryption at rest for Kubernetes Secrets using a KMS provider; base64 encoding is not encryption.
2. Prefer an external secrets operator or a CSI secrets store driver that syncs from the approved store, with namespace-scoped access.
3. Restrict get, list and watch on Secrets through RBAC to the workloads that need them; list on Secrets in a namespace exposes all of them.
4. Disable automatic mounting of service account tokens for pods that do not call the Kubernetes API.
5. Cluster-level design choices live in Kubernetes Cluster Design (ops/kubernetes-cluster-design).

11. Secret scanning and leak response

11.1 Scanning coverage

11.2 Leak response steps

1. Triage (SOC). Confirm the value is a real secret and identify the inventory record and owner. Check validity where safe (for example a provider's verification endpoint).
2. Revoke and replace (owner). Rotate the secret using the dual-secret method; if overlap is not possible, revoke immediately and accept the outage for S1.
3. Investigate (SOC). Search store and target logs for use of the leaked secret from the time of exposure. Expand to an incident if any unexpected use is found.
4. Remove the exposure (owner). Remove the secret from the location, purge caches and artefacts, and request removal from public sources. History rewriting is optional; revocation is mandatory.
5. Learn (security engineering). Record the root cause (how the secret reached that location) and fix the path, for example by adding a scanner rule or moving to workload identity.

11.3 Leak response targets

12. Break-glass access

1. Maintain break-glass accounts only for: cloud organisation administration, the identity provider, and the vault itself (Example list).
2. Store break-glass credentials outside the systems they recover, for example as split knowledge in sealed envelopes in two safes, or in a separate password manager tenant, with hardware MFA tokens held separately.
3. Any use MUST raise a high-priority SOC alert automatically.
4. Use requires two people, a declared incident or change, and a written log of actions taken.
5. Rotate the credentials and re-seal after every use, and test access at least every [6] months (Example) without exposing the credential.
6. Review the list of break-glass holders quarterly.

13. Audit, logging and compliance measurement

13.1 Audit logging

• Store audit logs (reads, writes, policy changes, authentication failures) are forwarded to the SIEM and retained per Security Logging Standard (security/security-logging-standard).
• Alerts (Example): any S1 read; S2 reads from a new identity or network; bulk reads; policy changes outside change windows; disabled audit device.

13.2 Metrics

Example (Corvid Commerce, Q3): 1,240 secrets in stores, 1,215 with an inventory record: coverage = 1,215 / 1,240 = 98.0%. 410 static secrets due for rotation, 398 rotated in period: compliance = 398 / 410 = 97.1%.

13.3 Compliance checks

14. Exceptions and risk acceptance

Rules: exceptions to MUST statements for S1 need CISO approval; all exceptions expire within 12 months (Example); expired exceptions become findings.

15. Related documents and control mapping

15.1 Control mapping

15.2 Related templates and documents

16. Glossary and references

16.1 Glossary

16.2 References

• OWASP Foundation, Secrets Management Cheat Sheet, OWASP Cheat Sheet Series (living document, CC BY-SA 4.0): https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1, General, May 2020: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0 (27 August 2025), controls IA-5, SC-12, SC-28: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• Kubernetes documentation, "Good practices for Kubernetes Secrets": https://kubernetes.io/docs/concepts/security/secrets-good-practices/
• Kubernetes documentation, "Encrypting Confidential Data at Rest": https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

Standard and licence note

Based on NIST SP 800-57 Part 1 Rev. 5 (May 2020) and NIST SP 800-53 Rev. 5 (Release 5.2.0, August 2025), which are works of the United States Government; control identifiers are cited and their intent is paraphrased. The topic coverage (general secrets management, CI/CD, cloud providers, containers and orchestrators, detection, incident response) is informed by the OWASP Secrets Management Cheat Sheet by the OWASP Foundation, licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). If you adapt or redistribute material taken from the OWASP cheat sheet, attribute OWASP and license that adapted material under CC BY-SA 4.0 (ShareAlike). The wording of this template is original. Check the current official versions at nist.gov and owasp.org before relying on this standard, as updates may have been published. Product and platform names are trademarks of their owners; this template is not affiliated with or endorsed by them. Template licence: MIT.