IA-5(7) / SC-12(2) / SC-28(1) NIST SP 800-53 Rev 5

Credentials vaulted (no hardcoded secrets)

Demonstrate that all application and infrastructure credentials are stored in approved secret management systems and retrieved dynamically, with no secrets hardcoded in source code, configuration files, or deployment artifacts.

Description

What this control does

This control ensures that authentication credentials, API keys, tokens, passwords, certificates, and other secrets are not embedded directly in source code, configuration files, container images, or scripts. Instead, secrets must be stored in dedicated vaulting solutions (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk) and retrieved at runtime through secure APIs or environment variable injection. Hardcoded secrets create immutable attack surfaces: once committed to repositories or deployed to systems, they are difficult to rotate and vulnerable to exposure through code review, logs, or binary inspection. This control is critical for preventing credential leakage, enabling centralized secret rotation, and enforcing least-privilege access through dynamic credential provisioning.

Control objective

What auditing this proves

Associated risks

Risks this control addresses

Attacker extracts hardcoded credentials from source code repositories (including commit history) to gain unauthorized access to production systems or databases
Credentials embedded in container images or AMIs are discovered through image scanning or layer inspection, enabling lateral movement across cloud environments
Inability to rotate compromised credentials rapidly because secrets are distributed across codebases, requiring code changes and redeployment cycles
Accidental exposure of secrets in log files, error messages, or debug output where hardcoded credentials are passed as plaintext parameters
Developer workstations or CI/CD pipeline artifacts containing hardcoded secrets are compromised, granting persistent access to production resources
Insider threat actors with code repository access harvest credentials for unauthorized data exfiltration or system manipulation
Third-party code dependencies or open-source contributions inadvertently expose organization-specific credentials committed to public repositories

Testing procedure

How an auditor verifies this control

Obtain a complete inventory of applications, services, microservices, infrastructure-as-code repositories, and CI/CD pipelines in scope for the audit period.
Request documentation of the organization's approved secret management solutions, including vault product names, deployment architecture, access control policies, and integration methods.
Select a representative sample of source code repositories (minimum 10% or 15 repositories, whichever is greater) spanning different development teams and technology stacks.
Execute automated secret scanning tools (e.g., TruffleHog, git-secrets, Gitleaks) against sampled repositories, including full commit history, to detect patterns matching credentials, API keys, private keys, and tokens.
Manually inspect configuration files (e.g., application.properties, .env files, docker-compose.yml, Kubernetes manifests, Terraform configurations) within sampled repositories for plaintext credentials or suspicious base64-encoded strings.
Review application runtime configuration by examining environment variable injection mechanisms, secret volume mounts, or vault SDK implementations to verify dynamic credential retrieval.
Examine CI/CD pipeline configurations (e.g., Jenkins pipelines, GitHub Actions workflows, GitLab CI files) to confirm secrets are referenced through vault integrations or masked variables rather than plaintext values.
Interview development and DevOps staff to validate understanding of secret vaulting requirements, onboarding processes for new applications, and procedures for remediating discovered hardcoded secrets.

Evidence required Collect automated secret scanning reports showing scan execution timestamps, repositories scanned, and findings (true positives must be zero or remediated with proof); configuration exports from vault solutions demonstrating registered secrets and access policies; code repository excerpts (sanitized screenshots or pseudocode samples) illustrating vault API calls or environment variable references; CI/CD pipeline configuration files showing secret injection mechanisms; and remediation tickets or change records for any historical hardcoded secrets discovered during the audit period.

Pass criteria No hardcoded secrets are present in current source code, configuration files, container images, or infrastructure-as-code within sampled repositories, all applications retrieve credentials dynamically from approved vault solutions, and automated secret scanning is integrated into CI/CD pipelines with blocking enforcement on detection.

Where this control is tested

Audit programs including this control

Service Account Hygiene

Service accounts get over-privileged and never rotated — quick health check on inventory, scoping and credential rotation.