Mobile Security Assessment

Avaliação estática de segurança de pacotes de aplicativos Android e iOS com base no OWASP Mobile Application Security Verification Standard, com SBOM, pontuação de risco contextual e comparação entre releases.

O WASViking^® Mobile Security Assessment analisa um pacote compilado de aplicativo Android ou iOS e reporta o que ele expõe. A avaliação cobre configuração, segurança de transporte, criptografia, armazenamento local de dados, interação com a plataforma, hardening do binário, componentes de terceiros, material de credenciais embutido e os SDKs de coleta de dados que acompanham a release.

A avaliação é estática. Nada é instalado, nada é executado e nenhum dispositivo é necessário. Você envia o artefato que o seu sistema de build produziu e lê o resultado.

Esta é a seção do portal em Mobile Security → Assessments.

O que você pode enviar

O formato é decidido pela leitura do contêiner, não pela extensão do arquivo. Um pacote que não é um aplicativo móvel é recusado no upload, com o motivo.

Os uploads são limitados a 600 MB. Se o seu artefato for maior do que isso, entre em contato com o suporte antes da janela de avaliação.

Executando uma avaliação

1. Abra Mobile Security → Assessments e escolha Analyse a package (analisar um pacote).
2. Arraste o arquivo ou procure por ele.
3. Opcionalmente, adicione um Label (rótulo). Use o nome da release ou a referência do ticket; é o que você vai procurar depois, ao comparar versões.
4. Inicie a avaliação.

O progresso é mostrado ao vivo durante a execução, etapa por etapa. Um pacote típico é concluído em menos de um minuto. Pacotes grandes, com muitas dependências, levam mais tempo.

Você precisa da permissão Upload no recurso Mobile Security. Veja Convidando a sua equipe para a matriz de papéis.

Lendo o relatório

O relatório abre em Overview e é organizado em abas.

O painel de detalhes do achado

Cada achado traz:

• O que é e a capacidade concreta que ele dá a um atacante.
• Por que importa aqui: o caminho de ataque e o que um atacante precisa ter antes de poder usá-lo. "Qualquer pessoa que baixe o aplicativo" e "um dispositivo com root que o atacante já controla" são respostas muito diferentes, e o painel diz qual delas se aplica.
• Pontuação de risco com as entradas que a produziram, descritas por extenso em vez de apenas afirmadas.
• Evidência: onde, no pacote, a condição foi encontrada. Valores que parecem credenciais são mascarados.
• Remediação: a configuração, a API ou o ajuste específico a alterar.
• Padrões: os controles do MASVS (identificadores atuais e legados), o CWE, o item do OWASP Mobile Top 10 e o procedimento do MASTG para reproduzir o resultado manualmente.

O procedimento do MASTG merece destaque. Todo achado diz a um testador como confirmá-lo ou refutá-lo manualmente, que é o que um relatório de teste de intrusão externo precisa ser capaz de fazer.

Severidade, pontuação de risco e nota

A severidade descreve a classe do problema. A pontuação de risco, de 0 a 100, descreve este problema nesta aplicação, e é por ela que a lista é ordenada. Ela leva em conta:

• como um atacante alcança a fraqueza,
• como o pacote é distribuído,
• com o que a aplicação é construída, já que um valor dentro de um bundle JavaScript é mais fácil de alcançar do que um dentro de código nativo compilado,
• o grau de confiança da verificação,
• qualquer coisa no pacote que já mitigue o problema.

O pacote recebe uma nota em letra, de A a F, determinada pelo achado mais grave, com uma contribuição limitada dos demais. Uma cauda longa de achados informativos não consegue mover a nota sozinha.

O modelo de pontuação é publicado dentro de cada relatório, para que um revisor possa reproduzir qualquer pontuação em vez de aceitá-la por confiança.

Achados e para onde eles vão

Os achados acima de informativo são promovidos ao fluxo de trabalho de Findings da plataforma, com responsável, SLA, status e trilha de auditoria, ao lado dos seus resultados web e de API. Os achados de componentes vulneráveis são promovidos na categoria de componentes já existente, para que fiquem junto com o restante do seu trabalho de cadeia de suprimentos.

