Otukan’s controls support the resilience part of an OWASP MASVS review most directly: platform integrity checks, anti-tampering, anti-static analysis and anti-dynamic analysis, each scoped separately for Android and iOS. They also give reviewers supporting evidence for some platform-interaction and authentication controls. Storage, cryptography, network, privacy, code quality and most authentication controls stay with your own code and backend. This page shows which Otukan capabilities map to which MASVS category, how to tie that mapping to the MASVS version your organisation uses, and why a mapping supports a review without replacing it.
Scope
The OWASP Mobile Application Security project publishes several related documents. MASVS is the verification standard: it states what a secure mobile app should achieve. MASTG is the testing guide: it describes how testers check those requirements on Android and iOS. Keeping the two apart avoids a common mistake, which is treating a list of features as test evidence.
MASVS controls fall into three kinds of work, owned by different people.
| Kind of control | What it covers | Usually owned by | Where Otukan fits |
|---|---|---|---|
| Secure development | How the app stores data, uses cryptography, authenticates users, talks to the network and handles privacy | Your mobile and backend engineers | Your code; Otukan runtime signals inform authentication decisions |
| Testing | Verifying each requirement with MASTG techniques, on each platform | Your testers or an external assessor | Otukan helps your testers exercise its own controls on your build |
| Resilience | Making the app harder to analyse, modify and run in a compromised environment | Your security lead, with a protection product | Otukan’s primary area |
Resilience in context
MASVS treats resilience as defence in depth. It raises the effort needed to reverse engineer or tamper with an app, and it works best when the secure development controls underneath are already sound. Apps that handle money, identity or valuable intellectual property are the usual candidates for resilience requirements.
Mapping
Map only what you can evidence, and tie every row to the MASVS version in use at the time of the review.
Capability-to-category table
| MASVS category | Requirement in plain words | Otukan capability | Mapping strength |
|---|---|---|---|
| MASVS-RESILIENCE-1 | The app checks the integrity of the platform it runs on | Root detection on Android, jailbreak detection on iOS, emulator detection | Direct support |
| MASVS-RESILIENCE-2 | The app has anti-tampering mechanisms | Anti-tampering checks on code, resources and signing certificate | Direct support |
| MASVS-RESILIENCE-3 | The app resists static analysis | Code obfuscation and string encryption | Direct support |
| MASVS-RESILIENCE-4 | The app resists dynamic analysis | Anti-debugging and hooking detection | Direct support |
| MASVS-PLATFORM | The app uses platform features and user interfaces safely | Screen capture protection; overlay detection on Android | Supporting evidence |
| MASVS-AUTH | Sensitive operations get suitable authentication | Runtime signals your backend can use for step-up decisions | Supporting evidence |
| MASVS-STORAGE, MASVS-CRYPTO, MASVS-NETWORK, MASVS-PRIVACY, MASVS-CODE | Data at rest, cryptography, network communication, privacy, code quality and dependencies | None claimed | Your code and configuration |
“Direct support” means the Otukan control is designed to meet the intent of that requirement. “Supporting evidence” means Otukan contributes a signal or a protection that your reviewer can weigh, while the requirement still depends on your own implementation.
Tie the mapping to a version
MASVS has changed shape over time. Earlier versions grouped requirements into verification levels; the current structure uses control categories with testing profiles defined alongside the testing guide. A mapping written against one version can mislead when read against another. Record the version and the date on every mapping you keep, and review the mapping whenever OWASP publishes a new version.
Evidence behind each row
- Does each row name the Otukan control, the platform and the framework layer it was tested on?
- Does each row cite the MASTG test used and the result on your protected build?
- Are Android and iOS results recorded separately, with device and OS version?
- Is the reviewer and the review date recorded for each row?
Otukan supplies the per-control Android and iOS scope for every row it supports, and helps your testers run the MASTG-referenced tests against its own controls on your build.
Limits
A clear boundary makes a mapping more credible, not less.
Mapping is not certification
MASVS is a verification standard. A capability mapping shows where a control contributes evidence toward a requirement; it does not show that the app as a whole meets the standard, and it does not replace an assessment by your testers or an independent assessor. Otukan presents its mapping as input to that assessment.
Standards alignment is not legal compliance
Regulators and sector bodies sometimes refer to MASVS in guidance. Whether a given app satisfies a legal or contractual obligation depends on the full obligation, your whole app and your organisation’s processes. A resilience control mapping supports that conversation with your compliance team; it does not settle it.
Before you cite the mapping in a report
- Is the MASVS version stated, and does every row match that version?
- Have the categories owned by your own code been tested separately?
- Are rows marked “supporting evidence” described as such, and not as met?
- Has a named reviewer signed off the mapping on a stated date?
For how Otukan’s controls fit together, see mobile app security.