ASVS 5.0 V13.1.4 requires application documentation that names the secrets critical to security and sets a rotation schedule for them, based on your threat model and business needs. It is a Level 3 requirement.
The point is that rotation is a decision with an owner and a date, not a hope. V13.3.4 then asks you to configure secrets to expire and rotate according to this document.
Why it matters
Secrets leak through logs, backups, laptops and departing staff. A secret that never changes stays exploitable forever once leaked. An inventory also tells you what to rotate first when something does leak.
How to implement it
Create a register with one row per secret. Never put the secret value in it.
- name: orders-db password
type: database credential
location: vault path prod/orders/db
consumers: orders-api
owner: orders-team
rotation: every 30 days, automatic
on_compromise: rotate within 1 hour, runbook RB-14
- name: JWT signing key
type: asymmetric key
location: KMS key jwt-signing
rotation: every 90 days with overlap of 7 days
Base intervals on impact: higher for broad access and hard to revoke secrets, lower for per service short lived ones. Include API keys for third parties, signing keys, encryption keys, TOTP seeds and CI tokens.
How to test it
Pick three secrets at random and confirm that (1) they are in the register, (2) the stored rotation date matches the real last rotation in your secret store and (3) the owner can state the compromise procedure.
Common mistakes
- A register that lists secret values or file paths with the values inside.
- No overlap period, so rotation causes an outage and the team stops doing it.
- Skipping CI and build secrets.
Quick check
Should the document contain the secret values?
No. It lists names, owners, locations and schedules only.
