Mobile Security no CI/CD com GitHub Actions

Avalie o pacote Android ou iOS que o seu build produz dentro do seu pipeline do GitHub Actions com o WASViking Sentinel. Envia o artefato por HTTPS, executa a avaliação estática com base no OWASP MASVS e no MASTG, faz o build falhar quando há novos achados usando um diff de baseline e publica os resultados na aba Security do GitHub.

Esta integração envia o pacote do aplicativo móvel que o seu build produz para o WASViking^® Mobile Security Assessment, de dentro do seu runner do GitHub Actions, e faz o pipeline falhar quando a release traz achados que importam para você. O pacote é analisado estaticamente com base no OWASP Mobile Application Security Verification Standard (MASVS) e no Mobile Application Security Testing Guide (MASTG). Nada é instalado em um dispositivo e nada é executado.

Diferentemente do fluxo de DAST, não há túnel mTLS nem aplicação em execução para alcançar: o artefato é um arquivo. O runner o envia direto para um armazenamento de objetos seguro, com uma autorização de propósito único, de modo que os bytes nunca passam pela API, e a avaliação roda no mesmo motor que o portal usa.

A configuração é curta. Você precisa de uma coisa no portal (uma chave de API com o escopo mobile:scan) e de uma coisa no GitHub Actions (essa chave como secret). A mesma chave instala o agente e executa a avaliação, então não há um token de agente separado para gerenciar.

O que esta integração faz

• Avalia o .apk, .aab ou .ipa que o seu pipeline gera, a cada push ou pull request.
• Faz o build falhar por severidade com --fail-on, de modo que uma release que regride é bloqueada antes do merge.
• Compara com a avaliação anterior do mesmo aplicativo usando --baseline new, de modo que um build só falha pelos achados que ele introduz, não pela dívida preexistente.
• Emite SARIF 2.1.0, consumido nativamente pelo GitHub Code Scanning, além de um resumo completo em JSON.
• Registra quem gerou o quê: o pipeline anota o provedor, o repositório, a branch, o commit e a execução, para que toda avaliação seja rastreável até um build.
• Desconta da sua franquia mensal de avaliações mobile em CI e lista cada execução no portal, marcada como um envio de pipeline.

Como funciona

1. O runner instala o agente Sentinel usando a sua chave mobile:scan.
2. O agente pede à API que autorize um upload e recebe uma autorização de curta duração e propósito único, válida para um objeto.
3. O agente envia o pacote direto para o armazenamento de objetos seguro. Os bytes não passam pela API nem pela CDN.
4. A API verifica o objeto armazenado, confirma que ele é um pacote de aplicativo real e enfileira a avaliação para a sua organização.
5. O motor executa as suas verificações (configuração, segurança de transporte, criptografia, armazenamento local, interação com a plataforma, hardening do binário, componentes de terceiros, credenciais embutidas e SDKs de rastreamento) e pontua o resultado.
6. O agente grava wasviking-mobile.sarif e wasviking-mobile.json, e o workflow envia o SARIF para o GitHub Code Scanning.

Postura de acesso

• Apenas o pacote do aplicativo que você indica com --file é enviado. Nenhum código-fonte, nenhuma variável de ambiente do runner além da chave que você passa e nenhum arquivo fora do diretório de trabalho são coletados.
• A autorização de upload é de propósito único e curta duração, e fixa o objeto exato; uma autorização adulterada é recusada.
• O envio é feito por HTTPS com uma chave de API. A WASViking autentica com o header Authorization: ApiKey <key>, não com Bearer.
• Revogue o acesso a qualquer momento revogando a chave de API no portal.

Pré-requisitos

Não usa GitHub Actions? O mesmo gate roda em qualquer sistema de CI em que o binário wasviking-sentinel possa ser executado. Veja wasviking-sentinel mobile.

Passo 1: Crie uma chave de API com o escopo mobile:scan (portal)

Esta única chave tanto baixa o agente quanto executa a avaliação.

Vá em Settings → System Settings → API Keys e clique em + New Key (nova chave).

Salve e copie a chave uma única vez. Você vai colá-la no GitHub no Passo 2 como WASV_MOBILE_API_KEY.

