Mobile Security Assessment
Static security assessment of Android and iOS application packages against the OWASP Mobile Application Security Verification Standard, with SBOM, contextual risk scoring, and release-to-release comparison.
WASViking® Mobile Security Assessment analyses a compiled Android or iOS application package and reports what it exposes. It covers configuration, transport security, cryptography, local data storage, platform interaction, binary hardening, third-party components, embedded credential material, and the data-collection SDKs the release ships with.
The assessment is static. Nothing is installed, nothing is executed, and no device is required. You upload the artefact your build system produced and read the result.
This is the portal section at Mobile Security → Assessments.
What you can upload
| Format | Platform | Notes |
|---|---|---|
.apk |
Android | The standard application package. |
.aab |
Android | App Bundle. The base module is analysed. |
.xapk, .apks |
Android | Split-package containers. The base module is extracted and analysed; the report says which one. |
.ipa |
iOS | The App Store package. |
The format is decided by reading the container, not the file extension. A package that is not a mobile application is refused at upload with the reason.
Uploads are capped at 600 MB. If your artefact is larger than that, contact support before the assessment window.
Running an assessment
- Open Mobile Security → Assessments and choose Analyse a package.
- Drop the file, or browse for it.
- Optionally add a Label. Use the release name or the ticket reference; it is what you will look for later when comparing versions.
- Start the assessment.
Progress is shown live while it runs, stage by stage. A typical package completes in under a minute. Large packages with many dependencies take longer.
You need the Upload permission on the Mobile Security resource. See Inviting your team for the role matrix.
Reading the report
The report opens on Overview and is organised in tabs.
| Tab | What it answers |
|---|---|
| Overview | Grade, risk score, severity breakdown, the executive summary, the highest-risk findings, and what the assessment could not see. |
| Findings | The full list, filterable by severity, category, MASVS group and OWASP Mobile Top 10 slot. Selecting a finding opens the detail panel. |
| MASVS Coverage | Every MASVS control, whether it was assessed, and how many findings landed against it. |
| Components & SBOM | The dependency inventory recovered from the package, and the CycloneDX download. |
| Secrets | Credential-shaped values found in the package, masked. |
| Network | Every endpoint the package carries, with the cleartext ones marked, plus the transport configuration. |
| Privacy & Trackers | Third-party data-collection SDKs, grouped by purpose. |
| Package Detail | The decoded manifest or property list, components, permissions, entitlements, and binary hardening flags. |
| Coverage & Limitations | Which checks ran, which did not, and why. |
The finding detail panel
Each finding carries:
- What it is and the concrete attacker capability it creates.
- Why it matters here: the attack path, and what an attacker needs before they can use it. "Anyone who downloads the app" and "a rooted device the attacker already controls" are very different answers, and the panel says which one applies.
- Risk score with the inputs that produced it, written out rather than asserted.
- Evidence: where in the package the condition was found. Values that look like credentials are masked.
- Remediation: the specific setting, API or configuration to change.
- Standards: the MASVS controls (current and legacy identifiers), the CWE, the OWASP Mobile Top 10 slot, and the MASTG procedure to reproduce the result by hand.
The MASTG procedure is worth calling out. Every finding tells a tester how to confirm or refute it manually, which is what an external penetration test report has to be able to do.
Severity, risk score and grade
Severity describes the class of problem. The risk score, 0 to 100, describes this problem in this application, and it is what the list sorts by. It accounts for:
- how an attacker reaches the weakness,
- how the package is distributed,
- what the application is built with, since a value inside a JavaScript bundle is easier to reach than one inside compiled native code,
- how confident the check is,
- anything in the package that already mitigates it.
The package receives a letter grade from A to F, driven by the highest finding with a bounded contribution from the rest. A long tail of informational findings cannot move the grade on its own.
The scoring model is published inside every report, so a reviewer can reproduce any score rather than take it on trust.
Findings, and where they go
Findings above informational are promoted into the platform Findings workflow, with an owner, an SLA, a status and an audit trail, alongside your web and API results. Vulnerable-component findings are promoted under the existing component category so they sit with the rest of your supply chain work.
A finding is identified by the application it belongs to, not by the file you uploaded. The same weakness in version 4.1 and version 4.2 is the same row, so fixing it resolves it and reintroducing it reopens it.
Software bill of materials
Every assessment produces a CycloneDX 1.5 SBOM for the shipped artefact, downloadable from the report. Components are matched against the same advisory corpus used by Supply Chain Intel, including the CISA KEV catalog.
A component whose exact version cannot be recovered from the package appears in the SBOM but is excluded from advisory matching. The report states how many components fell into that group, so the supply chain result is read as the lower bound it is.
Comparing two releases
Mobile Security → Compare versions puts two assessments side by side and reports:
- findings introduced by the newer build,
- findings resolved since the older one,
- findings carried forward unchanged,
- findings whose severity moved,
- dependencies added, removed or upgraded.
The comparison warns you when the two assessments are not really comparable, for example when they are different applications or were produced by different engine versions.
Accuracy
Mobile static analysis is prone to attributing a bundled library's own content to the application. A cryptographic provider ships a catalogue of every algorithm it supports; a networking library references certificate validation because it implements it correctly. Reported naively, both produce findings that are wrong.
WASViking evaluates where the evidence came from before scoring it. Findings that belong to a bundled dependency rather than to your code are downgraded or set aside, with the reason recorded on the finding and listed in the report. Nothing is removed silently, so you can review the judgement instead of trusting it.
Exports
| Export | Contents |
|---|---|
| CSV | One row per finding, with severity, risk score, attack path, standards mapping and remediation. Built for a remediation backlog. |
| JSON | The complete report, in a versioned contract. |
| CycloneDX | The SBOM on its own. |
| Package | The artefact you uploaded, while it is still retained. |
Retention
Two horizons, because the two artefacts carry different sensitivity.
| Artefact | Default | Note |
|---|---|---|
| Uploaded package | Purged on the shorter horizon | It is your intellectual property and frequently carries production credentials, so it is not kept longer than the analysis needs. |
| Assessment report | Kept for the full retention window | Trend and version comparison depend on it. |
Both horizons are set per organization. An assessment can be placed under legal hold, which exempts it from retention until the hold is released. Applying a hold requires a written justification and is recorded in the audit log.
What it does NOT do
- No dynamic analysis. The application is not installed, launched, instrumented or driven on a device or emulator. Findings that require runtime observation are outside the current scope.
- No source code required, and none inferred. The assessment reads the compiled artefact. Where a result needs a human to confirm a call site, the finding says so and gives the procedure.
- No store submission. WASViking assesses the package; publishing remains yours.
- No modification of your artefact. The uploaded package is read, never rewritten or repackaged.
Where it lives in the portal
- Mobile Security → Assessments: upload, history, and the application portfolio.
- Mobile Security → Rule catalogue: every check the engine runs, with its severity and standards mapping. Readable before you upload anything.
- Findings: mobile results in the shared remediation workflow.
- Settings → Usage: assessments consumed in the current period.
In your pipeline
Assessments do not have to start in the portal. The WASViking Sentinel submits the package your build produces straight from CI/CD, fails the build on new findings with a baseline diff, and publishes SARIF to the GitHub Security tab. Pipeline runs land in the same history, tagged with a CI badge. See CI/CD Mobile Security with GitHub Actions and the command reference at wasviking-sentinel mobile.
Set up
Mobile Security Assessment is enabled per organization. If Mobile Security appears in your sidebar but the page shows a locked panel, the module is not enabled for your organization yet; contact your account team. Once it is enabled there is nothing to configure, upload your first package and the assessment runs.
See Activate your modules for the full activation checklist.