OWASP ASVS: the requirements checklist behind application security reviews

What ASVS is for, and who ends up using it

ASVS is an open application security standard for web apps and web services of all types. That sentence from the README is the whole scope: it defines security requirements for designing, developing and testing modern web applications and services. It is a document, not a runtime component. Nothing in it scans your code or watches your traffic.

The people who get value from it are the ones who need a shared vocabulary across roles. A security architect writing acceptance criteria, a developer deciding what 'done' means for an authentication flow, a tester who needs to know which checks are in scope for this engagement, and an auditor who has to justify a finding. ASVS gives all four the same numbered requirements.

It has been around since 2008 and is maintained as a community project under OWASP. Version 4.0 arrived in 2019, a minor update 4.0.3 followed in 2021, and version 5.0.0 was released in May 2025. The repository's last push was on 2026-09-03, and the master branch is described as the bleeding edge version, which the README says might contain in-progress changes. The next release target named in the README is a patch release, 5.0.1.

Requirements, levels and the document pipeline

The mechanism is a numbered set of requirements organised into verification levels. That structure is why the standard works as a contract: a requirement has an identifier, so a review finding can cite it and a ticket can be closed against it. The README does not spell out the level definitions in the text available here, so if you need the exact boundary between L1 and L2, read the 5.0 documents rather than a summary.

The repository itself is a build pipeline for those documents. Top-level directories 1.0 through 5.0 hold the content for each major version, and a Makefile drives generation. The 5.0 target pulls a container image, mounts the 5.0 directory as /data and the docker directory as /scripts, and passes TARGET, FORMATS and LANGS as environment variables. Output formats follow from FORMATS, which is how the same source produces the PDF, Word and CSV files linked in the README.

The 4.0 target differs in one visible way: its LANGS value is computed by inspecting git status in the 4.0 directory and filtering for language codes such as ar, de, en, es, fr, pt, ru and zh-cn. That is a build-time detail, but it tells you translations are tracked as directories rather than as a separate translation system.

Getting the ASVS 5.0 PDF, CSV or Word file

Most readers never build anything. The README links the stable 5.0.0 edition directly, and the CSV is the one to grab if you intend to load requirements into a spreadsheet or an issue tracker. The links point at the v5.0.0 tag, not at master, which matters because master is explicitly the in-progress branch. The PDF and Word files are the reading copies; the CSV is the working copy.

Building the documents yourself with the Docker builder

If you are editing content or producing a language edition, the Makefile is the entry point. The docker target pulls the builder image and falls back to building it locally if the pull fails, using the repository's docker directory as the build context.

make docker

After that, the 5.0 target runs the builder against the 5.0 directory. FORMATS and LANGS are passed through from your environment, so an unset FORMATS means the container decides what to emit rather than you.

make 5.0

The 5.0-clean target uses the same image with TARGET=clean, which is the way to clear generated output before a rebuild. The 4.0 target works the same way but derives its language list from the working tree, so a dirty 4.0 directory changes what gets built. The README and COMPILING.md are where the project documents the details; the Makefile shows the mechanics.

Where ASVS stops being the right tool

ASVS tells you what should be true. It does not tell you whether it is true in your codebase. There is no scanner, no linter, no CI action in this repository. You supply the testing, whether that is manual review, a penetration test or an automated tool mapped to the requirement numbers. Teams that download the CSV expecting a checklist they can tick automatically are going to be disappointed, because the hard part is the evidence, not the list.

The second limitation is scope. The README states the standard is for web apps and web services. Mobile applications are a different document family, and the related-searches data shows people confusing ASVS with MASVS. If your target is a native mobile client, ASVS is not the standard you want.

The third is version drift. Master is the bleeding edge and may contain in-progress changes, while 5.0.0 is the stable release. Any tooling, spreadsheet or internal wiki that references 'ASVS' without a version tag will silently change meaning over time. Pin the version.

Finally, the translation situation is honest but uneven. The README calls translation a community best-effort and says there is only so much the project can do to ensure translations are correct. Turkish, Russian, French and Korean 5.0.0 editions are listed, and the project is looking for more help. If your organisation works in a language without a listed edition, you are reading English.

ASVS against the OWASP Top 10 and the WSTG

The OWASP Top 10 is a short awareness document about categories of risk. ASVS is a long requirements catalogue you verify against. The practical difference shows up in a review: the Top 10 tells you that broken access control is a problem area, while ASVS gives you numbered requirements that let you say which access-control behaviours you checked and which you did not. Use the Top 10 to get attention and ASVS to define the work.

The OWASP Web Security Testing Guide is the closest sibling, and the split is clean. The WSTG describes how to test; ASVS describes what must hold. A tester works from the WSTG for technique and cites ASVS for the requirement the technique verifies. If you only need a testing playbook, the WSTG alone is enough. If you need a pass/fail bar that a third party can audit, ASVS is the one that carries identifiers.

OWASP SAMM is a different shape again: it is a maturity model for a security programme, not a list of application requirements. SAMM asks how good your processes are over time. ASVS asks whether this application meets this requirement now. Teams sometimes run both, using SAMM to plan the programme and ASVS to measure individual applications.

Licence, upkeep and what a version bump costs

The repository is licensed CC-BY-SA-4.0, a Creative Commons Attribution-ShareAlike licence. That is a content licence, not a software licence, and it carries a share-alike condition: adaptations you distribute need to be under the same terms, with attribution. Embedding requirement text in an internal spreadsheet is normal use; republishing a modified version of the standard is where the share-alike clause starts to matter. This is not legal advice, and if you plan to redistribute a derived edition, read the licence text and get your own counsel.

Upgrade cost is the part teams underestimate. Moving from 4.0.3 to 5.0.0 means re-mapping every internal control, ticket template and tool rule that referenced 4.x numbering. The README describes 5.0 as modernized to reflect advances in software security, which is exactly the kind of change that renumbers things. Budget the mapping work as a project, not as a documentation update. The planned 5.0.1 patch is a smaller event by the README's own description, but any branch that tracks master is tracking in-progress content.

Editorial conclusion

Adopt ASVS when you need a shared, versioned list of security requirements that architects, developers and testers can all point at, and when you can afford the review work that L2 or L3 implies. Do not adopt it as a scanner or as a drop-in replacement for the OWASP Top 10, and do not treat it as a compliance certificate. Before you commit, verify which version tag your tooling references, confirm the language edition you need exists under 5.0/docs_<lang>, and check whether your team can actually close the gaps an L2 review will surface.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. OWASP/ASVS on GitHub
4. README
5. Releases