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

Secrets via external secret manager

Demonstrate that all production applications and infrastructure components retrieve secrets exclusively from an approved external secret management system, with no hardcoded credentials present in code repositories, configuration files, or container images.

Description

What this control does

This control requires that sensitive credentials, API keys, certificates, and other secrets are retrieved at runtime from a dedicated external secret management platform (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk) rather than hardcoded in application code, configuration files, or environment variables. The secret manager enforces centralized access control, audit logging, rotation policies, and encryption at rest and in transit. This separation ensures secrets are never exposed in source code repositories, container images, or unencrypted configuration stores, and allows security teams to revoke or rotate credentials without redeploying applications.

Control objective

What auditing this proves

Demonstrate that all production applications and infrastructure components retrieve secrets exclusively from an approved external secret management system, with no hardcoded credentials present in code repositories, configuration files, or container images.

Associated risks

Risks this control addresses

  • Hardcoded credentials in source code repositories are discovered by attackers through public repository scanning or insider access, leading to unauthorized system access
  • Credentials stored in plaintext configuration files or environment variables are exposed during container image publication or log aggregation
  • Lack of centralized secret rotation forces manual credential updates across distributed systems, increasing the window of exposure after a compromise
  • Developers with code repository access gain unintended elevated privileges by accessing embedded production credentials
  • Secrets embedded in version control history remain accessible indefinitely even after subsequent removal, creating persistent attack vectors
  • Absence of secret access auditing prevents detection of unauthorized credential retrieval or lateral movement during breach investigations
  • Application redeployment requirements for credential rotation cause operational delays that extend the validity period of compromised secrets

Testing procedure

How an auditor verifies this control

  1. Obtain an inventory of all production applications, microservices, infrastructure-as-code modules, and automated workflows that require authentication credentials or API keys
  2. Review organizational policy documentation to identify approved external secret management platforms and integration standards
  3. Select a representative sample of 8-12 applications spanning different technology stacks and development teams for detailed examination
  4. Examine application source code repositories for each sampled application, searching for patterns indicating hardcoded secrets (API keys, passwords, private keys, connection strings) using automated secret scanning tools and manual code review
  5. Inspect runtime configuration files, Kubernetes manifests, Docker Compose files, and environment variable declarations to verify secrets are referenced as external lookups rather than literal values
  6. Review application authentication and initialization code to confirm integration with the designated secret manager API, including proper authentication, TLS verification, and error handling
  7. Query secret manager audit logs for evidence that sampled applications are actively retrieving secrets at runtime, correlating application deployment timestamps with secret access events
  8. Interview development and DevOps teams to validate that secret injection mechanisms (SDK integration, sidecar agents, init containers) are consistently applied across all deployment pipelines and documented in deployment runbooks
Evidence required Evidence includes exports of application source code repository secret scans showing no findings, configuration file excerpts demonstrating secret manager API calls or variable references, screenshots of secret manager access logs correlated with application deployment events, infrastructure-as-code templates showing secret manager integration patterns, developer interview notes confirming training and tooling availability, and approved secret management architecture diagrams with data flow annotations.
Pass criteria All sampled production applications retrieve secrets exclusively from the approved external secret management platform with no hardcoded credentials found in source code, configuration files, or container images, and audit logs confirm active runtime secret retrieval for all examined systems.

Where this control is tested

Audit programs including this control

Kubernetes Security Quick Check

A short audit of your k8s cluster against the high-impact controls — RBAC, secrets, network policies, image trust.

7 controls · v1.0