Relatório de pentest: o que precisa ter

O problema: relatório que parece pentest e não é

Imagine a cena: o auditor pede a evidência do teste de intrusão anual, o time entrega um PDF de 60 páginas, e a primeira pergunta é "onde está a prova de que isso foi explorado?". Ninguém sabe responder. O pentest custou dinheiro e semanas, e o requisito continua em aberto. Isso acontece com mais frequência do que deveria, e quase sempre a causa está no relatório, não no teste.

O relatório é o único produto que sobra depois do pentest. A equipe de segurança usa para corrigir, o auditor usa para validar um requisito e o cliente enterprise usa para decidir se assina o contrato. Um teste excelente com relatório fraco vale pouco; um relatório bonito de um scan automatizado vale menos ainda.

Este guia descreve as partes que um relatório de pentest sério precisa ter, como reconhecer o "dump de scanner" e uma checklist que você pode usar na hora de receber (ou comprar) o entregável. Se ainda está escolhendo fornecedor, comece pelas 10 perguntas antes de contratar um pentest.

Quem lê cada parte do relatório

Um relatório sério atende leitores diferentes ao mesmo tempo. Saber quem lê o quê ajuda a avaliar se a estrutura está certa:

Seção	Quem lê	Pergunta que responde
Sumário executivo	Diretoria, CISO, jurídico	Qual o risco real e o que decidir primeiro?
Escopo e metodologia	Auditor, compliance	O teste cobriu o que a norma exige?
Classificação de risco	CISO, gestão de risco	O que corrigir antes?
Achados com evidência	Desenvolvedores, infraestrutura	Como reproduzo e corrijo?
Mapeamento regulatório	Auditor, compliance	Qual requisito este teste atende?
Reteste	Auditor, CISO	A correção funcionou?
Carta de atestação	Cliente enterprise, parceiros	Posso confiar nesse fornecedor?

1. Sumário executivo: para quem decide, não para quem executa

A primeira página deve ser legível por quem não é técnico e responder quatro coisas: o que foi testado, qual o resultado geral, quais riscos exigem decisão e o que fazer primeiro. Procure:

Veredito claro (por exemplo, "foi possível acessar dados de outros clientes sem autenticação válida"), não apenas um número de vulnerabilidades.
Os três a cinco achados que realmente importam para o negócio, em linguagem simples.
Contexto: o que não foi testado e por quê, para ninguém ler "sem achados críticos" como "sem risco".

Um sumário que diz "foram encontradas 143 vulnerabilidades" sem priorização é sinal de alerta.

2. Escopo, regras de engajamento e metodologia

Esta seção é a base da validade do relatório perante um auditor. Deve conter:

Alvos testados: domínios, IPs, aplicações, APIs, ambientes (produção ou homologação) e versão testada.
Janela de teste e abordagem: black, gray ou white box, com ou sem credenciais, o que estava fora de escopo. Veja a diferença em O que é pentest e os tipos de teste.
Metodologia documentada: referências como OWASP WSTG, OWASP API Security Top 10, PTES ou NIST SP 800-115. O relatório precisa dizer o que foi aplicado, não só listar resultados.
Limitações: bloqueios por WAF, restrições de carga, contas de teste indisponíveis.

Sem escopo e metodologia, o auditor não consegue confirmar que o teste cobriu o que a norma exige.

3. Classificação de risco: CVSS mais impacto de negócio

CVSS é útil como linguagem comum, mas sozinho engana. Um CVSS 6,5 numa API que expõe dados pessoais de todos os clientes pode ser mais urgente que um 9,0 em um sistema isolado sem dados. Um bom relatório mostra:

A pontuação CVSS com o vetor completo (para você conferir e recalcular).
A severidade ajustada ao contexto, explicando o impacto no seu negócio: dado exposto, fraude possível, parada de serviço, exigência regulatória.
A explorabilidade real: foi explorado de fato ou é teórico?

Desconfie de relatórios em que toda vulnerabilidade tem a severidade que a ferramenta atribuiu, sem nenhuma análise humana.

Na prática, a classificação de risco tem duas camadas. A faixa do CVSS é padronizada (baixa de 0,1 a 3,9; média de 4,0 a 6,9; alta de 7,0 a 8,9; crítica de 9,0 a 10,0), mas a prioridade de correção depende do contexto: que dado está exposto, quantos clientes são afetados, se há exploração sem autenticação e se existe um controle compensatório. Dois achados com a mesma nota podem exigir prazos muito diferentes. Por isso, exija que o relatório mostre as duas leituras lado a lado, e não só a nota da ferramenta.

4. Achados: evidência, prova de conceito e passos de reprodução

