wasviking-sentinel mobile
Submit an Android or iOS application package from any pipeline for a static assessment against OWASP MASVS and MASTG, with a baseline diff and deterministic exit codes.
wasviking-sentinel mobile submits a compiled application package to the
WASViking® Mobile Security Assessment, waits for the verdict,
writes SARIF and JSON, and fails the build on findings above a threshold you
choose. It is the file-based counterpart of the cloud scan: there is no
mTLS tunnel and no running app to reach, because the artefact is the input.
For a full GitHub Actions walkthrough, see CI/CD Mobile Security with GitHub Actions. This page is the command reference for any pipeline.
Supported packages
| Format | Platform |
|---|---|
.apk |
Android |
.aab |
Android App Bundle |
.xapk, .apks |
Android split-package containers |
.ipa |
iOS |
The format is decided by reading the container, not the file extension. A file that is not a recognised application package is refused at upload.
License check (preflight)
Before any work, mobile calls the WASViking preflight endpoint to confirm
the organization API key is active.
--api-key(or envWASV_API_KEY) is required.- The check is
POST /api/v1/sentinel/preflight. Any active org API key passes. - The result is cached briefly on disk, so repeated runs skip the network.
- A short WASViking outage does not break your pipeline, but an actively rejected key (401 / 403) blocks immediately.
Scope
The API key needs the mobile:scan scope. The same key also downloads
the agent from install.sh, so a mobile-only pipeline does not need any
other scope.
How it runs
- The agent asks the API to authorise one upload and receives a short-lived, single-purpose authorisation for one object.
- The package is uploaded straight to secure object storage. The bytes do not pass through the API or a CDN, so package size is not capped by a proxy.
- The API verifies the stored object, confirms it is a real application package, and queues the assessment.
- The agent polls until the assessment reaches a terminal state, then pulls the SARIF.
Basic usage
export WASV_API_KEY="wv_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
wasviking-sentinel mobile --file app-release.apk
Two files are written into --out (default .):
wasviking-mobile.sarif: SARIF 2.1.0, for GitHub Code Scanning, GitLab, and any SARIF-aware tooling.wasviking-mobile.json: the run summary with severity counts, risk score, and build provenance.
Flags
| Flag | Required | Description |
|---|---|---|
--file |
Yes | Path to the application package. |
--api-key |
Yes | API Key with mobile:scan. Prefer env WASV_API_KEY. |
--label |
No | Label stored with the assessment (release name, commit). |
--fail-on |
No | critical, high, medium, low, or none. "Or above" logic. Default: critical. |
--baseline |
No | new (only findings absent from the previous assessment of the same app) or all. Default: all. |
--out |
No | Output directory. Default: current directory. |
--timeout |
No | Budget for upload plus analysis. Default: 40m. |
--api |
No | API base URL. Default: https://api.wasviking.com (env WASV_API). |
Baseline diff
The baseline is the previous completed assessment of the same application
(same platform and package identifier), from a pipeline or a manual upload.
The comparison is by finding identity, so a version bump does not reset it.
With --baseline new, the build fails only on findings the release
introduces, which keeps pull requests free of friction from inherited debt.
The SARIF marks each result as new, existing, or fixed.
Exit codes
| Code | Meaning |
|---|---|
0 |
Nothing at or above the threshold (given the baseline). |
1 |
Findings exceed the threshold. Blocks the merge. |
2 |
Operational error (missing package, bad arguments, auth or upload failure). |
Build provenance
The command reads the standard CI environment variables and records the provider, repository, branch, commit, run, and actor with the assessment, with no extra flags. GitHub Actions, GitLab CI, Bitbucket Pipelines, and CircleCI are recognised automatically. The portal shows this next to the run, tagged with a CI badge, and the same context rides in the SARIF.
Where results land
Pipeline assessments appear alongside manual uploads under Mobile Security → Assessments. The capability itself is documented at Mobile Security Assessment.