OWASP ASVS 5.0: levels, requirements and implementation

OWASP ASVS 5.0 turns the vague requirement that an application “must be secure” into a structured set of verifiable controls. Teams can use it for architecture, implementation, procurement, penetration testing and ongoing assurance. Its greatest value is a shared language between business owners, developers, architects and testers.

The current stable OWASP Application Security Verification Standard release is 5.0.0. Requirements are organised into chapters and three verification levels. This guide explains how to select a level, create traceable requirements and collect evidence without turning the programme into a spreadsheet exercise.

ASVS versus OWASP Top 10

OWASP Top 10 raises awareness of broad web-application risk categories. ASVS is a detailed catalogue of verification requirements. Top 10 helps answer “which problem classes matter?” ASVS helps answer “which exact condition must hold, and what evidence proves it?”

Broken Access Control, for example, is a broad category. ASVS separates requirements for object access, privileged functions, ownership, administrative boundaries and behaviour after permission changes. A team cannot close the entire area with one successful login test.

ASVS is not a step-by-step testing methodology. Combine it with the OWASP Web Security Testing Guide, code review and business-specific abuse cases. The standard defines the target condition; the method and tester produce the evidence.

ASVS Level 1

Level 1 provides foundational application-security controls and a starting point for lower-risk applications. Some requirements can be assessed externally, but an automated scanner alone does not demonstrate L1 compliance. Access control and business logic still require meaningful manual tests.

L1 can be appropriate for public informational services, lower-impact applications and organisations beginning a formal AppSec programme. It should not be selected merely because the team has not planned how to achieve a higher level.

ASVS Level 2

Level 2 is the recommended target for most applications. It adds depth across data protection, identity, sessions, validation, cryptography, communication and other controls. The official OWASP Developer Guide describes Level 2 as recommended for most applications.

Typical candidates include SaaS products, e-commerce, customer portals and systems processing personal data. Achieving L2 normally requires architecture and configuration review in addition to code and dynamic testing.

ASVS Level 3

Level 3 is designed for high-value, high-impact or safety-critical applications. Examples may include financial systems, healthcare, critical infrastructure, privileged administration and services where compromise creates severe consequences.

It demands the strongest verification. Not every component must automatically receive the same profile. A payment or administrative module may target L3 while a public information section uses a different baseline, provided boundaries and dependencies are clearly documented.

How to select the right level

Choose based on risk rather than the budget left before launch. Assess:

• sensitivity and volume of data;
• financial and operational impact of compromise;
• authority the application holds in other systems;
• internet exposure and user population;
• legal, regulatory and contractual obligations;
• attractiveness to likely adversaries;
• irreversible operations and transaction values;
• role in a supply chain or critical service.

L2 is a practical default for many business applications, with selected L3 controls for critical flows. Mark a requirement not applicable only with a technical explanation. The absence of password recovery can justify excluding recovery-specific controls; lack of implementation time cannot.

Threat modelling identifies scenarios that need stronger controls than the baseline, especially across services and trust boundaries.

Version-qualified requirement identifiers

Every ASVS requirement has an identifier. A bare number such as 1.2.5 is insufficient for a long-lived programme because requirements can move or change between versions. OWASP recommends including the version, for example v5.0.0-1.2.5.

Record the following in backlogs, contracts and reports:

• full ASVS version;
• version-qualified requirement ID;
• selected level or application profile;
• status and reason for not-applicable decisions;
• control owner;
• verification method;
• evidence and its validity date.

This avoids a supplier claiming generic “ASVS compliance” against an unspecified release. When the standard changes, teams can perform a gap analysis instead of restarting without traceability.

ASVS in procurement and contracts

“The application shall comply with OWASP” is ambiguous. It does not name the project, release, level, scope or acceptance process. A useful clause specifies ASVS 5.0.0, the required profile, components, allowed exceptions, evidence and remediation process.

Define:

• who maps requirements to product functions;
• when not-applicable decisions are agreed;
• who performs independent verification;
• how nonconformities are prioritised;
• remediation and retest deadlines;
• report recipients and evidence handling;
• changes that trigger reassessment.

Evidence should match the control. An exported policy can support configuration requirements. Integration and dynamic tests support authorisation controls. Architecture and code review support cryptographic design. A screenshot of one successful login does not prove the entire authentication mechanism.

