OWASP MASVS: a standard whose newest tagged release is from January 2024

A standard that hands its work to two other projects

MASVS on its own is a statement of baseline security and privacy requirements for mobile apps, and the readme is quick to say what it is not responsible for. The requirements are broken down in the Mobile Security Weakness Enumeration, a separate repository, and the testing that verifies them lives in the Mobile Application Security Testing Guide, a third. The readme draws the relationship as an arrow chain, from the verification standard to the weakness enumeration to the testing guide, and that ordering is the whole model: the standard says what must be true, the enumeration names the ways it goes wrong, the guide tells you how to find out. Three uses are given for it. As a metric, so existing apps can be compared against a standard by developers and by application owners. As guidance across all phases of development and testing. And during procurement, where a buyer needs a baseline to verify a vendor's app against. It is worth noticing that the opening sentence contains a duplicated word, breaking the requirements down in the the enumeration, which is the sort of thing that survives in a document this widely mirrored.

The newest tagged release is two years and eight months old

For a document that organisations cite in contracts and audits, the release dates are the part worth checking. The visible history is three tags: 1.5.0 in January 2023, 2.0.0 in April 2023, and 2.1.0 in January 2024. The branch's last recorded push is 2026-09-21. So the newest artefact anyone can download from the releases page is roughly two years and eight months behind the tip of the branch, which means the text people are reading on the site is not necessarily the text in a tagged PDF, and neither is necessarily what a working group agreed to most recently. None of that is evidence of neglect, since the repository has four open issues and nearly two and a half thousand stars, and the branch is clearly not idle. It is evidence that for this project the branch and the release are two different states, and that a compliance process should pin a version and cite it rather than quote the live site.

Two book formats and a directory with a capital letter

The repository root shows two generations of documentation tooling living side by side. There is a GitBook configuration file and there is a book manifest for the other book generator, which means the same content can be built two ways and the project has not picked one. The content lives in a directory whose name starts with a capital letter, which is worth knowing if you script anything against the tree, because case matters on the platforms people actually use, and there is a separate directory of controls plus a tools directory. The licence is a Markdown file rather than the plain text name most automated licence checks look for, and the cover artwork is committed twice, as an image and as a PDF. The primary language recorded for the repository is Python, which is a good reminder that the content here is not code: the Python lives in the tooling, and the substance is Markdown and a YAML file at the root.

Three workflows guard a document full of links

The badges at the top of the readme are not the usual build and coverage markers. They point at three workflows: one that generates the documentation, one that lints the Markdown, and one that checks URLs. For a standard whose value depends on cross references between requirements, weakness identifiers and test cases, an automatic link checker is the most valuable of the three, because a broken reference in a requirement list is a defect that no reviewer would notice and every auditor would hit. The Markdown linting has its own configuration file at the root, and an editor directory is committed as well. There is also a changes file, a code of conduct, a contributing guide and a pull request template, so the governance apparatus around a text document is in good shape. What is missing from the badges is any indication of a version or a build number, which is consistent with a project whose releases are infrequent and whose branch does the work.

The adoption page lives inside the testing guide's documentation

Two sections of the readme make claims about adoption and both link sideways. The first says the three projects are trusted by platform providers and by standardisation, governmental and educational institutions, and its learn more link points at a page inside the testing guide's documentation rather than at anything in this repository. The second defines MAS Advocates as industry adopters who have put significant and consistent resources into pushing the projects forward through consistent high impact contributions and by spreading the word, and that link lands on the acknowledgements section of the same external documentation, down to an anchor. Both are reasonable choices, since the three projects are presented as one programme with one site. They do mean that the evidence for a project's standing is not versioned alongside the project, so if you are citing adoption in an audit you are citing a web page that changes without a release.

Three download links, two of them from a sibling repository

The entry points are a useful map of how the work is split. The web version is one project site. The PDF of the standard itself is downloaded from the releases page of this repository. The checklists, which are the thing most people actually want, are downloaded from the releases page of the testing guide instead, a different repository with a different release cadence. So a reader who wants the standard and the printable checklist ends up pinning two repositories. The remaining entry points are the contributing page, a contact page, and a set of deliberately crackable applications to practise against, which is the only item in the list that is not a document at all and the only one that is unambiguously fun. That asymmetry is probably deliberate: the standards work is reference material, the crackmes are how you find out whether you can check something.

A YAML file at the root, and a licence with two obligations

The machine readable layer is a single YAML file with the project's name in it at the repository root, which suggests the requirements are available in a structured form as well as in prose, and that something in the toolchain reads it. Nothing in the readme says who consumes that file, which is the kind of detail that would matter a great deal to anyone building tooling on top of the standard and is not documented at the entry point. The licence is the Creative Commons share alike at version four, which the readme links from a badge near the top, and it is the only content licence in play here rather than a software licence, which is the correct choice for a standard and also means there is no software warranty language anywhere in the project. The obligation that matters in practice is share alike: adapt the standard and your adaptation carries the same terms, which is what makes the standard usable as a procurement baseline without being vendor owned.

Editorial conclusion

MASVS fits a team that needs a shared yardstick for mobile app security, especially a procurement or audit function that has to compare what an app owner claims against something written down, and that is prepared to read the enumeration and the testing guide alongside it. It does not fit as a checklist you can apply in an afternoon, because the standard is deliberately a statement of requirements and the work is in the testing guide. Before you adopt a version, check three things. Which release you are pinning, since the tagged artefact stopped at 2.1.0 while the branch has been pushed since. Which of the three projects you are actually reading, because the requirements, the weakness list and the tests are three separate documents with three separate release schedules. And where the requirement text you are quoting came from, because the site and the repository are two artefacts built by different tooling.

Frequently asked questions

Official sources

1. License: CC-BY-SA-4.0
2. OWASP/masvs on GitHub
3. Project website
4. README
5. Releases