A sua release mobile é um binário nas mãos de todos que a instalam.
Envie um pacote Android ou iOS e receba uma avaliação estática completa com base no OWASP Mobile Application Security Verification Standard: configuração, transporte, criptografia, armazenamento, interação com a plataforma, hardening do binário, componentes de terceiros e secrets embutidos. Os achados entram no mesmo fluxo de trabalho que a sua equipe já usa para os resultados de web e API.
Não é possível corrigir uma release mobile pelo lado do servidor.
Uma correção web é publicada em minutos. Uma correção mobile passa por um build, por uma revisão da loja e por uma atualização do usuário, e a versão antiga continua instalada nos dispositivos por meses. Tudo o que o pacote carrega, incluindo as chaves e os endpoints dentro dele, pode ser lido por qualquer pessoa que o baixe.
Isso muda o que importa. Uma credencial hardcoded em um binário mobile já está divulgada. Um endpoint em texto claro já está acessível. Um componente exportado já pode ser chamado por qualquer outro app no dispositivo. O Mobile Security Assessment encontra essas condições antes que a release saia do seu sistema de build e explica com clareza como um atacante chegaria a cada uma delas.
[package] com.acme.banking 4.2.0 (build 4200), Android
[signing] v1 + v2 + v3, RSA 2048, expires 2039-11-04
[sbom] 114 components, 106 with a resolved version
[finding] transport: cleartext permitted for 2 domains
[finding] storage: credentials in unencrypted preferences
→ mapeado a MASVS, MASTG, CWE e OWASP Mobile Top 10
→ promovido a Findings com responsável, SLA e trilha de auditoria
Mais de 200 verificações, em todos os grupos do MASVS.
O pacote é desmontado e analisado como um todo: manifesto e property lists, código compilado, bibliotecas nativas, material de assinatura, assets empacotados e todos os recursos que o acompanham. Nada é inferido a partir do nome do arquivo.
Configuração e exposição na plataforma
Builds depuráveis, exposição de backup, componentes acessíveis por qualquer outro app no dispositivo, deep links sem verificação de domínio e esquemas de URL que qualquer app pode reivindicar. A exposição é derivada de como a plataforma de fato a resolve, não de um único atributo.
Segurança de transporte
Política de tráfego em texto claro, confiança em certificados instalados pelo usuário, overrides de debug enviados para produção, certificate pinning e exceções do App Transport Security no iOS. Cada endpoint que o pacote carrega é inventariado e sinalizado quando é HTTP simples.
Criptografia e tratamento de chaves
Algoritmos quebrados e retirados, modos de bloco que vazam estrutura, fontes aleatórias previsíveis, material de chave que nunca chega a um armazenamento protegido por hardware e itens de keychain vinculados de forma mais frouxa do que os dados exigem.
Armazenamento de dados e privacidade
Credenciais em preferências desprotegidas, bancos de dados locais sem criptografia, arquivos de credenciais e de banco de dados distribuídos dentro do pacote e o inventário de SDKs de terceiros para coleta de dados e session replay que a release carrega.
Hardening do binário e resiliência
Independência de posição, proteção de pilha, contagem automática de referências, imports sem segurança de memória, cobertura do esquema de assinatura, canal de provisionamento e se o build faz alguma tentativa de perceber um dispositivo com root, um depurador anexado ou uma cópia reempacotada de si mesmo.
Componentes e secrets embutidos
Uma lista de materiais de software em CycloneDX recuperada do artefato distribuído, comparada com os boletins de segurança publicados e com o catálogo CISA KEV, além da detecção, ancorada no provedor, de material de credenciais embutido no pacote.
Um achado sobre o qual os seus engenheiros possam agir, ou ele não pertence ao relatório.
A análise estática mobile tem fama de produzir listas longas que ninguém lê. O motivo é quase sempre o mesmo: o conteúdo próprio de uma biblioteca de terceiros acaba atribuído à aplicação. A WASViking trata isso como um problema de engenharia, não como um custo aceitável.
O conteúdo da biblioteca é atribuído à biblioteca
Evidências que pertencem a uma dependência empacotada, e não ao seu código, são rebaixadas e rotuladas como tal, com o motivo declarado no achado. Nada é escondido: cada ajuste é listado no relatório para que um revisor possa discordar dele.
Versões são recuperadas, nunca adivinhadas
Um componente cuja versão exata não pode ser recuperada do artefato aparece na lista de materiais, mas é excluído da correlação com boletins de segurança. Uma CVE que não pode ser confirmada é pior do que nenhuma CVE.
Cada pontuação se explica
Cada achado traz o caminho de ataque, o que um atacante precisa ter antes de conseguir usá-lo e as entradas que produziram a sua pontuação de risco. O modelo de pontuação acompanha o relatório, então o número pode ser revisado, e não apenas afirmado.
Confiança na release e as evidências para comprová-la.
O mobile é onde dados regulados encontram um dispositivo não controlado. Avaliar cada release transforma isso de um achado do teste de intrusão anual em uma resposta no momento do build.
Controle de regressão entre releases
Duas releases são comparadas pela identidade dos achados, não pelo texto do relatório. A equipe vê o que o build corrigiu, o que introduziu, o que manteve e quais dependências mudaram. Essa é a conversa de que uma revisão de release precisa.
Declarações de loja e de privacidade que se sustentam
O inventário de rastreadores e permissões é aquilo a que o seu aviso de privacidade e a declaração de segurança de dados da loja precisam corresponder. Uma divergência é, por si só, uma exposição regulatória, independente de qualquer vulnerabilidade técnica.
Evidências de auditoria no mesmo lugar que o restante
Os achados mobile entram no mesmo fluxo de trabalho dos resultados de web e API: responsável, severidade, SLA, trilha de auditoria e exportação. Um único registro de riscos, não um PDF separado que envelhece no dia em que é escrito.
Mapeado ao padrão que o seu auditor mobile já usa.
Cada achado traz o seu controle OWASP MASVS, o procedimento de verificação MASTG correspondente, um CWE e a sua classificação no OWASP Mobile Top 10. Relatórios que ainda referenciam a geração anterior do MASVS são suportados: os identificadores de requisitos legados acompanham os atuais.
| Framework | Controle | Com o que o Mobile Security Assessment contribui |
|---|---|---|
| OWASP MASVS v2 | Storage, Crypto, Auth, Network, Platform, Code, Resilience, Privacy | Verificação por release em todos os oito grupos de controle, com o procedimento MASTG para reproduzir cada resultado manualmente |
| PCI DSS v4.0 | Req 6.2.4 técnicas de engenharia de software · Req 6.3.2 inventário de componentes sob medida e de terceiros | Evidências por release de que as classes comuns de ataque mobile foram testadas, além de um inventário de componentes gerado a partir do artefato distribuído |
| ISO 27001:2022 | Anexo A.8.24 uso de criptografia · A.8.26 requisitos de segurança de aplicações · A.8.28 codificação segura | Registro por release do uso de criptografia, dos resultados da verificação de segurança da aplicação e das condições de código encontradas no build |
| NIST CSF 2.0 | PR.PS-06, práticas seguras de desenvolvimento de software são integradas | Avaliação pré-release repetível, com um registro durável para cada versão, comparável entre releases |
| LGPD · GDPR | Artigo 46 · Artigo 32, medidas técnicas | Evidências de proteção de transporte e de armazenamento no cliente, além do inventário de coleta de dados por terceiros que acompanha a release |