TL;DR: benchmarking your AppSec program against OWASP ASVS
OWASP ASVS is a yardstick, not a certificate. Its value depends on what you measure with it, and on the evidence you can show when someone asks which level your application meets.
- There is no official OWASP ASVS certification. A level claim is only as strong as the verification behind it, which is why buyers and auditors increasingly ask how it was verified.
- Organizations use it in four main ways: as a secure development baseline, a pentest scope, a procurement requirement and a gap-driven roadmap.
- Adoption breaks on scope and ownership, not on security knowledge. Many requirements turn out to be not applicable, or owned by another team.
- Version matters. ASVS 5.0 reshuffled the levels in 2025, so every claim and every contract should pin the version, for example
v5.0.0. - Automate what you can, verify the rest. Scanner findings mapped to OWASP ASVS requirement IDs keep part of the benchmark current; design reviews and testing cover the rest.
Almost every AppSec team has heard of the OWASP Application Security Verification Standard, better known as OWASP ASVS. Far fewer can say which level their applications actually meet, or prove it to an auditor or a customer. That gap is where OWASP ASVS earns its value, or loses it.
This post doesn’t summarize the standard, because the standard does that well. It looks at how organizations actually use OWASP ASVS, where adoption creates friction, how the standard has matured in 18 years, and how to benchmark your own program against it.
What OWASP ASVS is, in one paragraph
Launched in 2008, OWASP ASVS is a catalogue of security requirements for web applications and APIs, each written so it can be verified objectively. Requirements are grouped into three cumulative levels, so the effort scales with an application’s risk. Unlike organization-level frameworks such as ISO 27001, OWASP ASVS works at the level of concrete requirements that developers, testers and buyers can all use. The current version, ASVS 5.0, was released live at Global AppSec EU in Barcelona in May 2025.
18 years on the maturity ladder
OWASP ASVS has changed a lot since 2008. Version 4.0 (2019) restructured the standard around the tiered level model, and 4.0.3 (2021) became the version procurement teams quoted for years. ASVS 5.0 modernized it: about 350 requirements across 17 chapters, a streamlined Level 1 designed to lower the barrier to entry, new chapters on web frontend security and self-contained tokens, and a dedicated website.
The pattern across those 18 years is clear: the standard matured faster than its adoption. Many organizations still reference 4.x requirements in contracts and audits, while the requirements themselves have moved on.
Who uses OWASP ASVS, and for what?
Five real uses, what each one delivers, and where it tends to break.
| Use | Who uses it | What it delivers | Where it breaks |
|---|---|---|---|
| Secure development baseline | Developers and architects | A concrete definition of "secure enough", usable as acceptance criteria | Hundreds of requirements, many not applicable or owned by another team |
| Pentest and audit scope | Testers and auditors | Reports that map findings to requirement IDs and show coverage, not just a list of bugs | Results can't be compared unless the scope pins both the level and the version |
| Procurement and contracts | Buyers and vendor risk teams | A clear bar in RFPs and contracts: "the delivered system shall meet ASVS Level 2" | No official certification, so the buyer has to define the evidence it will accept |
| GRC and compliance evidence | Compliance teams | Mappings to frameworks such as ISO 27001 and PCI DSS for audit preparation | Often stays a technical standard that GRC tooling doesn't track |
| Gap analysis and roadmap | AppSec leaders | A level-based gap list that can be closed in phases | Goes stale fast unless it is re-verified as the code and the standard change |
Where it’s adoption creates friction
The most useful accounts of OWASP ASVS adoption come from teams that went through it. One detailed example is SoftwareMill’s report on implementing ASVS Level 2 in an existing system, a mature microservices platform on Kubernetes. Four lessons stand out, and they match what we see across the industry.
There’s no certificate at the end. OWASP doesn’t certify ASVS levels. In that project, verification combined penetration testing with an internal audit based on a self-assessment sheet, repeated every year. Any “OWASP ASVS Level 2” claim is a statement about a verification process, and buyers are learning to ask about the process.
Scope takes more work than security. Of the 267 Level 2 requirements the team reviewed, more than half were already met and 80 were not applicable. Some requirements didn’t belong to the team at all: identity was managed by another internal team, which had to pass its own ASVS check. An ASVS level belongs to a system, and systems cross team boundaries.
Versions drift. Between 4.0.3 and 5.0, some requirements moved between levels. One JSON validation requirement the team had flagged moved from Level 1 to Level 3 in the new version. A benchmark that doesn’t pin its version measures against a moving target.
The GRC question is still open. OWASP ASVS was designed to work in contracts: the buyer sets a required level and the seller proves the software meets it. In practice, many organizations still use OWASP ASVS mainly as an engineering and testing tool. Compliance teams map it to broader frameworks, but the link between a requirement ID and the evidence that proves it is often manual, which makes continuous reporting hard.
How to benchmark your AppSec program against OWASP ASVS
A practical benchmark doesn’t start with requirement 1.1.1. It starts with decisions about scope.
- Tier your applications and assign a target level. Level 1 as the baseline for everything, Level 2 for applications that handle sensitive data, Level 3 only for critical systems.
- Pin the version. Benchmark against v5.0.0 and cite requirement IDs with it, so results stay comparable over time.
- Scope before you score. Mark requirements as not applicable with a written reason, and name an owner for every requirement that crosses team boundaries.
- Automate the verifiable layer. Map scanner findings (code, infrastructure as code, pipelines) to OWASP ASVS requirement IDs, so part of the benchmark updates with every scan instead of once a year.
- Verify the rest by hand. Architecture, business logic, and process requirements need design reviews, threat modeling, and testing.
- Turn gaps into a phased roadmap. Close Level 1 gaps across the whole portfolio before pushing individual applications to Level 2.
- Re-verify on a schedule and after major changes. Annual verification is a common minimum. Continuous evidence from your tools makes the annual review much shorter.
Beyond the application: ASVS and SPVS
OWASP ASVS covers the application. It doesn’t cover the pipeline that builds and ships it, and that’s where many of the most damaging supply chain attacks now land. That gap is what the OWASP Secure Pipeline Verification Standard (SPVS) addresses: a maturity-based set of controls across Plan, Develop, Integrate, Release, and Operate, which reached version 1.0 in October 2025.
The two standards work as a pair: ASVS for what you build, SPVS for how you build it.
How Xygeni maps findings to OWASP ASVS
OWASP ASVS is one of the standards Xygeni focuses on most, alongside SPVS. Xygeni’s SAST, IaC and CI/CD detectors are tagged with the ASVS requirement each one maps to. That changes what a finding means: it’s no longer just “an issue in this file”, it’s evidence for or against a specific requirement in your benchmark.
Those findings flow into Xygeni ASPM, where they’re prioritized together with findings from the rest of your stack. Pipeline findings from Xygeni CI/CD Security and IaC checks extend the same logic beyond the code. Knowing which requirements your tooling already evidences lets you focus manual review on the ones that really need a human.
See your findings mapped to OWASP ASVS requirements
A benchmark that updates once a year describes last year’s application. Book a demo to see Xygeni map SAST, IaC, and CI/CD findings to OWASP ASVS requirements, or start free and scan your first repositories today.
FAQ
Is there an official OWASP ASVS certification?
No. OWASP doesn’t certify ASVS levels. Organizations verify them through penetration testing, audits, and self-assessment, so the evidence behind a level claim matters as much as the claim.
What changed in ASVS 5.0?
Version 5.0, released in May 2025, has about 350 requirements in 17 chapters, a streamlined Level 1, new chapters such as web frontend security, and updated guidance on cryptography and authentication.
Which OWASP ASVS level should my application target?
Level 1 is the baseline for any application, Level 2 suits most business applications that handle sensitive data, and Level 3 is for critical systems where a breach would have severe consequences.
What’s the difference between OWASP ASVS and SPVS?
OWASP ASVS defines security requirements for the application itself. SPVS defines verifiable controls for the pipeline that builds, tests and delivers it.
