OWASP ASVS: six versions in the tree, a rolling latest tag, and a language list parsed from git status

Six versions of the standard live in the repository as directories

The top level of this repository is six directories named after versions, covering everything from the first release through the current one, and there is a small subdirectory for a single point release in between two majors. Each holds a full copy of the document in each language. That is the unusual thing about this project: it is a publication, not a program, and it keeps its own back catalogue in version control rather than on a download page. Two documentation files sit beside them, one describing how to compile the document and one describing the release strategy. There is also a page crediting supporters, a wall of fame, a security policy and a markdown lint configuration, because at heart this is a large document with a build system attached.

The newest release is a rolling tag that calls itself bleeding edge

Three releases are visible and the newest is not a version. Its tag is the word latest and its title says bleeding edge. Before it, a release tagged with the version number and the word release, from May 2025, and before that the same style of tag for version four, from October 2021. The README is explicit about what the default branch means: it will always be the bleeding edge version, which might have changes or edits still open, and the next release target is a patch release of the current version. So there are two kinds of thing in the release list, a moving pointer and a fixed snapshot, and a consumer who installs by tag gets one or the other depending on which they pick.

The document is built inside a container pulled from a moving tag

The build file is the clearest statement of how this project makes its artefacts. Each target runs a container image hosted on a package registry, pulls that image or builds it locally if the pull fails, mounts the version directory as the data volume and a scripts directory as the tool volume, and passes the target version plus the requested formats and languages as environment variables. Two details matter. The image tag is the same rolling word used by the release list, so the PDF you produce depends on a builder that can change without notice. And the container is run as your own user and group identifier, which is the right call for writing files into a directory you own, and means the build cannot silently write anything you could not write yourself.

The list of languages to build is parsed out of your working copy

One target in the build file is a shell pipeline with three sed expressions, an uniq pass and a tr, and its job is deciding which languages to build for the older version. It changes into that version's directory, runs a status command with the short output format, strips the status letters and the version prefix out of each line with a bracket expression, keeps only the first path component, filters that against a fixed list of language codes, and joins the survivors with spaces for the container to read. So the language list is derived from which files your checkout currently reports as added, renamed or removed, which means deleting a translated document locally is enough to get it rebuilt, and a clean checkout of a branch with no changes in that directory builds nothing.

Translations are declared to be a best effort with no structural checking

The translations section says something a lot of projects would not: the community effort on translations is a best effort, the maintainers do their utmost to ensure the content is valid, but from a structural perspective there is only so much they can do to ensure the translations are correct, and they rely on the community. The README then lists what exists, and each entry credits its translators by name with links to their profiles. The lists are wildly uneven: Turkish credits one person, French about five, Russian about ten, and one of them twenty. Two entries are formatted as plain text names without links, in the middle of lists where every other name is a link, which is the kind of small inconsistency that appears when a credit line is edited rather than regenerated.

One name appears twice, once as maintainer and once as translator

The credits sections are worth reading as a record of who does the work. Three project leaders are named, and they are supported by a working group of eight. Then the translation lists name a further twenty-odd people. Read the two lists together and one name appears in both: a member of the working group is also credited on the French translation. That is not a problem, it is a sign that the working group is doing translation work rather than only process work, which is consistent with a project whose entire output is a translated document. It is also the kind of detail that a reader can only find by doing exactly what the structure invites, which is reading the credits all the way down.

The standard ships as a spreadsheet, which is the useful part

The download section for the current release offers four things: a PDF, a Word document, a spreadsheet, and a branch of the repository at the same version. Three of those four are obvious for a standard document. The spreadsheet is not, and it is the most consequential choice in the list, because it means the requirements can be loaded into whatever tool a team already uses to track them rather than read off a page. The PDF is what you send to an auditor, the word file is what you edit, and the branch is what you diff when you want to see exactly what changed between two versions. Nothing in the README says the spreadsheet is the intended input to anything, which is a shame.

The README never explains the verification levels

Here is the gap worth naming. The people who land on this project are overwhelmingly looking for two things: what the standard covers, and what the numbered levels mean. The README answers the first and is silent on the second. It gives the aim, the history from the first launch through the two previous versions to the current one, the leaders, the supporters, the downloads, the release strategy and the translation policy, and then it ends. Not one sentence in the visible document defines a level or says how many there are, so every search for the level-one or level-two version of this standard ends in a page that does not answer the question.

Editorial conclusion

This is the document to reach for when you need a security requirements list that a team can be held to, rather than a checklist written by whoever is reviewing, and the spreadsheet output is the part that makes it usable in a scanner. Two things to know before you adopt it as a baseline. The default branch is explicitly the unreleased line, so pin to a release tag or a version directory rather than reading the master branch as the current standard. And the translations are described by the project itself as a best effort with no structural verification, so if your team reads a non-English copy, compare it against the English requirements before you treat it as authoritative.

Frequently asked questions

Official sources

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