CI/CD Mobile Security with GitHub Actions

Assess the Android or iOS package your build produces inside your GitHub Actions pipeline with the WASViking Sentinel. Uploads the artefact over HTTPS, runs the static assessment against OWASP MASVS and MASTG, fails the build on new findings with a baseline diff, and publishes results to the GitHub Security tab.

This integration submits the mobile application package your build produces to the WASViking^® Mobile Security Assessment, from inside your GitHub Actions runner, and fails the pipeline when the release carries findings you care about. The package is analysed statically against the OWASP Mobile Application Security Verification Standard (MASVS) and the Mobile Application Security Testing Guide (MASTG). Nothing is installed on a device and nothing is executed.

Unlike the DAST flow, there is no mTLS tunnel and no running app to reach: the artefact is a file. The runner uploads it straight to secure object storage with a single-purpose authorisation, so the bytes never pass through the API, and the assessment runs on the same engine the portal uses.

The setup is short. You need one thing in the portal (an API Key scoped to mobile:scan) and one thing in GitHub Actions (that key as a secret). The same key installs the agent and runs the assessment, so there is no separate agent token to manage.

What this integration does

• Assesses the .apk, .aab, or .ipa your pipeline builds, on every push or pull request.
• Fails the build by severity with --fail-on, so a release that regresses is blocked before merge.
• Compares against the previous assessment of the same application with --baseline new, so a build only fails on findings it introduces, not on pre-existing debt.
• Emits SARIF 2.1.0, consumed natively by GitHub Code Scanning, plus a full JSON summary.
• Records who built what: the pipeline stamps the provider, repository, branch, commit, and run so every assessment is traceable to a build.
• Meters against your monthly CI mobile assessment allowance and lists every run in the portal, tagged as a pipeline submission.

How it works

1. The runner installs the Sentinel agent using your mobile:scan key.
2. The agent asks the API to authorise one upload and receives a short-lived, single-purpose authorisation for one object.
3. The agent uploads the package straight to secure object storage. The bytes do not pass through the API or the CDN.
4. The API verifies the stored object, confirms it is a real application package, and queues the assessment against your organization.
5. The engine runs its checks (configuration, transport security, cryptography, local storage, platform interaction, binary hardening, third-party components, embedded credentials, and tracking SDKs) and scores the result.
6. The agent writes wasviking-mobile.sarif and wasviking-mobile.json, and the workflow uploads the SARIF to GitHub Code Scanning.

Access posture

• Only the application package you name with --file is uploaded. No source code, no runner environment variables beyond the key you pass, and no files outside the working directory are collected.
• The upload authorisation is single-purpose and short-lived, and pins the exact object; a tampered authorisation is refused.
• Submission is HTTPS with an API Key. WASViking authenticates with the Authorization: ApiKey <key> header, not Bearer.
• Revoke access at any time by revoking the API Key in the portal.

Pre-requisites

Not on GitHub Actions? The same gate runs on any CI system where the wasviking-sentinel binary can execute. See wasviking-sentinel mobile.

Step 1: Create an API Key scoped to mobile:scan (portal)

This one key both downloads the agent and runs the assessment.

Go to Settings → System Settings → API Keys and click + New Key.

Save and copy the key once. You will paste it into GitHub in Step 2 as WASV_MOBILE_API_KEY.

You can review or adjust a key's scopes later with Edit on the key row. Editing scopes keeps the same key value, so the pipeline keeps working without re-issuing the secret.

Step 2: Add the GitHub secret

Never commit a key to the repository. Store it as an encrypted Actions secret.

In GitHub, go to the repository's Settings → Secrets and variables → Actions → Secrets and add:

Use Secrets (encrypted), never Variables, for the key. For multiple environments (staging, production), prefer Environment secrets with required reviewers and deployment protection rules.

Step 3: Add the workflow

Create .github/workflows/wasviking-mobile.yml. The example builds an Android APK; replace the Build the app step with however your project produces its package, and point --file at the artefact.

name: WASViking Mobile Security

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read
  security-events: write
  actions: read

