Three Assurance Levels and 278 Controls

▶ Watch (1:48)

The ASVS (Application Security Verification Standard) is an open standard with roughly 278 controls across 14 verification topics, ranging from application configuration to threat modeling and access control. Three assurance levels define what each application must meet. Level 1 covers basic security every application should have, like XSS prevention and access controls. Level 2 applies when sensitive data such as payment information is present. Level 3 targets high-risk environments: defense, healthcare, and critical infrastructure. Level 1 is almost entirely verifiable through penetration testing, with two exceptions around encryption protocols.

Why Version 5 Is Being Built

▶ Watch (5:39)

Version 4.03 has redundant requirements and text that needed clarification. Some requirements don’t fit their current chapters given where technology has moved. The working group wants to cut the dense introductory prose from each chapter and push supplementary content to appendices, making it faster to reach the requirements themselves. The goal is clarity without prescription: the standard should not name specific encryption algorithms that risk becoming outdated. Requirements must be specific enough to act on but general enough to remain valid as technology shifts.

New Chapters and the Level Structure Problem

▶ Watch (7:46)

Version 5 adds three new chapters. Web frontend security brings together existing scattered requirements alongside new ones. OAuth 2 gets its own chapter, with nearly all requirements new. WebRTC was contributed by community members Sandro Mortis and a colleague, filling a gap missing from the standard. The level structure is also under review. Levels 1 and 2 hold most controls, leaving Level 3 thin. The working group is discussing whether some Level 1 requirements are too demanding for the “baseline every application must meet” intent.

Fixing CWE Mappings and Streamlining the Document

▶ Watch (9:40)

The current CWE mappings have a reliability problem. Multiple CWEs can apply to a single verification requirement but only one gets listed. The working group is considering shifting to OWASP Common Requirements (CR) as an intermediate mapping layer. That would transfer the update burden to the CR project when new CWEs are added. CWE entries also clutter the requirements list itself. The plan is to move them to a later section or appendix to keep the main document readable.

How to Contribute, Starting from Zero

▶ Watch (13:24)

Contributing starts with watching the GitHub repo and reading the issues. Filter notifications into a dedicated folder to track discussions. Ryan Armstrong’s consultancy built internal testing standards from reading those threads. For deeper involvement: find an issue in your area of expertise and add your perspective. Prutchi’s first contribution came from a WebSocket issue with little activity. She engaged, kept the discussion going, and it landed as a pull request. Employers can also contribute by letting staff spend an hour or two a week on the project.

Q&A

Are there discussions around defining testability conditions for Level 2 and Level 3 controls? Ongoing work exists in that area and evolution is expected in V5, though the current discussion centers more on applicability than testability. ▶ Watch (24:04)

Does ASVS plan to link requirements to implementation guides and cheat sheets? The project aims to add per-chapter cheat sheet links but intentionally avoids prescribing specific frameworks; the MVSP project already demonstrates strong requirement-to-testing linkage as a reference model. ▶ Watch (25:07)

Can ASVS be filtered down to only controls applicable to a specific application? No formal tooling is in the V5 timeline yet; teams currently go through requirements manually and mark exceptions, though the project recognizes this as a common pain point. ▶ Watch (28:24)

Notable Quotes

really prone to like XZ style attacks Ryan Armstrong · ▶ Watch (14:06)

had to get it out of my system everyone Shanni Prutchi · ▶ Watch (21:49)

Key Takeaways

  • ASVS v4.03 has 278 controls; Level 1 is nearly entirely pen-testable, Levels 2 and 3 require backend access.
  • Version 5 adds web frontend, OAuth 2, and WebRTC chapters, targeting a candidate release before end of 2024.
  • Watch the ASVS GitHub issues to learn and find contribution opportunities in your area of expertise.

About the Speaker(s)

Shanni Prutchi is an information security consultant specializing in incident response preparedness and application security. She delivers incident response tabletop exercises and cybersecurity maturity assessments at CrowdStrike, and previously focused on threat modeling at Bishop Fox. She is a member of the ASVS working group.

Ryan Armstrong manages the Application Security Services team at Digital Boundary Group (DBG). He joined DBG as an application penetration tester and security consultant after completing his PhD in Biomedical Engineering at Western University in 2016. He is also a member of the ASVS working group.