ASVS 4.0.3 vs 5.0: What Changed and What Developers Need to Know

The OWASP Application Security Verification Standard moved from 4.0.3 to 5.0 on 30 May 2025. For a team running a mature ASVS 4.0.3 verification program, the migration is tractable but non-trivial — chapter structure was reorganized, requirement IDs were renumbered, three new standalone chapters were spun out, and the working group did a pruning pass on requirements judged to be redundant or untestable. This post walks the changes that actually matter for developers — the full 5.0 table of contents, the chapter-level diff against 4.0.3, the requirements that were removed or renumbered, and the practical migration steps that get an existing ASVS program to 5.0 without losing evidence continuity. For broader context on what ASVS is and how to run a verification program, the complete ASVS developer guide covers the foundations; this post assumes you know the basics and want the version diff.

ASVS Version Lineage Recap

ASVS first appeared in 2009 as a security requirements list maintained by an OWASP project led by Mike Boberski, Daniel Cuthbert, and others. Version 2.0 (2014) added a level system. Version 3.0 (2015) introduced the modern three-level structure (L1 / L2 / L3) and consolidated the requirements list into a form recognizable to anyone using the standard today. Version 4.0 (March 2019) was the largest restructure to that point, reorganizing chapters along the lines that 5.0 has now further evolved, and version 4.0.3 (October 2021) was a maintenance release that resolved ambiguities and added cross-references.

The 4.x line dominated industry practice for six years. Most procurement security questionnaires written between 2019 and 2024 explicitly reference 4.0 or 4.0.3, and many of the secondary artifacts produced by vendors — ASVS-aligned SAST rule packs, training catalogs, attestation templates — solidified around the 4.x structure. This installed base is the practical reason the migration to 5.0 takes effort: not because the 5.0 requirements are dramatically different, but because the surrounding ecosystem of references, tooling, and documentation needs an update pass.

Version 5.0 was released on 30 May 2025 at Global AppSec EU Barcelona, after a release-candidate cycle that began with RC1 on 31 March 2025 and a development period that ran for roughly three years. The 5.0 working group was substantially larger than any previous version's, with contributor participation reflecting the broader maturation of the application security community. The release notes published with 5.0 explicitly frame the version as a structural cleanup pass rather than a fundamental reimagining of the standard — the verification philosophy is the same; the organization is sharper.

ASVS 5.0.0 Table of Contents — Security Requirements by Chapter

The ASVS 5.0.0 table of contents security requirements are organized into 14 chapters, each addressing a domain of application security with individually-verifiable requirements at three levels (L1, L2, L3). The OWASP ASVS latest version — 5.0.0 since the 30 May 2025 release — is the canonical reference for new programs and the migration target for established 4.0.3 programs. The full table of contents and the high-level scope of each chapter:

This is the 14-chapter structure of ASVS 5.0 as released. Chapters V3 (Web Frontend Security), V9 (Self-Contained Tokens), and V10 (OAuth and OIDC) are new standalone chapters in 5.0 — material that had been sub-sections of larger chapters in 4.0.3 was elevated to chapter status, reflecting how dominant these areas have become in modern application architecture.

Chapter-by-Chapter Changes — 4.0.3 to 5.0

The mapping from 4.0.3 chapters to 5.0 chapters is mostly intuitive but contains several reorganizations that catch teams off guard during migration. The high-level diff:

The single most significant structural change is the split of 4.0.3's V5 (Validation, Sanitization and Encoding) into two distinct 5.0 chapters — V1 Encoding and Sanitization, and V2 Validation and Business Logic. The 4.0.3 chapter conflated two related but separate disciplines: defense at trust boundaries (encoding and sanitization) and defense as business-rule enforcement (validation and business logic). The 5.0 split makes the verification effort easier because the two disciplines have different evidence patterns — encoding is typically verified by SAST or DAST against a known sink list; business logic is typically verified by manual code review and test cases.

The second-most-significant change is the spin-out of OAuth and OIDC into V10 as a standalone chapter. In 4.0.3, OAuth and OIDC requirements lived as a sub-section of V2 Authentication and were treated essentially as a credential-flow appendix. In 5.0, the chapter is full-size with requirements covering grant type selection, redirect URI validation, state and nonce handling, token storage, and integration patterns. This is the chapter where 5.0 adds the most net new requirement language; teams whose 4.0.3 evidence for OAuth flows was thin will find V10 expects substantially deeper verification.

