What’s New in ASVS 5.0

The first major release in six years of one of OWASP’s flagship projects, the Application Security Verification Standard (ASVS), is here. It has been described as a complete revamp compared to the previous version. Let's take a look at what changes and improvements it brings.

source: https://asvs.dev/

1. Introduction

ASVS is a set of security guidelines for web applications and services. In today’s world, where application security is more critical than ever, having a reliable and structured approach to secure development is essential. In other words, ASVS offers a comprehensive framework for verifying the security of web applications and services. Unlike the OWASP Top 10, which focuses on the most common risks, ASVS provides a complete, actionable standard across all phases of your application. With its refreshed version, it’s more than ever a solid foundation for teams aiming to build secure software by design.

In another blog post, I recently shared practical insights from applying this standard in a large, real-world project - Implementing OWASP ASVS v4.0.3. If you're new to ASVS, that article provides a brief introduction and some lessons learned from integrating it into an existing project.

The former ASVS version - v4.0.3 - was released in 2021. The time intervals between major versions of this project vary, but overall, the project has been alive for more than 15 years. And now, we are just welcoming v5.0.

ASVS release timeline

2. What’s new?

First of all, while ASVS was previously available mainly as a PDF, it now has a dedicated website - asvs.dev - where you can quickly browse both the current and earlier editions.

The most significant changes from the perspective of users of previous version v4 are described in the ASVS itself - Guidance for users of version 4.0. I will also present them here in a cumulative and comprehensive form:

Change in levels approach

I believe the most notable change in ASVS 5.0 is the updated approach to verification levels. In ASVS v4, the L1 level defined as “bare minimum” demanded exactly 131 controls - creating a steep entry point for adoption. On the other hand, L3 level (which includes L1 & L2) was defined with only 20 controls more than L2.

The high number of L1 controls was due to the possibility of covering them all with black-box security testing. While well-intentioned, this was considered by some as an unrealistic entry point, leading many teams to either avoid adopting ASVS altogether or attempt only partial implementation without ever reaching a full Level 1 status.

The idea in v5.0 was to lower the entry barrier without compromising security goals. ASVS v5 addresses this by rebalancing the levels, making level 1 easier to achieve. The intention is to make it easier for organizations to adopt the standard and gradually move toward level 2 and beyond.

Approximate comparison of level sizes

Complete renumbering and reordering

Requirements in ASVS v5.0 have been completely reorganized with numbering changes, deduplicated, and almost every single one has been reworded. To understand these changes you can follow a mapping document from v4.0.3 to v.5.0. You can find there what happened to specific requirements (are they moved, modified, merged, etc.).

To see the difference, let’s take a look at two example requirements defined in ASVS v.4.0.3. These controls had modified requirements and security levels, moved into different sections, and merged into one:

Difference between versions, source: ASVS v4.0.3 & v5.0

Less coupling with CWE & NIST

ASVS v5.0 removes direct mappings to MITRE’s Common Weakness Enumeration (CWE). While CWE remains a valuable classification for software weaknesses, some of the links between ASVS and CWE were ambiguous or imprecise, and there were cases where requirements didn’t map cleanly to a single CWE. Future mappings will be handled through OWASP's Common Requirement Enumeration (CRE) project, which offers more flexible cross-references to other OWASP materials.

ASVS v5 also reduces its dependency on external mappings like NIST's Digital Identity Guidelines. While it is still respected and officially maintained, the mappings live in a separate section outside the main requirement list.

3. Personal picks from the new version

The new features presented earlier are in the official documentation. Below are my personal findings and thoughts about the new version.

No controls related to “AI”

In 2025, any new application security standard might include at least some requirements related to broadly understood AI. But it is not covered here, and it is done on purpose - as per the ASVS creators - “It is worth a separate standard”.

That separate initiative is already underway - AISVS (Artificial Intelligence Security Verification Standard) - is an OWASP project focused specifically on security requirements for AI systems. It will aim to cover both classical machine learning pipelines and modern LLM-based architectures, offering structured guidance where ASVS intentionally leaves a gap. Currently, AISVS is in its early stages, and no official release date or timeline is available.

If you are more interested in OWASP and AI related topics, I recommend checking OWASP AI Exchange for a broader look at OWASP’s ecosystem of AI-related projects or OWASP Top 10 for Large Language Model Applications for high-level risks and mitigations for LLMs and generative AI applications.

