# OWASP MASTG: the testing companion to MASVS and MASWE

> The OWASP Mobile Application Security Testing Guide is a documentation repository, not a scanner. It maps MASWE weaknesses to test procedures for Android and iOS, and its v2.0.0 release landed on 2026-06-30.

**OWASP/mastg** — The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.

- Repository: https://github.com/OWASP/mastg
- Website: http://mas.owasp.org/
- Stars: 13,209 · Forks: 2,811
- Language: Python
- License: CC-BY-SA-4.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/owasp-mastg

## What MASTG actually is, and who needs it

MASTG is a manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the weaknesses in the OWASP Mobile Security Weakness Enumeration (MASWE), and those weaknesses are aligned with the controls in the OWASP Mobile Application Verification Standard (MASVS). The README lays out the chain explicitly: MASVS leads to MASWE, which leads to MASTG.

That ordering matters for the audience. If you are writing a security requirement, you work in MASVS. If you are enumerating what can go wrong in a mobile app, you work in MASWE. If you are the person who has to open a decompiler and prove whether a specific weakness is present, you are the MASTG reader. The repository is a Python-based documentation project under the OWASP flagship banner, licensed CC-BY-SA-4.0, and it is not archived: the last push was on 2026-09-20.

The practical value is that a pentest report can cite a test ID instead of describing a technique from scratch. The cost is that you inherit a large, opinionated body of text that you have to keep current yourself.

## How the MASVS to MASWE to MASTG chain is laid out in the repo

The top-level entries show the shape of the project. tests/ holds the test cases, techniques/ holds the reverse engineering and analysis techniques, demos/ and Crackmes/ hold practice material, apps/ and Samples/ hold target applications, and tools/ and utils/ hold supporting scripts. Document/ holds the site source, and prerequisites/ holds the setup material a tester needs before running anything.

This is a content architecture rather than a runtime architecture. A test case in tests/ is prose plus references; a technique in techniques/ describes a procedure; the demos and crackmes are the artifacts you point those procedures at. The README does not describe a service, a database, or a network protocol, because there is none. The build produces a static site and a set of checklists.

Two GitHub Actions workflows guard the content: markdown-linter.yml and url-checker.yml. That tells you the maintainers treat link rot and formatting drift as real defects, which is the right instinct for a reference document that other standards point at. It also tells you the CI checks prose, not correctness of the security claims.

## Reading MASTG without a local build

The README's own route to the content is the hosted site. It lists the MASTG Web at mas.owasp.org/MASTG/ and directs readers to the latest release for the Mobile App Security Checklists. That is the fastest way to evaluate the guide, and it needs no toolchain at all.

The repository does carry a .dockerignore at the top level, which indicates a containerised build path exists, and the primary language is Python. The README does not document the build commands themselves, and the repository files provided here do not include a Dockerfile or a task runner listing, so any command this article printed would be a guess. Confirm the build steps from the repository's own setup files rather than from a third-party summary.

One convention worth knowing before you start reading: test identifiers appear in the guide's numbering scheme, and search traffic for a specific identifier such as test 0001 shows that people cite these tests by number in reports and tickets. That is why a stable numbering scheme matters more here than in an ordinary documentation site. If you are evaluating the guide, open a few tests in the hosted site and check that the numbering and the weakness references line up the way you would cite them.

## Where MASTG stops being the right tool

MASTG will not scan anything for you. There is no analyser in this repository that takes an APK or an IPA and returns findings. If your requirement is continuous automated coverage in a CI pipeline, this project is the wrong layer: it gives you the test definitions that such tooling would implement, not the implementation.

The second limitation is freshness against platform change. Android and iOS release on their own cadence, and a documented technique can quietly stop working when an OS version changes its storage layout or its runtime protections. The markdown linter and URL checker catch broken links and formatting, not obsolete procedures. You are responsible for noticing that a technique no longer reproduces on the current OS.

