Secrets stored in a managed vault
Demonstrate that all production and development secrets are stored in a managed vault with appropriate access controls, encryption, and audit logging enabled.
Description
What this control does
This control requires that cryptographic secrets (API keys, database passwords, private keys, tokens, service account credentials) be stored exclusively in a dedicated secrets management vault such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or CyberArk. Secrets are not stored in source code, configuration files, environment variables, or unencrypted databases. The vault enforces access controls, audit logging, encryption at rest and in transit, and supports automated rotation where feasible, reducing exposure from credential leakage.
Control objective
What auditing this proves
Demonstrate that all production and development secrets are stored in a managed vault with appropriate access controls, encryption, and audit logging enabled.
Associated risks
Risks this control addresses
- Hardcoded credentials in source code repositories are exposed via version control history or public repository leaks
- Plaintext secrets in configuration files or environment variables are accessible to unauthorized users or processes with filesystem access
- Leaked credentials in CI/CD pipelines, container images, or infrastructure-as-code templates allow lateral movement or privilege escalation
- Secrets stored in unencrypted databases or shared documents are compromised during data breaches or insider threats
- Lack of centralized secret rotation enables prolonged exploitation after initial credential compromise
- Absence of audit trails prevents detection of unauthorized secret access or exfiltration attempts
- Overly permissive access to secrets enables attackers to pivot between systems after initial foothold
Testing procedure
How an auditor verifies this control
- Obtain an inventory of all applications, services, databases, and infrastructure components that require secrets for authentication or encryption.
- Review source code repositories (using automated scanning tools such as TruffleHog, GitLeaks, or git-secrets) to identify any hardcoded secrets, API keys, or credentials committed to version control.
- Examine CI/CD pipeline configurations, Dockerfiles, Kubernetes manifests, and infrastructure-as-code templates (Terraform, CloudFormation) for plaintext secrets or references to unmanaged secret storage.
- Inspect application configuration files, environment variable configurations, and container orchestration secrets to verify all secret references point to the managed vault API or secret injection mechanism.
- Review the secrets management vault configuration to confirm encryption at rest is enabled, access control policies follow least privilege, and multi-factor authentication is required for administrative access.
- Select a representative sample of secrets from the vault and trace their usage in production systems to verify applications retrieve secrets programmatically at runtime rather than storing them locally.
- Examine vault audit logs for a defined period (minimum 90 days) to verify comprehensive logging of secret access attempts, modifications, and administrative actions.
- Validate that secret rotation policies are defined and enforced, and review evidence of recent rotation events for high-privilege credentials such as database root passwords and service account keys.
Where this control is tested