What Was Removed in 5.0

The 5.0 working group did a deliberate pruning pass on 4.0.3 requirements that had become redundant, ambiguous, untestable, or addressed transient threats no longer in the landscape. Removed requirements are explicitly listed in the release notes with the working group's reasoning, but the categories of removal are worth knowing:

Requirements made redundant by stricter platform defaults. Some 4.0.3 requirements existed because the popular frameworks of 2019 had insecure defaults — early Express.js cookie handling, older Django session middleware, pre-3.0 Spring Security defaults. The frameworks fixed the defaults; the requirements were preserved out of caution but were verifying configuration that almost no application got wrong anymore. 5.0 removed several of these where the working group judged the underlying platform behavior to have stabilized.

Requirements judged to address transient threats. A handful of 4.0.3 requirements addressed specific attack patterns that were prominent in 2017-2019 but have since been largely supplanted by other concerns or addressed at the protocol level. The cleanup pass removed these where the working group judged the requirement to be tracking a specific exploit class rather than a durable defensive principle.

Requirements that were untestable in practice. Some 4.0.3 requirements were aspirational rather than verifiable — they described a security property that an auditor could agree was desirable but could not establish whether the application met. The working group removed several of these where the property could not be operationalized into evidence collection.

Requirements consolidated with adjacent requirements. The largest source of removed IDs is not requirements disappearing entirely, but two or three requirements that were redundantly verifying the same property being merged into a single, clearer requirement. The verification surface is preserved; the ID count decreases.

The practical implication for migration is that an evidenced 4.0.3 program will find some of its evidenced requirements simply do not appear in 5.0. This is not a verification gap — the underlying property is still verified, either by an adjacent requirement or by a structural change in the chapter — but the mapping between 4.0.3 IDs and 5.0 IDs is not always 1:1. The official OWASP repository hosts the mapping in JSON form, and a migration script that takes a 4.0.3 evidence inventory and produces a 5.0-aligned version is a few hundred lines of work.

Migration Practical Guide

For a team with an active 4.0.3 verification program, the migration sequence that works in practice is the following.

Step 1 — Inventory current evidence. Produce a document that lists every 4.0.3 requirement the program currently has evidence for, the type of evidence (configuration, SAST report, DAST run, code review record, attestation), the artifact path, and the date of last verification. This is the artifact you will migrate; doing the inventory before touching the standard prevents the common failure mode of partial migration where some chapters are updated and others are left in 4.0.3 IDs indefinitely.

Step 2 — Apply the 4.0.3-to-5.0 mapping. Use the official OWASP-published mapping document to translate each 4.0.3 requirement ID in your inventory to its 5.0 equivalent. Requirements that map cleanly get a direct ID swap. Requirements that map to multiple 5.0 IDs (because one 4.0.3 requirement covered ground now split across two 5.0 requirements) get duplicated in the inventory and tagged for re-verification. Requirements that were removed get marked as obsolete in the inventory with a reference to the 5.0 release note explaining the removal.

Step 3 — Identify net new requirements. The new standalone chapters (V3 Web Frontend Security, V9 Self-Contained Tokens, V10 OAuth and OIDC) add requirement language that did not exist in 4.0.3. Walk these three chapters specifically and produce a gap list — requirements that need evidence but have none yet. This is the verification work the migration adds; for most teams the gap list is 30-60 requirements depending on the application's surface area.

Step 4 — Refactor automation. Any CI/CD scripts, SAST rule packs, or DAST configurations that reference 4.0.3 requirement IDs in their output need to be updated. The pattern that works is to add 5.0 IDs alongside 4.0.3 IDs in tool output for one transition cycle, then remove the 4.0.3 references in the following cycle once downstream consumers have been migrated.

Step 5 — Update evidence collection schema. If you maintain a structured evidence document per release (recommended), update its schema to reference 5.0 requirement IDs. The schema change is small in code but high in downstream impact, since any consumer of the evidence document — auditors, internal dashboards, attestation generators — needs to understand the new ID format.

The full migration for a single application typically takes a quarter of focused work for a small security team, longer for organizations with multiple applications and shared automation. The work is largely mechanical once the mapping document is in hand; the manual judgment is concentrated in the gap-list step (Step 3) where the new chapters require fresh verification effort.

OWASP ASVS Checklist and Official Resources

