Loading the standard…
The Application Security Verification Standard is a list of security requirements that architects, developers, testers and procurement teams use to define, build, test and verify secure applications. Version 5.0.0 has 345 requirements across 17 chapters.
Its scope is set by its own name:
ASVS contains only requirements ("must"), never recommendations ("should").
Levels are cumulative: L2 means all L1 + all L2 items. They are assigned by weighing risk reduction against implementation effort, not by how easy something is to pen-test.
70 requirements (~20%). First-layer defenses against common attacks that need no other vulnerability or precondition to exploit. Deliberately small to lower the barrier to adoption.
e.g. an early-stage startup handling limited sensitive data.
183 requirements (~50%); reaching L2 means implementing ~70% of the whole standard. Covers less common attacks, or more complex protections against common ones. Multi-factor authentication becomes mandatory at this level.
92 requirements (~30%). Defense-in-depth mechanisms and useful but hard-to-implement controls, such as hardware-based authentication.
e.g. online banking, healthcare, or anything where users expect the highest assurance.
Which level? ASVS does not dictate one. Analyse your own risk, data sensitivity and user expectations, then pick the level you should be at. You may also pull individual higher-level requirements forward if your threat model calls for it.
Unlike a traditional pen-test report that lists only failures, an ASVS report should state the scope, the level attempted, a summary of all requirements checked, the exceptions found, and the rationale for anything excluded. Export to Markdown or CSV to build that report.
Those two are one-way report formats. Export JSON is the one that can be imported again, so use it to back up an assessment or move it to another browser.
OWASP certifies no vendor or software. Be wary of third-party claims of "ASVS certification."
Some requirements ask you to document a security decision (they sit in the first section of a chapter). Verifying that the documentation exists and verifying that the implementation matches it are two separate activities.
IDs are <chapter>.<section>.<requirement>. Because they change between
major versions, cite them with the version prefix: v5.0.0-1.2.5.
Loading the standard…