Skip to main content
← All controls
IA-5(7) / SC-12 / SC-28 / AU-2 NIST SP 800-53 Rev 5

How are secrets (API keys, DB passwords) stored and accessed?

Demonstrate that all secrets are stored in approved secrets management solutions with encryption, access controls, rotation policies, and audit trails, and are not embedded in source code, configuration files, or unencrypted storage.

Description

What this control does

This control governs the secure storage, retrieval, and lifecycle management of secrets such as API keys, database passwords, encryption keys, certificates, and service account credentials. Secrets must be stored in dedicated vaults or secrets managers with encryption at rest, fine-grained access controls, and audit logging, rather than in code repositories, configuration files, environment variables, or wikis. Proper implementation prevents credential exposure through source code leaks, reduces lateral movement risk after initial compromise, and enables centralized rotation and revocation.

Control objective

What auditing this proves

Demonstrate that all secrets are stored in approved secrets management solutions with encryption, access controls, rotation policies, and audit trails, and are not embedded in source code, configuration files, or unencrypted storage.

Associated risks

Risks this control addresses

  • Hardcoded credentials in source code repositories are exfiltrated by attackers through public repository exposure or compromised developer workstations
  • API keys stored in plaintext configuration files enable lateral movement after web server or container compromise
  • Database passwords shared via email, Slack, or wikis are harvested by attackers with access to collaboration tools or backup archives
  • Secrets stored in environment variables are exposed through application error messages, process listings, or container image layers
  • Absence of secrets rotation capability allows compromised credentials to remain valid indefinitely, extending attacker dwell time
  • Lack of audit logging for secrets access prevents detection of credential abuse or insider theft
  • Secrets embedded in CI/CD pipeline configurations are leaked through pipeline logs or disclosed in build artifacts

Testing procedure

How an auditor verifies this control

  1. Obtain and review the organization's secrets management policy, approved secrets storage solutions (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk), and lifecycle procedures including rotation schedules
  2. Inventory all systems, applications, and services that consume secrets, categorizing by environment (production, staging, development) and secret type (database credentials, API keys, certificates, encryption keys)
  3. Select a representative sample of applications and services across environments and retrieve their configuration files, environment variable definitions, container images, and infrastructure-as-code templates
  4. Scan the sampled configurations, source code repositories (including commit history), and container images using automated secrets detection tools (e.g., GitGuardian, TruffleHog, git-secrets) to identify hardcoded or embedded credentials
  5. Verify that sampled applications retrieve secrets programmatically from the approved secrets manager by reviewing application code, deployment manifests, and authentication workflows to the secrets service
  6. Examine access control policies within the secrets manager to confirm least-privilege access, role-based restrictions, and segregation between environments (developers cannot access production secrets)
  7. Review secrets manager audit logs for a 30-day period to validate logging of all access events, including retrieval, creation, rotation, and deletion operations, with user and application identity attribution
  8. Test secrets rotation procedures by selecting three high-risk credentials (production database, payment gateway API key, admin service account) and verifying documented rotation schedules, last rotation dates, and automated rotation capability where implemented
Evidence required Collect secrets management policy documents, approved secrets manager configurations including access control policies and encryption settings, screenshots of secrets manager interfaces showing stored secret metadata (names, last rotation dates, access logs), automated scan reports from secrets detection tools run against code repositories and container images, application configuration files demonstrating programmatic secrets retrieval, audit log exports from secrets managers for the review period showing access events, and rotation procedure documentation with evidence of recent rotations for sampled credentials.
Pass criteria All sampled secrets are stored in approved encrypted secrets managers with role-based access controls and audit logging enabled, no credentials are hardcoded in source code or configuration files, applications retrieve secrets programmatically at runtime, and rotation procedures are documented and evidenced for high-risk credentials.