ASVS verification

Do this

1. Choose the level from the risk

   Level 1 holds about 20% of the requirements, the first layer of defense. Level 2 brings the total to about 70% and is where most applications should aim. Level 3 adds the rest, for applications that must show the highest assurance. ASVS suggests a startup with little sensitive data may start at level 1, while a bank may struggle to justify anything less than level 3.

2. Scope the chapters and the build

   Drop chapters the application does not use, such as V10 OAuth and OIDC or V17 WebRTC, with a reason for each. Name exactly what you verify: the service, the release and its artifact digest, the environment and the interfaces. ASVS asks verifiers to describe scope by what was included, not by what was left out. Requirements usually come from Security requirements.

3. Cite every requirement with its version

   Write IDs with the edition, such as v5.0.0-1.2.5, as the OWASP project recommends, because numbering changes between versions. ASVS 5.0.0 has 345 requirements in 17 chapters. Export the list for your level and chapters from ASVS 5.0 checklist export and use it as the record's skeleton.

4. Pick a check for each requirement

   Decide how each requirement is shown: an automated test, a code or configuration review, or a manual test. Prefer tests that run in CI (Automated security tests) so the result repeats on every build. OWASP says running an off-the-shelf tool is not enough: many requirements need access to source code, configuration and documentation.

5. Record evidence another engineer can repeat

   For each requirement, record the test or review ID, the artifact and environment, the input, the expected and observed behavior, where the evidence is stored, who checked it and when. Keep failing observations alongside the retest. A screenshot that cannot be tied to the artifact counts as missing evidence.

6. Report each result honestly

   Use four results: pass, fail, not tested and not applicable. One passing code path does not outweigh a failing one in scope, and an approved risk exception does not turn a fail into a pass. File every fail as a bug with an owner and a due date, then retest it.

7. Recheck when the code changes

   Write down what would reopen each result, such as a new subprocess call or a changed login flow, and rerun the affected checks before the next release. Keep the record with the release, so the next verification starts from it rather than from scratch.

Common mistakes

• Claiming "ASVS compliant" or a level from a handful of passing requirements. A few requirements are not a level, and OWASP does not certify any vendors, verifiers or software.
• Citing requirements without a version. V14.2.1 means keeping components up to date in ASVS 4.0.3 and keeping sensitive data out of URLs in 5.0.0.
• Marking a requirement not applicable because nobody tested it. Not applicable needs a reason in the product; a missing test is "not tested".
• Treating a scanner run as verification. ASVS says tools cannot fully verify many of its more complex requirements, so authorization and business rules still need review and manual tests.
• Verifying a different build from the one you ship. The evidence must name the artifact digest that is actually deployed, or it describes another program.

Pass, fail, not tested or not applicable?

Keep the four results apart. Counting "not tested" as a pass, or an accepted risk as a pass, hides exactly the gaps a verification exists to find.

Tools and guides

• Tool: ASVS 5.0 checklist export
• Workflow: Test an application
• ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat

  Scope edition-qualified requirements, connect them to implementation and tests, and separate a passing check from an unsupported assurance claim.

• Write testable security requirements and a security Definition of Done

  Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done.

Standards

NIST SSDF 1.1

PW.7 Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security RequirementsPW.8 Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements

OWASP SAMM 2

Requirements-driven Testing

Sources

1. OWASP Application Security Verification Standard
2. OWASP ASVS 5.0.0 release. 30 May 2025.
3. OWASP ASVS 5.0.0: What is the ASVS? (levels and scope). Version 5.0.0.
4. OWASP ASVS 5.0.0: Assessment and Certification. Version 5.0.0.
5. OWASP SAMM: Requirements-driven Testing, Control Verification stream
6. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.