# Do achado ao relatório: confirmar, classificar e registrar

> Como transformar uma lista de coisas estranhas num relatório de pentest mobile acionável: confirmação, severidade, CVSS e o que fazer depois de registrar.

- Autor: Marcelo Silva
- Publicado em: 2026-10-16
- Tema: Segurança
- Série: Segurança Mobile, parte 11 de 11 (https://marcelxsilva.dev/series/seguranca-mobile/)
- URL: https://marcelxsilva.dev/artigos/do-achado-ao-relatorio/

Todo o trabalho descrito nos artigos anteriores desta série, decompilar, ler o manifesto, revisar código nativo, rodar scanners, instrumentar o app em execução, produz uma coisa só: uma lista de coisas estranhas. Esse último artigo cobre o passo que transforma essa lista em algo útil, um relatório capaz de orientar uma correção.

## Primeiro: confirmar, não só suspeitar

Uma string suspeita, um padrão de scanner, um comportamento inesperado: nenhum desses é, sozinho, um achado. Ele vira achado quando confirmado, e a barra de confirmação muda de acordo com de onde ele veio:

| Origem | Confirmado quando |
|---|---|
| Análise estática | O valor aparece no binário **e** sua origem é localizada no código-fonte |
| Análise dinâmica | O comportamento é reproduzido mais de uma vez, com um passo a passo que outra pessoa consegue seguir e obter o mesmo resultado |
| Scanner automático | Alguém revisou manualmente a saída. Resultado de scanner sozinho, sem essa revisão, não é achado, [como visto no artigo sobre scanners](https://marcelxsilva.dev/artigos/scanners-automaticos/) |

Esse passo evita o problema mais comum de relatórios de segurança malfeitos: uma lista extensa onde metade dos itens é ruído, o que faz quem recebe o relatório perder confiança no restante, inclusive nos achados reais.

## Classificando a severidade

Depois de confirmado, um achado precisa de uma severidade, que comunica o quanto ele é urgente sem exigir que quem lê entenda os detalhes técnicos de cada um:

| Severidade | Quando usar | Exemplo |
|---|---|---|
| Crítica | Acesso à conta ou aos dados de outro usuário, sem que ele precise fazer nada | Uma falha de autorização (IDOR) numa operação sensível |
| Alta | Uma credencial ou chave que dá acesso a um backend ou a um serviço de terceiro | Um client secret de confiança embutido no binário |
| Média | Facilita um ataque ou expõe algo que deveria ficar interno | Endereço de um ambiente de homologação, dado de teste esquecido numa build de produção |
| Baixa | Falta de reforço (hardening), sem um caminho de exploração direto e imediato | Tráfego sem criptografia liberado para um domínio de teste, log verboso demais |
| Informativa | Boa prática ou observação, sem risco de segurança direto | Metadado de build, versão de uma dependência que não tem vulnerabilidade conhecida |

Para precisar essa classificação de forma mais objetiva, principalmente quando o relatório precisa ser comparado com outros ou alimentar um processo formal, o padrão de mercado é o [CVSS (Common Vulnerability Scoring System)](https://www.first.org/cvss/), hoje na versão 3.1, mantido pelo [FIRST](https://www.first.org/). Ele produz uma nota de 0 a 10 a partir de um vetor com métricas (como complexidade do ataque, privilégio exigido, impacto na confidencialidade), que a [calculadora oficial](https://www.first.org/cvss/calculator/3.1) gera automaticamente a partir das respostas.

## Estrutura de um achado

Um relatório de pentest mobile costuma organizar cada achado confirmado com a mesma estrutura, repetida item a item:

```markdown
### <n>. <Título curto do problema>

- **Controle violado:** referência ao padrão de verificação usado (ex.: um grupo do OWASP MASVS)
- **Onde no app:** arquivo, classe ou tela onde o problema aparece
- **Origem no código:** caminho e linha, quando houver acesso ao código-fonte
- **Como reproduzir:** passo a passo objetivo
- **Impacto:** o que um atacante consegue fazer, numa frase
- **Correção:** o que precisa mudar
- **Status:** aberto, em correção ou corrigido (e em qual versão)
```

O campo "onde no app" merece uma ressalva: quando o valor encontrado é, de fato, um segredo (uma chave, um token), ele nunca deveria aparecer completo no relatório. A prática recomendada é mascarar a maior parte do valor, mostrando só os primeiros caracteres (o suficiente para quem corrige confirmar que é o valor certo, sem reproduzir o segredo inteiro num documento que pode circular por e-mail, chat ou um sistema de tickets):

```bash
echo 'CLIENT_SECRET = "a1b2c3d4e5f6..."' | sed -E 's/= "(.{0,6})[^"]*"/= "\1…"/'
```

O mesmo princípio já apareceu no [artigo sobre segredos no binário](https://marcelxsilva.dev/artigos/segredos-no-binario/), aplicado direto na saída do `BuildConfig`.

## De volta ao padrão: os controles do MASVS

O [primeiro artigo desta série](https://marcelxsilva.dev/artigos/o-mapa-da-seguranca-mobile/) descreveu os oito grupos de controle do [OWASP MASVS](https://mas.owasp.org/MASVS/). Fechar o relatório apontando cada achado para o grupo correspondente (`MASVS-STORAGE`, `MASVS-NETWORK`, `MASVS-PLATFORM` e assim por diante) tem uma vantagem prática: transforma uma lista solta de problemas num mapa de cobertura, que permite comparar duas execuções do mesmo app ao longo do tempo e enxergar se um grupo inteiro de controles está sistematicamente mais fraco que os outros.

## Depois de registrado

Registrar o achado não encerra o processo. Três coisas costumam vir em seguida:

1. **Segredo exposto exige rotação, não só correção de código.** Se um valor sensível já foi publicado num binário distribuído, trocar o código não invalida o valor antigo: ele continua funcionando até ser revogado na origem, e o binário antigo continua instalado no aparelho de quem já baixou aquela versão.
2. **Achados Alto e Crítico merecem rastreamento formal**, geralmente um ticket próprio, apontando para o registro detalhado, para que a correção entre no fluxo normal de trabalho do time, em vez de depender de alguém lembrar manualmente.
3. **Reteste fecha o ciclo.** Depois da correção, gerar um novo build e repetir especificamente os passos do achado (não o processo inteiro) confirma se ele realmente foi resolvido, e o status no relatório é atualizado para refletir isso.

## Encerrando a série

Os onze artigos desta série percorreram o caminho de uma análise de segurança mobile completa: o que muda quando o alvo é um app, como a arquitetura do Android e do iOS sustentam (ou não) as garantias que um app depende, como abrir e ler um APK e um IPA, onde segredos costumam vazar, o que o manifesto e o código nativo revelam, o papel (e os limites) dos scanners automáticos, como a análise dinâmica confirma o que a estática só sugere, e como transformar tudo isso num relatório que alguém consegue agir em cima. O padrão que amarra o processo inteiro continua sendo o mesmo descrito no primeiro artigo: o [OWASP MAS](https://mas.owasp.org/), em suas peças que se complementam, do que verificar a como testar.