Standards
OWASP MASVS coverage
The Mobile Application Security Verification Standardis the common vocabulary between a testing vendor and an enterprise security team. Below is an honest account of which control groups real-device dynamic testing can evidence and which it cannot.
Coverage by control group
| Group | Area | Dynamic fit | Notes |
|---|---|---|---|
MASVS-STORAGE | Storage | Partial | Device filesystem and session state are inspectable after a run. Confirming that a secret was never written anywhere still benefits from static review. |
MASVS-CRYPTO | Cryptography | Partial | Weak transport-layer cryptography and unprotected sensitive fields are visible in captured traffic. Key management and algorithm choice inside the binary are static concerns. |
MASVS-AUTH | Authentication | Strong | Login, registration, session lifetime, token handling and step-up authentication are exercised end to end — and are exactly the flows that anti-emulator checks gate. |
MASVS-NETWORK | Network communication | Strong | Full TLS-inclusive capture per device. Cleartext transmission, weak negotiation, absent validation and third-party leakage are directly evidenced. |
MASVS-PLATFORM | Platform interaction | Partial | Runtime permission behaviour and inter-app surfaces are observable. Manifest-level review remains static. |
MASVS-CODE | Code quality | Out of scope | Verified by binary and dependency analysis rather than runtime observation. |
MASVS-RESILIENCE | Resilience | Strong | The group concerns behaviour under attack. Establishing what the defences do requires a device the application will actually run on, which is the platform’s core capability. |
MASVS-PRIVACY | Privacy | Strong | What identifiers leave the device, to which hosts, and whether that matches the stated policy is answered from captured traffic. |
Why resilience is the group that breaks on emulators
MASVS-RESILIENCE asks what an application does when someone is attacking it: whether it detects a compromised environment, how it responds, and whether those defences can be removed. Verifying it requires observing the defences operating normally.
On an emulator, the defences have already fired before the assessment begins. The application is in its degraded state, and every subsequent observation describes that state rather than the one users experience. The result is not a weak assessment of resilience — it is an assessment of a different application.
Current status
Evidence collection — device, flow execution, full traffic capture, video and UI tree — is running in production. The reporting layer that turns that evidence into ranked findings carrying MASVS identifiers and remediation guidance is being built now, with design partners.
We would rather state that plainly than describe a report generator that does not exist yet.
Frequently asked questions
Does Elenchia produce a MASVS-compliant report today?
Not yet. The device platform, workflow engine and traffic capture are in production; the layer that converts captured evidence into ranked findings mapped to MASVS control identifiers is in active development. Design partners are shaping it now.
Can dynamic testing alone satisfy MASVS?
No, and no vendor should claim otherwise. Several MASVS groups — notably code quality and parts of cryptography — are verified by inspecting the binary or the source, not by observing runtime behaviour. Dynamic testing on a trusted device is the part that emulators cannot do, not the whole standard.
What is the difference between MASVS and MASTG?
MASVS states the requirement. MASTG describes the procedure that establishes whether the requirement is met. Reports cite MASVS identifiers; testers follow MASTG procedures to get there.