An owasp asvs checklist is the operational artifact most verification programs produce — a spreadsheet or tracking document listing every requirement at the chosen level (L1, L2, or L3) with verification status, evidence reference, and last-verified date for each. The OWASP project itself does not publish a single canonical checklist; instead, the standard's machine-readable JSON release acts as the source of truth from which teams generate their own checklists tuned to their tooling and process. A pragmatic team produces the checklist as an output of their evidence-collection schema, so the checklist updates automatically as evidence is collected rather than drifting from a manually-maintained spreadsheet.

The official artifacts worth bookmarking. The owasp asvs pdf is the human-readable form of the standard, available in English plus translated editions on the OWASP ASVS GitHub repository. The CSV and JSON forms are machine-readable; the JSON is the format tooling typically consumes for ASVS-tagged SAST rule output, evidence-collection schemas, and cross-reference mappings to CWE and other standards. The owasp application security verification standard asvs 4.0.3 archive also remains available for teams managing the migration window where some workloads are still on the older edition — the GitHub repository preserves all historical releases including the owasp application security verification standard 4.0.3 official PDF, CSV, and JSON.

Teams running an ASVS verification program should download the latest 5.0.0 release alongside the 4.0.3 archive (for migration reference), the official mapping document between the two, and the JSON release for any tooling integration. The PDF is the readable reference; the machine-readable formats are what production tooling consumes.

Tooling Supporting ASVS 5.0

The tooling ecosystem around ASVS 5.0 was thin at release in May 2025 and has been catching up through the second half of the year. As of mid-2026, the landscape is:

SAST rule packs. Most commercial SAST vendors with ASVS-aligned rule packs released 5.0-tagged versions within six months of the standard's release. Open-source SAST rule packs (Semgrep registry, CodeQL community queries) have been steadily expanding 5.0 coverage; coverage is typically more complete for the chapters that didn't reorganize (V11, V12, V14) than for the reorganized chapters (V1+V2 split, V6+V9 split).

DAST and IAST tools. Tagging dynamic findings against ASVS 5.0 requirement IDs is slower to roll out than SAST tagging because dynamic findings are inherently fuzzier in their requirement mapping. Several commercial vendors have ASVS 5.0 reporting overlays available; open-source DAST tools (OWASP ZAP, Nikto) are still primarily 4.0.3-tagged.

Compliance and evidence tooling. Compliance-evidence platforms that ingest scan results and produce verification reports are mostly 5.0-aware by mid-2026, though some still default to 4.0.3 reporting for backward compatibility with customer expectations.

Training catalogs. Developer security training programs aligned to ASVS have substantially migrated to 5.0 chapter structure. The SecureCodingHub challenge catalog is mapped to 5.0 chapters and requirements, with each interactive code review challenge tagged to the ASVS requirement IDs it verifies — at all three levels (L1, L2, L3).

Official OWASP artifacts. The OWASP project page hosts 5.0 in PDF, CSV, JSON, and YAML formats. The JSON format is the most useful for any tooling integration because it includes the requirement language, the level applicability, the CWE mappings, and the cross-references to other standards (NIST 800-63, ISO 27001 Annex A) in machine-readable form.

Should You Migrate Now or Wait?

The pragmatic answer for most teams is: migrate now. The reasoning has three parts.

First, the migration cost does not decrease with time. The mapping document, the official artifacts, and the tooling ecosystem are now stable; the work is largely mechanical and gets no easier by being postponed. Teams that wait six months will do the same work then.

Second, the installed base is shifting. Procurement security questionnaires written in 2026 are starting to reference 5.0 explicitly. Compliance auditors are increasingly trained on 5.0 and expect 5.0-aligned evidence. Vendors and customers expect ASVS-attesting partners to be on the current version.

Third, the new chapters (V3, V9, V10) address real gaps in the application security posture of most modern applications. A team that skips 5.0 misses the opportunity to formalize verification of OAuth flows, JWT handling, and browser-side hardening — three areas where most applications have weaker evidence than they should. Migrating to 5.0 forces the gap analysis these chapters surface.

The single legitimate reason to defer migration is if the team's current 4.0.3 evidence collection is itself shallow or inconsistent. In that case, the right work is to stabilize the 4.0.3 program first, then migrate, rather than attempting both a quality improvement and a version migration simultaneously. Programs that try to do both at once consistently produce evidence that is neither solid 4.0.3 nor coherent 5.0.