AI
Why ASVS V5 Rewrote the Levels
The V5 working group rebalanced levels to make Level 1 more approachable. V4’s Level 1 carried roughly 130 requirements, which intimidated teams. V5 trimmed that number and stopped labeling Level 1 as the “pentestable level” because black-box testing alone misses source-code-level issues. Requirements now span all levels based on verifiability from code. The goal: get teams started without feeling overwhelmed, then progress to Levels 2 and 3.
Tighter Scope: Code Properties Over Process
ASVS V5 dropped the entire architecture chapter (V1). The working group tightened scope to properties you can verify by looking at code: ssdlc considerations, threat modeling, and process maturity moved to other OWASP projects like SAM. Every requirement now yields a Boolean outcome from source inspection. V5 also removed explicit mappings to CWE and NIST, shifting those to the OpenCRE project to avoid maintenance overhead and improve global applicability.
New Chapters Driven by Real Incidents
The new V1 focuses on encoding and sanitization, consolidating scattered requirements. Additions cover CSV injection, LaTeX processing (CVE-2020 leading to RCE), and JNDI validation (Log4Shell). A dedicated front-end security chapter addresses SPAs and modern headers. Self-contained tokens (JWTs) and OAuth each got their own sections. A live code review showed a missing audience claim in a JWT verifier, which creates an authentication bypass if any valid token from the issuer is accepted.
Race Conditions: From One Sentence to Four Requirements
V4 mentioned race conditions in a single sentence. V5 adds four specific requirements covering time-of-check time-of-use (TOCTOU), deadlock, and improper lock ordering. A live demo in Go showed a TOCTOU race: reading a balance, making an external API call, then acting without atomicity. The fix: a mutex or database lock. Another example demonstrated deadlock by acquiring locks in inconsistent order across methods. These requirements help developers recognize common concurrency bugs.
Q&A
With the rebalancing, should teams aim for Level 2 immediately? Eden encourages starting with Level 1 as an accessible starting point and then progressing, but all new controls she contributed ended up at Level 2 or 3. ▶ Watch (43:10)
What primary sources feed into ASVS development? Mainly GitHub issues; contributors note missing requirements (e.g., DOM clobbering, ReDoS, CSV injection) and the working group adds them. ▶ Watch (44:25)
Notable Quotes
We would rather people get started and not feel intimidated by just the quantity of requirements. Eden Yardeni · ▶ Watch (12:40)
What I’m specifically looking for is the is the term time of check, time of use. Eden Yardeni · ▶ Watch (30:05)
I think every single control I added or contributed to V5 ended up being level two or level three. Eden Yardeni · ▶ Watch (43:34)
Key Takeaways
- ASVS V5 reduced Level 1 requirements to encourage adoption.
- New chapters address modern web architectures: SPAs, JWTs, OAuth.
- Four dedicated race condition requirements help catch TOCTOU and deadlocks.
About the Speaker(s)
Eden Yardeni works in application security and is a contributor to OWASP projects, including ASVS v5. She previously worked as a full-stack developer and now focuses on defining and operationalizing application security standards across engineering teams.