Cada achado deve permitir que seu time reproduza o problema sem precisar ligar para o fornecedor. O mínimo:

Título e identificador estável, para rastrear na correção e no reteste.
Descrição do que é a falha e onde está (URL, parâmetro, função, componente).
Evidência: capturas de tela, requisições e respostas HTTP, saída de comandos, com dados sensíveis mascarados.
Passos de reprodução numerados, na ordem em que foram executados.
Impacto demonstrado: o que o atacante consegue de fato com esse achado, inclusive encadeado com outros. É isso que diferencia pentest de scan; veja Scanner, pentest ou bug bounty.
Pré-condições: precisa estar autenticado? Precisa de rede interna?

Para o auditor, a evidência de exploração é o que prova que o teste foi manual e que a falha é real, e não um falso positivo.

Exemplo ilustrativo de um achado bem escrito

O exemplo abaixo é fictício e serve apenas para mostrar o nível de detalhe esperado. Não corresponde a nenhum cliente real.

Campo	Conteúdo
Identificador e título	PM-004 — Acesso a pedidos de outros clientes por troca do identificador na API
Severidade	Alta (CVSS 8,1 com vetor completo no anexo); ajustada para Crítica no contexto por expor dados pessoais de todos os clientes
Onde	`GET /api/v1/pedidos/{id}`, ambiente de produção, versão testada informada no escopo
Pré-condição	Conta de cliente comum autenticada; sem acesso à rede interna
Evidência	Requisição e resposta HTTP com dados mascarados; captura de tela da resposta com o pedido de outra conta
Reprodução	1) autenticar como cliente A; 2) chamar o endpoint com o identificador de um pedido do cliente B; 3) observar a resposta 200 com nome, endereço e itens do pedido
Impacto demonstrado	Leitura dos pedidos de qualquer cliente por enumeração do identificador, o que configura incidente de dados pessoais
Correção recomendada	Validar no servidor que o pedido pertence ao usuário autenticado (controle de acesso por objeto); usar identificadores não sequenciais como defesa adicional; testes automatizados de autorização
Status no reteste	Corrigido: a chamada com identificador de outro cliente retorna 403; evidência anexada em PM-004-R1

Repare no que torna esse achado útil: o time reproduz sozinho, o auditor vê a exploração real, e o status de reteste fecha o ciclo. Para entender a classe de falha, veja BOLA em APIs.

5. Recomendações de correção que um desenvolvedor consegue aplicar

"Aplique boas práticas de segurança" não é recomendação. Uma correção útil indica a causa raiz, o que mudar (validação no servidor, controle de acesso por objeto, rotação de segredos), uma referência técnica e, quando possível, um exemplo de código ou configuração. Também deve priorizar: o que corrigir em dias, o que pode entrar no próximo ciclo e o que pede mitigação enquanto a correção definitiva não chega.

6. Mapeamento regulatório

Se o teste existe para atender uma exigência, o relatório precisa dizer qual. Em vez de deixar o auditor adivinhar, uma tabela de rastreabilidade liga a atividade do pentest ao requisito:

PCI DSS 4.0.1, requisito 11.4 (pentest interno e externo, segmentação, reteste). Detalhes em Pentest para PCI DSS 4.0 e BACEN.
Regulação do Banco Central para instituições reguladas.
ISO 27001, SOC 2 e LGPD, quando fizerem parte da sua pauta de conformidade.

O relatório não substitui a decisão do seu time jurídico ou de compliance sobre o que a norma exige de você, mas deve facilitar a resposta.

Um exemplo de tabela de rastreabilidade que facilita a vida do auditor (os requisitos exatos dependem da sua norma e do seu escopo):

Atividade do pentest	Onde está no relatório	Requisito que apoia
Teste externo e interno com metodologia nomeada	Seção de escopo e metodologia	PCI DSS 4.0.1, requisito 11.4
Teste de segmentação do ambiente de cartão	Seção de segmentação	PCI DSS 4.0.1, requisito 11.4
Evidência de exploração e impacto	Achados	Exigência de teste independente de instituições reguladas
Correção e nova verificação	Seção de reteste	Requisitos que pedem correção documentada
Teste de controles de acesso e proteção de dados	Achados de autorização e dados	Medidas de segurança da LGPD (art. 46)

7. Reteste: a prova de que a correção funcionou

O relatório inicial mostra o problema; o reteste mostra que ele acabou. A seção de reteste deve registrar a data, o status de cada achado (corrigido, parcialmente corrigido, não corrigido, risco aceito) e a evidência de que o ataque original não funciona mais. Muitos auditores tratam um relatório sem reteste como requisito em aberto. Pergunte ao fornecedor, antes de fechar, se o reteste está incluído e em que prazo.

