OWASP ASVS: the Application Security Verification Standard, explained

The OWASP Application Security Verification Standard (ASVS) is an open, versioned list of application security requirements, built to be checked off one by one rather than read as general advice. The current release, ASVS 5.0.0, was published 30 May 2025 under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license and organises roughly 350 requirements across 17 chapters, per the project's own documentation. Unlike the OWASP Top 10's risk-awareness framing, ASVS exists to answer a narrower, more testable question for a specific application: for each individual requirement, does this build satisfy it or not?

What ASVS is for

OWASP describes three concrete uses for the standard: as a metric security architects and assessors can use to judge how trustworthy an application is; as guidance for developers and security-control vendors building the mechanisms an application needs; and as a basis for specifying application security requirements in development contracts. Every requirement in the document is written to be individually verifiable — producing a clear pass or fail — and is referenced with a stable identifier such as v5.0-V6.2.1, so a specific control can be cited precisely in a report, a ticket, or a contract clause rather than paraphrased.

The 17 chapters

ASVS 5.0.0's roughly 350 requirements are grouped into 17 numbered chapters (V1-V17), each covering one area of application security — for example encoding and sanitization, validation and business logic, authentication, session management, authorization, cryptography, secure communication, configuration, data protection, and WebRTC, among others. Chapters are organised so a team can select the ones relevant to their application's architecture rather than apply the entire document uniformly to every build.

Level 1, Level 2, Level 3: how the levels build on each other

ASVS's three verification levels are cumulative, not independent tracks — each level includes everything in the level below it, plus more:

Level	Share of total requirements	What it represents
Level 1	~20%	"The minimum requirements to consider when securing an application... a critical starting point," per the ASVS 5.0 documentation. Framed to be achievable even where an assessor lacks full code or documentation access.
Level 2	brings L1+L2 to ~70% of the total	The level most applications handling sensitive data should target, per the standard's own framing — "most applications should be striving to achieve this level."
Level 3	the remaining ~30%	The highest-assurance tier, generally defense-in-depth mechanisms and other controls described as useful but harder to implement, aimed at applications where the consequences of failure are most severe.

A device maker's companion mobile app or cloud management backend is a reasonable candidate for Level 1 or Level 2 verification; a backend handling safety-relevant commands or large volumes of personal data is a better candidate for Level 3.

No official certification — read vendor claims carefully

OWASP does not run or endorse an ASVS certification program. The project's own Assessment and Certification documentation is explicit: "any assurance, trust mark, or certification claiming ASVS compliance is not officially endorsed by OWASP," though organisations "may offer assurance services, provided they do not claim official OWASP certification." A vendor or auditor stating a product is "ASVS 5.0 Level 2 certified" is describing a self-declared or third-party assessment against the standard's requirements, not an OWASP-issued credential — worth confirming what assessment method was actually used before relying on the claim.

How ASVS fits next to the OWASP Top 10 and OWASP SAMM

These three OWASP projects answer different questions and are complementary rather than overlapping:

Project	Question it answers	Granularity
OWASP Top 10	What are the most critical categories of risk right now?	Awareness, 10 broad categories
ASVS	Does this specific application satisfy this specific, testable control?	~350 individually verifiable requirements
OWASP SAMM (see our guide)	How mature is the organisation's software-development process overall?	Organisational maturity, 5 business functions

A device or software maker can reasonably use the Top 10 to prioritise initial attention, ASVS to verify a specific application build against a concrete checklist, and SAMM to track whether the development process producing that application is improving over time.

Practical starting point

1. Pick a level deliberately, chapter by chapter if needed. A companion app's authentication chapter might warrant Level 2 while its less sensitive features stay at Level 1 — the standard's chapter structure supports mixed-depth adoption.
2. Cite requirement IDs, not summaries, in internal tickets and vendor contracts. The v5.0-Vx.y.z identifiers exist so a specific control can be unambiguously referenced and re-checked after a code change.
3. Verify any third-party "ASVS certified" claim against the actual assessment method used, since OWASP itself does not issue or endorse certifications.
4. Pair ASVS with CVE/KEV monitoring, not instead of it — passing a point-in-time verification does not substitute for ongoing vulnerability tracking once the application ships; see KEV and EPSS for vulnerability prioritization.

SoftWSP checks a device's companion applications and cloud backends against ASVS requirements alongside firmware-level analysis, so software and embedded risk are assessed together: see device firmware security.

This guide summarises a public OWASP project; it does not constitute legal or compliance advice.