APP-008 Secrets Management
Description
Secrets, including API keys, database credentials, tokens, private keys and service account passwords, are held in an approved secrets management system and injected at runtime. No secret is present in source code, in configuration files or in version control history, which is verified by automated scanning of each change and of the repository history. Access to a secret is logged. Each secret carries a rotation date within its defined rotation interval and is rotated on suspected compromise. No secret is present in a system prompt, in a prompt template or in any other content placed in a model's context window, and those surfaces are in the scanned scope alongside source code, configuration and version control history.
Rationale
A secret committed to a public repository is found by automated scanners in minutes. Once it is in the history, rotating it is the only remedy. Scanning the history matters as much as scanning the change: removing a key from the current file leaves it in every clone. IAM-009 holds human authenticators, including password policy and hashing; this control holds the machine secrets and the code and pipeline surfaces they leak through. A prompt is a configuration surface a model reads, so anything in it is reachable by whoever can make the model talk, and no amount of instruction not to reveal it changes that. AIG-026 tests whether a prompt can be extracted; APP-008 states what may not be in it in the first place.
Applicability (9 profiles)
Framework Mappings (8)
| IAM-14 | Credentials Management | informative |
| IAM-14 | Credentials Management | informative |
| HIPAA-164.308.a.5.ii.D | Password Management | informative |
| 5.17 | Authentication information | informative |
| IA-5 | Authenticator Management | informative |
| IA-5(7) | Authenticator Management | No Embedded Unencrypted Static Authenticators | full |
| LLM08 | Hidden Context Exposure | 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. The scanned scope includes prompt templates and system prompt configuration.
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, confirmed via pipeline configuration. (4) the scanned paths include the prompt templates and the system prompt configuration the product ships, and a test credential planted in a prompt template is reported.
Questions (2)
Are all secrets held in an approved secrets management system rather than in source code, configuration files, version control or a prompt the model reads?
Answer for the secrets in production use. A prohibition on hardcoding that is stated in a policy but not enforced by scanning in the pipeline does not meet the control; Q2 captures which enforcement is in place. A system prompt counts: whatever the model can see, a user can eventually see.
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. Prompt templates are the surface most often left out of the scan, because they are treated as content rather than as configuration.