O que está incluso em um relatório de pentest profissional

Já vi empresa pagar por pentest e receber um PDF gerado por ferramenta automatizada com o logo do fornecedor na capa. Tecnicamente é um "relatório". Na prática, não serve para muita coisa.

Esse é um problema real no mercado. Quem está comprando o serviço pela primeira vez não tem como saber o que deveria estar recebendo — e aí qualquer coisa parece suficiente.

Esse post existe para mudar isso. Se você está avaliando fornecedores ou acabou de receber um relatório e não sabe se o que tem na mão é bom, esse conteúdo vai te ajudar a fazer essa leitura.

Primeiro: um relatório não é o pentest

Antes de falar do documento em si, vale deixar claro: o relatório é o registro do que foi feito, não o pentest em si. Um relatório bom reflete um trabalho bom. Se o teste foi raso, o relatório vai ser raso também — independente de quantas páginas tem.

Dito isso, o relatório é o único entregável concreto que você tem em mãos. É o que vai orientar as correções, servir de evidência para auditorias e justificar o investimento internamente. Então ele precisa ser bom.

O que um relatório profissional deve ter

Sumário executivo

Essa seção é para você, não para o seu time técnico. Deve estar escrita em português claro, sem siglas que precisam de explicação, e responder basicamente três perguntas: o que foi testado, o que foi encontrado e qual é o risco real para o negócio.

Se você é gestor ou CTO e precisa de 20 minutos para entender o sumário executivo, ele foi mal escrito. Essa parte deve ser lida em 5 minutos e deixar claro o que precisa de atenção imediata.

Classificação de criticidade com contexto

Todo relatório tem algum sistema de classificação — crítico, alto, médio, baixo. O problema é quando tudo aparece como crítico, ou quando a classificação não leva em conta o contexto da empresa.

Uma vulnerabilidade num sistema interno acessível só pela VPN tem impacto diferente da mesma vulnerabilidade num endpoint público. Um relatório profissional faz essa distinção. Não é só a severidade técnica — é o risco real considerando como o seu ambiente funciona.

Evidências reais de exploração

Essa é uma das partes que mais diferencia um trabalho manual de um scan automatizado. Para cada vulnerabilidade relevante, deve haver evidência de que ela foi efetivamente explorada — não apenas detectada.

Isso significa capturas de tela, requisições HTTP completas, payloads utilizados, resposta do servidor. Se o relatório diz que tem SQL Injection mas não mostra a query executada nem o dado que foi extraído, você não tem como saber se aquilo é um falso positivo ou uma falha real.

Recomendações que alguém consegue seguir

Recomendação do tipo "implemente autenticação mais robusta" não serve para nada. O desenvolvedor que vai ler isso não sabe o que fazer com essa informação.

Uma boa recomendação especifica o problema, explica por que ele existe e descreve como corrigir — de preferência com referência técnica ou exemplo de implementação. Não precisa resolver o problema pelo cliente, mas precisa apontar um caminho claro.

Separação entre visão executiva e visão técnica

Esses são dois públicos diferentes com necessidades diferentes. O diretor financeiro que vai aprovar o orçamento de correção não precisa saber o que é um IDOR. O desenvolvedor que vai implementar o fix não precisa ler quatro páginas de contexto de negócio.

Um relatório bem estruturado separa essas duas camadas. Você consegue compartilhar a parte executiva com a diretoria e a parte técnica com a equipe de desenvolvimento sem precisar editar nada.

Escopo e metodologia documentados

O relatório deve deixar claro o que foi testado e o que ficou fora do escopo. Parece óbvio, mas muita empresa recebe um relatório "limpo" sem entender que metade dos sistemas não foi incluída.

A metodologia também importa. Saber que o teste seguiu OWASP, PTES ou outra referência reconhecida te dá uma base para comparar com outros trabalhos e entender o nível de cobertura que foi aplicado.

O que um relatório ruim costuma ter

Para contrabalançar, vale citar o que aparece com frequência em trabalhos de baixa qualidade:

Lista gerada por Nessus ou similar sem análise manual. Centenas de vulnerabilidades sem priorização real. Recomendações genéricas que poderiam ter sido escritas por qualquer pessoa sem ver o sistema. Nenhuma evidência de exploração. E o clássico: relatório que poderia ser de qualquer empresa, porque não tem nenhuma referência específica ao ambiente testado.

Se o relatório que você recebeu se parece com isso, vale questionar o fornecedor.

Como usar o relatório depois

O relatório não termina quando você lê. O ciclo correto é: receber o relatório, priorizar as correções por criticidade, implementar os fixes, e fazer o reteste para confirmar que as vulnerabilidades foram fechadas de fato.

Um fornecedor sério oferece suporte nessa fase — pelo menos para tirar dúvidas sobre as vulnerabilidades e confirmar se as correções foram adequadas. Se entregou o PDF e sumiu, é um sinal ruim.