jobs:
  mobile-assessment:
    runs-on: ubuntu-latest
    timeout-minutes: 45
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # Replace with your own build. The result must be an .apk, .aab,
      # .xapk, .apks, or .ipa on disk.
      - name: Build the app
        run: ./gradlew assembleRelease

      - name: Install WASViking Sentinel
        env:
          WASV_MOBILE_API_KEY: ${{ secrets.WASV_MOBILE_API_KEY }}
        run: |
          curl -sSL -H "Authorization: ApiKey $WASV_MOBILE_API_KEY" \
            https://api.wasviking.com/api/v1/sentinel/install.sh | sh

      - name: Run WASViking mobile assessment
        env:
          WASV_API_KEY: ${{ secrets.WASV_MOBILE_API_KEY }}
        run: |
          mkdir -p wasviking-reports
          ./.wasviking/wasviking-sentinel mobile \
            --file app/build/outputs/apk/release/app-release.apk \
            --label "${{ github.repository }}@${{ github.sha }}" \
            --fail-on high \
            --baseline new \
            --out ./wasviking-reports

      - name: Upload SARIF to GitHub code scanning
        if: always() && hashFiles('wasviking-reports/wasviking-mobile.sarif') != ''
        uses: github/codeql-action/upload-sarif@v4
        with:
          sarif_file: wasviking-reports/wasviking-mobile.sarif
          category: wasviking-mobile

      - name: Upload raw reports as artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: wasviking-mobile-reports
          path: wasviking-reports/

The assessment command reads the key from WASV_API_KEY, so you do not have to repeat --api-key on the command line. Code Scanning upload (the SARIF step) requires GitHub Advanced Security on private repositories. If you do not have it, drop that step and rely on the uploaded artifact and the portal instead.

Step 4: Command flags

wasviking-sentinel mobile [flags]

Two files are produced:

• wasviking-mobile.sarif: SARIF 2.1.0 (GitHub Code Scanning, GitLab, and others).
• wasviking-mobile.json: the run summary with severity counts, risk score, and provenance.

Exit codes

Fail-on policy

--fail-on sets the lowest severity that fails the build, and everything above it also fails.

A practical rollout: start at critical to keep early friction low, then tighten to high once your baseline is clean.

Baseline diff

--baseline controls what counts toward the fail-on policy. The baseline is the previous completed assessment of the same application (same platform and package identifier), whether that earlier run came from a pipeline or a manual upload in the portal. The comparison is by finding identity, so a version bump does not reset it.

On the first assessment of an application there is nothing to compare against, so new gates on the full set for that run and establishes the baseline for the next one. The SARIF marks each result as new, existing, or fixed, and lists what a release repaired since the baseline.

Build provenance

The pipeline reads the standard CI environment variables and records the provider, repository, branch, commit, run identifier, and actor with the assessment, with no extra flags. The portal shows this next to the run, and the same context rides in the SARIF document, so a finding on a pull request is traceable to the exact build that produced it. GitHub Actions, GitLab CI, Bitbucket Pipelines, and CircleCI are recognised automatically.

What is and isn't collected

WASViking does not collect your repository source code, runner environment variables beyond the key you pass, runner filesystem contents outside the working directory, or any production data. Only the application package you name is uploaded. Embedded secret values found during analysis are stored redacted, never in the clear. Data is processed in the US region, encrypted in transit (TLS 1.2+) and at rest (AES-256), with retention set by your plan. A DPA and EU data residency are available on request; see the Trust Center for the full compliance mapping (ISO 27001, SOC 2, LGPD, GDPR, OWASP MASVS, OWASP MASTG, NIST SSDF, OWASP DSOMM).

Common problems

Where this fits in the platform

• Pipeline assessments appear alongside manual uploads under Mobile Security → Assessments, tagged with a CI badge.
• The capability itself is documented at Mobile Security Assessment.
• The DAST counterpart is CI/CD DAST with GitHub Actions; the dependency and secrets counterpart is CI/CD SCA, SBOM & Secrets.