Um achado é identificado pela aplicação a que pertence, não pelo arquivo que você enviou. A mesma fraqueza na versão 4.1 e na versão 4.2 é a mesma linha, então corrigi-la a resolve e reintroduzi-la a reabre.

Lista de materiais de software (SBOM)

Toda avaliação produz um SBOM CycloneDX 1.5 do artefato entregue, disponível para download no relatório. Os componentes são comparados com a mesma base de boletins de segurança usada pelo Supply Chain Intel, incluindo o catálogo CISA KEV.

Um componente cuja versão exata não pode ser recuperada do pacote aparece no SBOM, mas fica fora da correspondência com boletins de segurança. O relatório informa quantos componentes caíram nesse grupo, para que o resultado de cadeia de suprimentos seja lido como o limite inferior que ele é.

Comparando duas releases

Mobile Security → Compare versions coloca duas avaliações lado a lado e reporta:

• achados introduzidos pelo build mais novo,
• achados resolvidos desde o mais antigo,
• achados mantidos sem alteração,
• achados cuja severidade mudou,
• dependências adicionadas, removidas ou atualizadas.

A comparação avisa quando as duas avaliações não são de fato comparáveis, por exemplo quando são aplicações diferentes ou foram produzidas por versões diferentes do motor.

Precisão

A análise estática mobile tende a atribuir à aplicação o conteúdo próprio de uma biblioteca empacotada com ela. Um provedor criptográfico traz um catálogo de todos os algoritmos que suporta; uma biblioteca de rede faz referência à validação de certificados porque a implementa corretamente. Reportados de forma ingênua, ambos produzem achados que estão errados.

A WASViking avalia de onde a evidência veio antes de pontuá-la. Os achados que pertencem a uma dependência empacotada, e não ao seu código, são rebaixados ou deixados de lado, com o motivo registrado no achado e listado no relatório. Nada é removido silenciosamente, então você pode revisar o julgamento em vez de confiar nele.

Exportações

Retenção

Dois horizontes, porque os dois artefatos têm sensibilidades diferentes.

Os dois horizontes são definidos por organização. Uma avaliação pode ser colocada sob legal hold (retenção legal), o que a isenta da retenção até que o hold seja liberado. Aplicar um hold exige uma justificativa por escrito e fica registrado na trilha de auditoria.

O que ele NÃO faz

• Sem análise dinâmica. A aplicação não é instalada, iniciada, instrumentada nem operada em um dispositivo ou emulador. Achados que exigem observação em tempo de execução estão fora do escopo atual.
• Sem exigir código-fonte, e sem inferi-lo. A avaliação lê o artefato compilado. Quando um resultado precisa que uma pessoa confirme um ponto de chamada, o achado diz isso e fornece o procedimento.
• Sem envio à loja. A WASViking avalia o pacote; a publicação continua sendo sua.
• Sem modificação do seu artefato. O pacote enviado é lido, nunca reescrito nem reempacotado.

Onde fica no portal

• Mobile Security → Assessments: upload, histórico e o portfólio de aplicações.
• Mobile Security → Rule catalogue: todas as verificações que o motor executa, com a severidade e o mapeamento para padrões. Pode ser lido antes de você enviar qualquer coisa.
• Findings: resultados mobile no fluxo de trabalho de remediação compartilhado.
• Settings → Usage: avaliações consumidas no período atual.

No seu pipeline

As avaliações não precisam começar no portal. O WASViking Sentinel envia o pacote que o seu build produz direto do CI/CD, faz o build falhar quando há novos achados usando um diff de baseline e publica o SARIF na aba Security do GitHub. As execuções de pipeline caem no mesmo histórico, marcadas com um selo CI. Veja Mobile Security no CI/CD com GitHub Actions e a referência do comando em wasviking-sentinel mobile.

Configuração

O Mobile Security Assessment é habilitado por organização. Se Mobile Security aparece na sua barra lateral, mas a página mostra um painel bloqueado, o módulo ainda não está habilitado para a sua organização; entre em contato com a equipe da sua conta. Depois de habilitado, não há nada para configurar: envie o seu primeiro pacote e a avaliação é executada.

Veja Ative os seus módulos para o checklist completo de ativação.