Você pode revisar ou ajustar os escopos de uma chave depois, em Edit, na linha da chave. Editar os escopos mantém o mesmo valor da chave, então o pipeline continua funcionando sem que o secret precise ser emitido de novo.

Passo 2: Adicione o secret no GitHub

Nunca faça commit de uma chave no repositório. Guarde-a como um secret criptografado do Actions.

No GitHub, vá em Settings → Secrets and variables → Actions → Secrets do repositório e adicione:

Use Secrets (criptografados), nunca Variables, para a chave. Para vários ambientes (staging, produção), prefira Environment secrets com revisores obrigatórios e regras de proteção de implantação.

Passo 3: Adicione o workflow

Crie .github/workflows/wasviking-mobile.yml. O exemplo gera um APK Android; substitua o passo Build the app pela forma como o seu projeto produz o pacote e aponte --file para o artefato.

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/

O comando de avaliação lê a chave de WASV_API_KEY, então você não precisa repetir --api-key na linha de comando. O upload para o Code Scanning (o passo do SARIF) exige o GitHub Advanced Security em repositórios privados. Se você não tem esse recurso, remova esse passo e use o artefato enviado e o portal no lugar dele.

Passo 4: Flags do comando

wasviking-sentinel mobile [flags]

Dois arquivos são produzidos:

• wasviking-mobile.sarif: SARIF 2.1.0 (GitHub Code Scanning, GitLab e outros).
• wasviking-mobile.json: o resumo da execução, com contagens por severidade, pontuação de risco e procedência.

Exit codes

Política de fail-on

--fail-on define a menor severidade que faz o build falhar, e tudo o que está acima dela também falha.

Um rollout prático: comece em critical para manter o atrito inicial baixo e depois aperte para high quando a sua baseline estiver limpa.

Diff de baseline

--baseline controla o que conta para a política de fail-on. A baseline é a avaliação concluída anterior do mesmo aplicativo (mesma plataforma e mesmo identificador de pacote), quer essa execução anterior tenha vindo de um pipeline, quer de um upload manual no portal. A comparação é feita pela identidade do achado, então um aumento de versão não a reinicia.

Na primeira avaliação de um aplicativo não há nada com que comparar, então new aplica o gate sobre o conjunto completo nessa execução e estabelece a baseline para a próxima. O SARIF marca cada resultado como novo, existente ou corrigido e lista o que uma release reparou desde a baseline.

Procedência do build

O pipeline lê as variáveis de ambiente padrão do CI e registra, junto com a avaliação, o provedor, o repositório, a branch, o commit, o identificador da execução e o autor, sem flags adicionais. O portal mostra isso ao lado da execução, e o mesmo contexto segue no documento SARIF, de modo que um achado em um pull request é rastreável até o build exato que o produziu. GitHub Actions, GitLab CI, Bitbucket Pipelines e CircleCI são reconhecidos automaticamente.

O que é e o que não é coletado

A WASViking não coleta o código-fonte do seu repositório, variáveis de ambiente do runner além da chave que você passa, conteúdo do sistema de arquivos do runner fora do diretório de trabalho nem qualquer dado de produção. Apenas o pacote do aplicativo que você indica é enviado. Os valores de secrets embutidos encontrados durante a análise são armazenados mascarados, nunca em texto claro. Os dados são processados na região dos Estados Unidos, criptografados em trânsito (TLS 1.2+) e em repouso (AES-256), com retenção definida pelo seu plano. Um DPA e a residência de dados na União Europeia estão disponíveis sob solicitação; veja o Trust Center para o mapeamento completo de conformidade (ISO 27001, SOC 2, LGPD, GDPR, OWASP MASVS, OWASP MASTG, NIST SSDF, OWASP DSOMM).

Problemas comuns

Onde isto se encaixa na plataforma

• As avaliações de pipeline aparecem ao lado dos uploads manuais em Mobile Security → Assessments, marcadas com um selo CI.
• A capacidade em si está documentada em Mobile Security Assessment.
• O equivalente para DAST é DAST no CI/CD com GitHub Actions; o equivalente para dependências e secrets é SCA, SBOM e secrets no CI/CD.