Implementing ASVS in the secure SDLC

Design

Architects map controls to components and data flows. Decisions about identity providers, tenant isolation, key management, trust boundaries and security logging belong here. The output should be an application-specific profile and recorded design decisions, not only copied requirement text.

Implementation

Developers turn requirements into acceptance criteria and tests. Shared security mechanisms—authorisation middleware, output encoding, secret handling and secure defaults—should be maintained as supported platform components. Code review examines paths that automated rules cannot understand.

CI/CD

SAST, DAST, dependency analysis, secret scanning and automated tests provide part of the evidence. Our SAST vs DAST vs IAST comparison explains why no single tool covers the standard. Pipeline gates should reflect risk and retain results linked to the exact artefact.

Pre-release verification

Testers execute manual scenarios, inspect architecture and confirm requirements that automation does not cover. A penetration test can map findings and coverage to ASVS, but the report must state which requirements were fully assessed, partially assessed or outside scope.

Operations

A new identity provider, cloud migration, API or business function can invalidate previous evidence. Every control needs an owner and reassessment trigger. Production monitoring supports operational controls, and incidents should create new regression cases.

Building an evidence matrix

Field	Purpose
ASVS ID	Full identifier including version
Component	Application, API, service or flow
Control design	How the system meets the requirement
Owner	Responsible person or team
Test method	Review, automated test, manual test or configuration
Evidence	Link to result, policy, code or report
Status	Met, not met, partial or not applicable
Validity	Artefact version and reassessment date

Maintain a central version of the standard rather than copying text into every project. Applications should store mappings, decisions and evidence. This makes upgrades and shared-control reviews more reliable.

Can a penetration test prove ASVS compliance?

A pentest can verify many requirements, but coverage depends on scope, access and time. A black-box assessment cannot fully prove internal cryptographic design, secret storage or build controls. A short production test does not provide evidence for the complete SDLC.

If ASVS verification is the objective, order it explicitly. Provide the version, level, architecture, roles and necessary artefacts. The report should show status, evidence and method limitations for each assessed requirement. “Tested according to OWASP” is not measurable coverage.

Conversely, passing listed requirements does not guarantee discovery of every vulnerability. Unusual business logic, integrations and novel attack chains may sit outside a literal checklist. Combine structured ASVS verification with exploratory penetration testing and risk analysis.

Common ASVS implementation mistakes

Selecting L3 for everything without analysis

An ambitious profile without owners and evidence becomes an abandoned spreadsheet. A credible L2 programme with risk-based L3 controls is better than an unsupported L3 declaration.

Treating a scanner as full verification

Automation detects some configurations and vulnerable patterns. It does not understand object ownership, acceptable transaction value or every workflow. Scanner results support selected requirements, not the entire standard.

Omitting the version from IDs

Numbers can change meaning between releases. Use v5.0.0-... consistently in backlogs, reports and contracts.

Marking controls complete without evidence

Every “met” status needs current evidence. A design document does not prove that production matches the design, and an owner’s assurance does not replace a test.

Introducing ASVS just before launch

An architectural control discovered a week before release may require major rework. Build the profile during design and carry it through implementation and operations.

Is there an official OWASP ASVS certificate?

OWASP publishes an open standard; that does not automatically make every third-party assessment an official OWASP certification. Treat marketing claims such as “OWASP certified” carefully. A useful verification statement identifies the assessor, version, level, scope, method, limitations and date.

The evidence trail matters more than a logo: what was tested, with which access, which issues were found, what was fixed and whether remediation was retested.

ASVS 5.0 implementation checklist

1. Identify components, data and critical flows.
2. Select ASVS 5.0.0 and a risk-based baseline level.
3. Raise controls for higher-impact modules.
4. Agree and justify not-applicable requirements.
5. Assign an owner and verification method to every control.
6. Convert requirements into acceptance criteria and tests.
7. Automate evidence where the result is reliable.
8. Plan manual verification and business-logic testing.
9. Report version-qualified IDs and method limitations.
10. Retest fixes and retain regression cases.
11. Define events that invalidate prior evidence.
12. Perform a gap analysis when ASVS is updated.

OWASP ASVS 5.0 turns security promises into a measurable process. The essentials are a suitable level, traceable requirements, credible evidence and regular reassessment. To create a product profile or commission an independent verification, contact Breachroad.