APP-008 Secrets Management
Description
Secrets — including API keys, database credentials, tokens, private keys, and service account passwords — are stored in approved secrets management systems. Secrets must not be hardcoded in source code, configuration files, or version control. Access to secrets is logged and audited. Secrets are rotated on a defined schedule and immediately upon suspected compromise.
Rationale
Hardcoded and poorly managed secrets are among the most commonly exploited vulnerabilities in cloud-native and SaaS environments. Secrets leaked to version control are frequently discovered by automated scanners within minutes.
Framework Mappings (4)
| IAM-14 | Credentials Management | partial |
| 5.17 | Authentication information | partial |
| IA-5 | Authenticator Management | partial |
| CC6.1 | Logical Access Security Software, Infrastructure, and Architectures | informative |
Evidence (2)
Secrets management vault configuration showing that approved secrets management tooling is in use, with access control, audit logging, and rotation policies configured.
Example: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault configuration export showing: secret paths with access policies, rotation rules (TTL or Lambda rotation function), and audit logging enabled.
Test: Review the secrets management platform configuration. Verify: (1) audit logging is enabled and logs are being captured, (2) each secret has an access policy restricting access to named services or roles (no wildcard '*' principals), (3) rotation is configured for all long-lived credentials with a TTL or scheduled rotation, (4) the vault is not publicly accessible and requires authentication to access.
Secret scanning tool output confirming no secrets are hardcoded in source code or version control history.
Example: truffleHog, git-secrets, GitHub Secret Scanning alerts page, or Gitleaks CI scan report for all production repositories, showing zero open high-confidence secret findings in the current codebase and no unresolved alerts in version control history.
Test: Run a secret scanning tool (e.g. truffleHog --json, gitleaks detect) against all production repositories including full git history. Verify: (1) zero high-confidence secrets are present in the current HEAD of any production branch, (2) any historical findings in git history have been remediated (secrets rotated and history cleaned or invalidated), (3) the scan runs automatically in CI on every PR — confirm via pipeline configuration.
Questions (2)
Are all secrets — including API keys, database credentials, tokens, and private keys — stored in an approved secrets management system, and is hardcoding secrets in source code or version control prohibited?
Both elements are required: approved vault storage AND an active prohibition on hardcoding. A policy without tooling enforcement (e.g. secret scanning in CI) is insufficient.
Which secrets management controls are in place in your development and deployment environment?
A vault combined with CI-based secret scanning provides both preventative and detective coverage. Secrets logged in a vault with rotation policies indicate a mature posture.