8. Carta de atestação e resumo para terceiros

Clientes enterprise raramente querem o relatório completo: ele contém detalhes das suas vulnerabilidades. O que eles pedem é uma carta de atestação (ou resumo) que confirme quem testou, quando, o escopo, a metodologia e o resultado geral, sem expor detalhes técnicos. Confirme que o fornecedor entrega os dois documentos: o relatório técnico completo, de circulação restrita, e a carta para compartilhar.

Sinais de alerta: o relatório que é um dump de scanner

Lista enorme de achados sem priorização e sem contexto.
Descrições genéricas copiadas de bases públicas, iguais para qualquer cliente.
Sem evidência de exploração, sem passos de reprodução.
Falsos positivos misturados (versão "vulnerável" que não é explorável naquela configuração).
Nenhuma menção a lógica de negócio, controle de acesso ou encadeamento de falhas.
Sem escopo, metodologia ou limitações declarados.
Sem seção de reteste e sem carta de atestação.

Checklist para receber o relatório

[ ] Sumário executivo com veredito e prioridades.
[ ] Escopo, janela, abordagem e limitações declarados.
[ ] Metodologia nomeada (OWASP, PTES, NIST SP 800-115).
[ ] CVSS com vetor e severidade ajustada ao negócio.
[ ] Cada achado com evidência, passos de reprodução e impacto.
[ ] Recomendações específicas e priorizadas.
[ ] Mapeamento para a norma que motivou o teste.
[ ] Reteste previsto, com prazo.
[ ] Carta de atestação para terceiros.
[ ] Dados sensíveis mascarados e confidencialidade do documento definida.

Perguntas para fazer ao fornecedor antes de fechar

Posso ver um relatório de exemplo anonimizado antes de assinar?
Quem escreve e quem revisa o relatório? Há revisão por um segundo profissional?
O relatório traz o vetor CVSS completo e a severidade ajustada ao meu negócio?
O reteste está incluído? Quantos ciclos e em que prazo?
Receberei a carta de atestação para mostrar a clientes?
Como os dados sensíveis encontrados durante o teste são tratados, armazenados e descartados?
O relatório mapeia os achados para a norma que motivou o teste?

Quer ver como isso fica na prática?

Podemos enviar um relatório de exemplo anonimizado para você comparar com o que seu fornecedor atual entrega. Peça pelo formulário de orçamento e diga que quer o exemplo; se já tem um escopo em mente, aproveite para pedir a proposta.

Perguntas frequentes

Quantas páginas deve ter um relatório de pentest?

Não existe número certo. Depende do escopo e dos achados. Mais importante que o tamanho é a estrutura: sumário executivo curto, achados com evidência e reprodução, e anexos técnicos separados.

O relatório pode ser entregue a clientes e auditores?

Normalmente o relatório técnico completo tem circulação restrita, porque descreve falhas do seu ambiente. Para terceiros, use a carta de atestação ou um resumo, e compartilhe o completo apenas sob acordo de confidencialidade.

Um scan de vulnerabilidades pode substituir o relatório de pentest?

Não. O scan lista possíveis falhas conhecidas; o pentest as explora, encadeia e demonstra impacto. Muitas normas e auditores exigem a segunda abordagem.

Qual a diferença entre relatório de pentest e relatório de scan?

O relatório de scan lista possíveis vulnerabilidades detectadas por uma ferramenta, normalmente com falsos positivos e sem prova de exploração. O relatório de pentest registra o que um profissional conseguiu explorar, encadear e demonstrar, com evidência, impacto e correção. Veja mais em Scanner, pentest ou bug bounty.

Por quanto tempo devo guardar o relatório?

Depende da norma e da política da sua empresa. Instituições reguladas e programas de conformidade costumam exigir guarda das evidências por vários anos. Confirme o prazo com seu time de compliance e guarde o relatório e o reteste juntos, com controle de acesso restrito.

Quem deve receber o relatório dentro da empresa?

O relatório completo deve ir para um grupo pequeno e definido: CISO ou responsável de segurança, líderes técnicos que corrigem e, quando necessário, compliance. Defina isso antes do teste, já que o documento descreve como atacar o seu ambiente.

O reteste está incluído no relatório?

Depende do contrato. Confirme antes de fechar se o reteste está no preço, quantos ciclos e em que prazo, e se o relatório é reemitido com o status atualizado.

Como sei se a severidade dos achados está correta?

Peça o vetor CVSS completo e a justificativa de impacto no seu negócio. Se a severidade parece vir apenas da ferramenta, sem análise, questione.