Guidance
Principles for building a mature secrets management program.
No secrets in source code, config files, container images, or CI/CD scripts. Use environment injection or runtime API calls to retrieve secrets from a vault.
Grant access to specific secrets, not entire vaults. Use role-based or attribute-based access control. Every service gets only the credentials it needs.
Set rotation schedules and automate the process. Prefer short-lived dynamic secrets over long-lived static credentials whenever the downstream system supports it.
Log who accessed which secret, when, and from where. Feed logs into your SIEM for anomaly detection. This is essential for compliance and incident response.
Use AES-256 or equivalent for storage. All API calls to the secrets manager must use TLS. Consider envelope encryption where the vault manages the data encryption key.
Run secret scanning tools in CI/CD and as pre-commit hooks. Monitor public repositories and paste sites for your organization's credentials. Treat any detected leak as a security incident.
Generate unique, short-lived credentials per session or request. If a dynamic secret is compromised, it expires before an attacker can exploit it.
Consolidate secrets into a single platform. Secrets sprawled across .env files, CI tools, wikis, and spreadsheets are impossible to govern and audit.
Know how to revoke and rotate all secrets quickly. Practice incident response runbooks. Identify which secrets are most critical and prioritize their recovery procedures.
Development, staging, and production should each have their own set of secrets. Never reuse production credentials in lower environments.