ASVS 5.0 V13.3.4 requires secrets to be configured to expire and be rotated according to the schedule in your application documentation (V13.1.4). It is a Level 3 requirement. A policy on paper is not enough: the system itself must enforce the dates.
Why it matters
Every secret eventually leaks somewhere you cannot see. Rotation puts a ceiling on how long a stolen secret works. Expiry forces teams to prove they can rotate before there is an emergency, so the emergency procedure has already been exercised.
How to implement it
- Prefer dynamic secrets that the vault creates with a short TTL and revokes itself.
- For static secrets, configure automatic rotation in the secret store.
- Support two valid values during rotation so consumers can switch without downtime.
- Make applications re-read secrets without a restart, or restart them in a controlled rollout.
AWS Secrets Manager rotation, via CLI:
aws secretsmanager rotate-secret \
--secret-id prod/orders/db \
--rotation-lambda-arn arn:aws:lambda:us-east-1:111122223333:function:rotate-orders-db \
--rotation-rules AutomaticallyAfterDays=30
HashiCorp Vault dynamic database credentials, with a short lease:
vault write database/roles/orders-api \
db_name=orders \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT, INSERT ON orders.orders TO \"{{name}}\";" \
default_ttl=1h max_ttl=24h
Signing keys need an overlap: publish the new public key, sign with it, and retire the old one after the longest token lifetime has passed.
How to test it
- Force a rotation in staging and confirm the application keeps working with no errors.
- Confirm the old value stops working after the overlap window.
- List secrets and flag any whose last rotation is older than the documented interval.
- Check that expiry alerts fire before a secret lapses.
Click through it at your own pace, or open it full screen.
Common mistakes
- Rotation that works in the vault but whose consumers cache the old value for days.
- No overlap, so rotation causes an outage and gets postponed.
- Skipping third party API keys because the provider has no rotation feature. Track them manually, with an owner and date.
- Alerting on expiry but not on failed rotation jobs.
Try it yourself
Choose one static secret that matters, such as a database password or a third party API key. Write its owner, interval and compromise procedure into your secrets register. Configure rotation in the store, run it once in staging during working hours and watch the consumers.
Common surprises show up on the first run: a service that reads the secret only at boot, a batch job that holds an old password, a monitoring tool with a copy. Fix each one and rerun. When a rotation completes with no manual steps and no errors, move the same pattern to the next secret.
Schedule a drill each quarter where you rotate one critical secret as if it had leaked, and time it.
Quick check
Where does the rotation interval come from?
From your application documentation under V13.1.4, based on your threat model. V13.3.4 checks that the system enforces it.
