Your mobile release is a binary in the hands of everyone who installs it.
Upload an Android or iOS package and get a full static assessment against the OWASP Mobile Application Security Verification Standard: configuration, transport, cryptography, storage, platform interaction, binary hardening, third-party components, and embedded secrets. Findings land in the same workflow your team already uses for web and API results.
You cannot patch a mobile release server-side.
A web fix ships in minutes. A mobile fix ships through a build, a store review, and a user update, and the old version stays installed on devices for months. Everything the package carries, including the keys and endpoints inside it, is readable by anyone who downloads it.
That changes what matters. A hardcoded credential in a mobile binary is already disclosed. A cleartext endpoint is already reachable. An exported component is already callable by any other app on the device. Mobile Security Assessment finds those conditions before the release leaves your build system, and states plainly how an attacker would reach each one.
[package] com.acme.banking 4.2.0 (build 4200), Android
[signing] v1 + v2 + v3, RSA 2048, expires 2039-11-04
[sbom] 114 components, 106 with a resolved version
[finding] transport: cleartext permitted for 2 domains
[finding] storage: credentials in unencrypted preferences
→ mapped to MASVS, MASTG, CWE and OWASP Mobile Top 10
→ promoted into Findings with owner, SLA and audit trail
More than 200 checks, across every MASVS group.
The package is taken apart and analysed as a whole: manifest and property lists, compiled code, native libraries, signing material, bundled assets, and every resource that ships with it. Nothing is inferred from the file name.
Configuration and platform exposure
Debuggable builds, backup exposure, components reachable by any other app on the device, deep links without domain verification, and URL schemes any app can claim. Exposure is derived from how the platform actually resolves it, not from a single attribute.
Transport security
Cleartext traffic policy, user-installed certificate trust, debug overrides shipped to production, certificate pinning, and App Transport Security exceptions on iOS. Every endpoint the package carries is inventoried and flagged when it is plain HTTP.
Cryptography and key handling
Broken and withdrawn algorithms, block modes that leak structure, predictable random sources, key material that never reaches a hardware-backed store, and keychain items bound more loosely than the data requires.
Data storage and privacy
Credentials in unprotected preferences, unencrypted local databases, credential and database files shipped inside the package, and the inventory of third-party data collection and session-replay SDKs the release carries.
Binary hardening and resilience
Position independence, stack protection, automatic reference counting, memory-unsafe imports, signing scheme coverage, provisioning channel, and whether the build makes any attempt to notice a rooted device, an attached debugger, or a repackaged copy of itself.
Components and embedded secrets
A CycloneDX software bill of materials recovered from the shipped artefact, matched against published advisories and the CISA KEV catalog, plus provider-anchored detection of credential material embedded in the package.
A finding your engineers can act on, or it does not belong in the report.
Mobile static analysis has a reputation for producing long lists nobody reads. The reason is almost always the same: a third-party library's own content gets attributed to the application. WASViking treats that as an engineering problem, not an acceptable cost.
Library content is attributed to the library
Evidence that belongs to a bundled dependency rather than to your code is downgraded and labelled as such, with the reason stated on the finding. Nothing is hidden: every adjustment is listed in the report so a reviewer can disagree with it.
Versions are recovered, never guessed
A component whose exact version cannot be recovered from the artefact appears in the bill of materials but is excluded from advisory matching. An unconfirmable CVE is worse than no CVE.
Every score explains itself
Each finding carries the attack path, what an attacker needs before they can use it, and the inputs that produced its risk score. The scoring model ships with the report, so the number is reviewable rather than assertable.
Release confidence, and the evidence to prove it.
Mobile is where regulated data meets an uncontrolled device. Assessing every release turns that from an annual penetration test finding into a build-time answer.
Regression control between releases
Two releases are compared by finding identity, not by report text. The team sees what the build fixed, what it introduced, what it carried forward, and which dependencies moved. That is the conversation a release review needs.
Store and privacy declarations that hold up
The tracker and permission inventory is what your privacy notice and store data-safety declaration have to match. A mismatch is a regulatory exposure on its own, independent of any technical vulnerability.
Audit evidence in the same place as the rest
Mobile findings enter the same workflow as web and API results: owner, severity, SLA, audit trail, and export. One risk register, not a separate PDF that ages the day it is written.
Mapped to the standard your mobile auditor already uses.
Every finding carries its OWASP MASVS control, the matching MASTG verification procedure, a CWE, and its OWASP Mobile Top 10 classification. Reports that still reference the earlier MASVS generation are supported: the legacy requirement identifiers travel alongside the current ones.
| Framework | Control | What Mobile Security Assessment contributes |
|---|---|---|
| OWASP MASVS v2 | Storage, Crypto, Auth, Network, Platform, Code, Resilience, Privacy | Per-release verification across all eight control groups, with the MASTG procedure to reproduce each result by hand |
| PCI DSS v4.0 | Req 6.2.4 software engineering techniques · Req 6.3.2 inventory of bespoke and third-party components | Release-level evidence that common mobile attack classes were tested for, plus a component inventory generated from the shipped artefact |
| ISO 27001:2022 | Annex A.8.24 use of cryptography · A.8.26 application security requirements · A.8.28 secure coding | Per-release record of cryptographic use, application security verification results, and the coding conditions found in the build |
| NIST CSF 2.0 | PR.PS-06, secure software development practices are integrated | Repeatable pre-release assessment with a durable record for each version, comparable across releases |
| LGPD · GDPR | Article 46 · Article 32 technical measures | Evidence of transport and storage protection on the client, plus the inventory of third-party data collection the release ships with |