Transparency with level 1 penetration testing

In former ASVS version v4.0.3, level 1 was positioned as the “bare minimum” and stated that it is optimized to be thoroughly checked by penetration testing. At the same time, it encouraged hybrid assessments and explicitly noted that black-box testing, while technically possible at Level 1, was “not an effective assurance activity”. In v5.0, that ambiguity is gone. The standard now clearly states that meaningful verification requires access to internal artifacts and that black-box testing alone is insufficient.

Level 3 requirements

ASVS v5.0 brings a considerable increase in the scope of level 3. In version 4.0.3, there were only about 20 extra level 3 requirements beyond level 2. Now, there are around 90 requirements. What’s notable (according to the mapping from v5.0 to v4.0.3) is that more than half of them are entirely new, not just lifted from level 2.

An example of this expansion is the completely new chapter: V10.4 OAuth Authorization Server, which introduces 16 new requirements spread across all levels, 5 of which are level 3. These controls address advanced OAuth-related topics, such as enforcing a fixed and client-specific response_mode or issuing sender-constrained access tokens using mutual TLS (mTLS) or Demonstration of Proof of Possession (DPoP).

There are also rare cases of a requirement level moving down, e.g:

• v4.0.3-9.2.5 L3: Verify that backend TLS connection failures are logged is downgraded to level 2 and modified with more generalized form into:
• v5.0-16.3.4 L2: Verify that the application logs unexpected errors and security control failures such as backend TLS failures.

Post-Quantum Cryptography

A notable addition is requirement 11.1.4 (level 3), reflecting the growing urgency of future-proofing cryptographic systems against the threat of quantum computing. It emphasizes having a plan for future migration - it’s a clear signal that while quantum threats aren’t immediate, proactive planning should start now.

A good example of such foresight is AWS’s post-quantum cryptography migration plan, which outlines their approach to identifying vulnerable assets, testing quantum-safe algorithms, and preparing for broader adoption in the future.

Reduced password length

Former ASVS requirement v4.0.3-2.1.1 recommends passwords with at least 12 characters. In the new version, control v5-6.2.1 (level 1) reduces the minimum password length to 8 characters, although at the same time strongly recommends at least 15 characters. The change was meant to align with the NIST SP 800-63B v4 authentication-related standard. I have observed that this change was the most discussed (GitHub issues, OWASP slack) among all.

Deleted requirements

What I appreciate, the new version deletes some requirements with explicitly stated reasons, which can be checked in as mentioned before mapping from v4.0.3 to v.5.0. While many were removed due to being merged or covered elsewhere, others were marked more explicitly, like DELETED, INCORRECT, NOT PRACTICAL, or INSUFFICIENT IMPACT. Below are a few examples deleted from the former version with context based on ASVS GitHub issues discussions:

• v4.0.3-2.4.2 (incorrect): Required salts to be at least 32 bits - Modern hashing algorithms like Argon2, bcrypt, and PBKDF2 already handle salting securely, making this obsolete (issue #994).
• v4.0.3-14.5.4 (incorrect): Required apps to authenticate HTTP headers from proxies or SSO devices - it doesn’t add anything more than existing requirements (issue #1529).
• v4.0.3-8.3.6 (not practical): Required zeroing sensitive data in memory after use - discussion consensus was to remove this requirement as it is not practically possible in most cases (issue #1225).
• v4.0.3-2.1.4 (insufficient impact): Encouraged allowing all printable Unicode characters in passwords - removed due to minimal impact, and in a world of MFA it doesn’t matter much (issue #2239).

Summary

In my opinion, the most critical change in ASVS v5.0 is the lowered barrier to entry at Level 1, which now focuses on fewer, more impactful, achievable, and meaningful controls. This change can encourage more teams to confidently aim for Level 1 without feeling overwhelmed - and progress toward Level 2 as a natural next step. The new version also brings a more consistent structure and more precise terminology. With its renewed focus on usability and realistic adoption, ASVS 5.0 is a solid update that makes secure development more approachable without compromising quality.

At SoftwareMill, we treat ASVS as one of the foundational standards for building secure software for our clients. If you're interested in building security into your development process, you might also enjoy our free eBook: Cybersecurity: developing a security-first mindset, for valuable insights on building secure applications.

Reviewed by: Krzysztof Ciesielski