ASVS 5.0 V13.3.2 requires that access to secret assets follows least privilege: a service or person gets the secrets they need to do their job and nothing more. It is Level 2.
A vault with one broad read policy has changed where the secrets are stored without reducing who can steal them.
Why it matters
If every service can read every secret, the weakest service becomes the way into all of them. A compromised web frontend should not be able to read the payment signing key.
How to implement it
Scope policies by path and by identity, and grant read only unless a service must write.
HashiCorp Vault policy for one service:
path "secret/data/prod/orders/*" {
capabilities = ["read"]
}
Bind it to that service's identity only. For humans, require individual authentication, short sessions and approval for production secret access, and remove access when people change roles.
How to test it
- Authenticate as service A and try to read service B's secret path. It must return permission denied.
- Export and review policies and grants quarterly, looking for wildcards and unused access.
- Check audit logs for reads by identities that should not need the secret.
Common mistakes
- A single "app" policy with read on the whole mount.
- Shared team accounts for the vault.
- Leaving access for former employees and retired services.
Quick check
Is read access to the whole secret mount acceptable for a single service?
Usually not. Scope it to the paths that service actually uses.
