ASVS 5.0 V13.2.3 requires that when a credential is used for service authentication, the consumer does not use a default one such as root/root or admin/admin. It is a Level 2 requirement.
Default credentials are published in vendor manuals and in every attacker's wordlist. They are tried first.
Why it matters
Databases, message brokers, dashboards and admin consoles ship with well known accounts. Internet scans find exposed ones within hours of deployment. Inside a network the same accounts let an intruder move laterally without any exploit.
How to implement it
- Change or disable every vendor default at install time, in code, not by hand.
- Generate a random unique secret per environment and inject it from a secret store.
- Fail the deployment if a known default is detected.
A Docker Compose file that refuses to start without a supplied secret:
services:
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: ${DB_PASSWORD:?DB_PASSWORD must be set}
The :? form aborts when the variable is empty. Do not give it a fallback such as changeme.
How to test it
Search for common defaults in repos, Helm values, Compose files and images:
grep -rniE "(password|passwd|secret)\s*[:=]\s*[\"']?(admin|root|password|changeme|test|guest)[\"']?" .
Then try the vendor default account against each running service in a test environment. Secret scanning in CI catches many of these before merge.
Click through it at your own pace, or open it full screen.
Common mistakes
- Defaults left in dev and staging that share a network with production.
- The same "strong" password reused across every environment.
- Disabling the default account in the UI but leaving it in the bootstrap script.
Quick check
Is a generated password that is identical in all environments fine?
No. Each environment should have its own unique secret, so a leak in one does not open the others.