The third is scope. The material is organised around Android and iOS application testing. If your target is a mobile backend API, a cross-platform framework's native bridge, or a device management layer, MASTG covers the app-side portion and leaves the rest to other references. Reading it as a complete mobile security programme will leave gaps you did not plan for.

## MASTG against the OWASP MASVS and MASWE repositories

The obvious alternative is not a competing vendor but the sibling OWASP projects. MASVS is the verification standard: a list of controls you assert about an application. MASWE is the weakness enumeration: a catalogue of things that go wrong. MASTG is the procedure layer that sits underneath both.

The difference in approach is that MASVS and MASWE are meant to be cited and assessed against, while MASTG is meant to be executed. A compliance conversation can end at MASVS. An engineering conversation about how to confirm a control holds has to reach MASTG, because that is where the technique and the demo target live. If you adopt only MASVS, you get a checklist with no method attached. If you adopt only MASTG, you get methods with no agreed statement of what the result should be.

The repository also ships Crackmes, which is a third mode: deliberately vulnerable practice apps. Those are for building skill, not for assessing a real target. Teams often conflate the two and then wonder why a crackme-shaped exercise did not transfer to a production app with obfuscation and anti-tampering in place.

## Maintenance cost, contribution path and the CC-BY-SA-4.0 licence

The last push was on 2026-09-20, and the most recent release, v2.0.0, is dated 2026-06-30. Two further releases, v1.9.0 and v1.8.0, both landed on 2026-06-24. That release rhythm suggests the project is being cut regularly rather than left to drift, and the presence of CHANGELOG.md and CITATION.cff at the top level means changes are recorded and the project is intended to be citable in formal work.

Upgrade cost is where teams underestimate the project. Because MASTG is documentation, an upgrade is not a dependency bump. Moving from v1.9.0 to v2.0.0 can renumber or restructure tests, which invalidates any internal mapping you built between your own test IDs and the guide's. If your reports cite MASTG test identifiers, budget time for that remapping on every major release.

The licence is CC-BY-SA-4.0, referenced from the README badge and from License.md in the repository. For an engineering reader the practical consequence is share-alike: derived material carries the same licence. How that interacts with your own internal report templates, or with a commercial product that embeds excerpts, is a question for your legal team, not something this article can settle. The README also points to a contributing page for anyone who wants to send changes upstream.

## Conclusion

Adopt MASTG if your team needs a shared, citable vocabulary for Android and iOS test coverage and is willing to track the upstream master branch rather than a pinned snapshot. Do not adopt it expecting an automated scanner or a one-off read: the repository is the deliverable, and the checklists ship attached to releases such as v2.0.0. Before you commit, open the guide at mas.owasp.org/MASTG/ and confirm that the tests and demos you plan to cite are present in the version you intend to reference, then check the License.md file and the Creative Commons deed for how CC-BY-SA-4.0 affects your own derived material.

## FAQ

### What is MSTG?

MSTG is the older abbreviation for the OWASP Mobile Application Security Testing Guide, now published as MASTG. The repository describes it as a manual for mobile app security testing and reverse engineering that verifies MASWE weaknesses aligned with MASVS controls.

### What is mast software?

In this context MASTG is not a standalone application but a documentation project: a manual describing technical processes for mobile app security testing and reverse engineering. The repository is Python-based and builds a guide plus checklists rather than shipping a runnable scanner.

### How does MASTG differ from MASVS?

MASVS is the OWASP Mobile Application Verification Standard, a set of controls to verify against. MASTG is the testing guide that describes the technical processes for verifying the MASWE weaknesses aligned with those controls. The README presents them as a chain: MASVS, then MASWE, then MASTG.

## Sources

- [License: CC-BY-SA-4.0](https://github.com/OWASP/mastg/blob/master/LICENSE)
- [OWASP/mastg on GitHub](https://github.com/OWASP/mastg)
- [Project website](http://mas.owasp.org/)
- [README](https://github.com/OWASP/mastg/blob/master/README.md)
- [Releases](https://github.com/OWASP/mastg/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-mastg