Relatório de pentest: o que deve conter

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

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

O relatório é o único produto que fica depois de um teste de intrusão. A equipa de segurança usa-o para corrigir, o auditor para validar um requisito e o cliente empresarial para decidir se assina. Um teste excelente com um relatório fraco vale pouco; um relatório bem apresentado, mas feito a partir de um scan automático, vale ainda menos.

Este guia descreve as secções de que um relatório de pentest sério precisa, como reconhecer o «despejo de scanner» e uma checklist para usar quando receber (ou comprar) o entregável. Se ainda está a escolher fornecedor, comece pelas 10 perguntas a fazer antes de contratar um pentest.

Quem lê cada parte do relatório

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

Secção	Quem lê	Pergunta a que responde
Sumário executivo	Administração, CISO, jurídico	Qual é o risco real e o que decidir primeiro?
Âmbito e metodologia	Auditor, conformidade	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	Programadores, infraestrutura	Como reproduzo e corrijo?
Mapeamento regulamentar	Auditor, conformidade	Que requisito este teste cumpre?
Reteste	Auditor, CISO	A correção funcionou?
Carta de atestação	Clientes enterprise, parceiros	Posso confiar neste fornecedor?

1. Sumário executivo: para quem decide

A primeira página tem de ser legível por quem não é técnico e responder a quatro questões: o que foi testado, qual o resultado geral, que riscos exigem decisão e o que fazer primeiro. Procure:

Um veredicto claro (por exemplo, «foi possível aceder a dados de outros clientes sem autenticação válida»), e 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 porquê, para que ninguém leia «sem achados críticos» como «sem risco».

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

2. Âmbito, regras de atuação e metodologia

Esta secção é o que torna o relatório defensável perante um auditor. Deve conter:

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

Sem âmbito 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 no negócio

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

A pontuação CVSS com o vetor completo, para que possa verificá-la e recalculá-la.
Uma gravidade ajustada ao contexto, que explique o impacto no seu negócio: dados expostos, possível fraude, paragem de serviço, exposição regulamentar.
A explorabilidade real: foi mesmo explorado ou é teórico?

Desconfie de relatórios em que cada vulnerabilidade tem a gravidade atribuída pela ferramenta, sem análise humana.

Na prática, a classificação de risco tem duas camadas. A faixa do CVSS é normalizada (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 dados estão expostos, quantos clientes são afetados, se a exploração exige autenticação e se existe um controlo compensatório. Dois achados com a mesma nota podem exigir prazos muito diferentes. Exija que o relatório mostre as duas leituras lado a lado, e não apenas a nota da ferramenta.

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

Cada achado deve permitir que a sua equipa reproduza o problema sem ter de contactar o fornecedor. No mínimo:

Título e identificador estável, para acompanhar a correção e o reteste.
Descrição da falha e de onde se encontra (URL, parâmetro, função, componente).
Evidência: capturas de ecrã, pedidos e respostas HTTP, saída de comandos, com dados sensíveis ocultados.
Passos de reprodução numerados, pela ordem em que foram executados.
Impacto demonstrado: o que um atacante consegue realmente com esse achado, incluindo quando encadeado com outros. É isto que distingue um pentest de um scan; veja Scanner, pentest ou bug bounty.
Pré-condições: exige autenticação? Acesso à rede interna?

Para o auditor, a evidência de exploração 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 seguinte é 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 encomendas de outros clientes ao trocar o identificador na API
Severidade	Alta (CVSS 8,1, vetor completo em anexo); ajustada para Crítica no contexto por expor dados pessoais de todos os clientes
Onde	`GET /api/v1/encomendas/{id}`, ambiente de produção, versão testada indicada no âmbito
Pré-condição	Conta de cliente comum autenticada; sem acesso à rede interna
Evidência	Pedido e resposta HTTP com dados mascarados; captura de ecrã da resposta com a encomenda de outra conta
Reprodução	1) autenticar como cliente A; 2) chamar o endpoint com o identificador de uma encomenda do cliente B; 3) observar a resposta 200 com nome, morada e artigos
Impacto demonstrado	Leitura das encomendas de qualquer cliente por enumeração do identificador, o que constitui uma violação de dados pessoais
Correção recomendada	Validar no servidor que a encomenda pertence ao utilizador autenticado (controlo de acesso por objeto); identificadores não sequenciais como defesa adicional; testes automáticos de autorização
Estado no reteste	Corrigido: a chamada com o identificador de outro cliente devolve 403; evidência anexa em PM-004-R1

Repare no que torna este achado útil: a equipa reproduz sozinha, o auditor vê exploração real e o estado do reteste fecha o ciclo. Para perceber esta classe de falha, veja BOLA em APIs.

5. Recomendações de correção que um programador consiga aplicar

«Aplicar boas práticas de segurança» não é uma recomendação. Uma correção útil indica a causa raiz, o que alterar (validação no servidor, controlo de acesso por objeto, rotação de segredos), uma referência técnica e, sempre que possível, um exemplo de código ou configuração. Deve também priorizar: o que corrigir em dias, o que pode esperar pelo ciclo seguinte e o que precisa de mitigação enquanto a correção definitiva não chega.

6. Mapeamento regulamentar

Se o teste existe para cumprir um requisito, o relatório deve 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). Pormenores em Pentest para PCI DSS 4.0.
ISO 27001, SOC 2 e RGPD, quando fizerem parte da sua agenda de conformidade. Veja Testes de intrusão para ISO 27001, SOC 2 e RGPD.
NIS2 e DORA, para entidades abrangidas. Veja Testes de intrusão na NIS2 e no DORA.

O relatório não substitui o critério da sua equipa jurídica ou de conformidade sobre o que a norma lhe exige, mas deve facilitar a resposta.

Um exemplo de tabela de rastreabilidade que facilita o trabalho do auditor (os requisitos exatos dependem da sua norma e do seu âmbito):

Atividade do teste	Onde consta no relatório	Requisito que apoia
Testes externos e internos com metodologia identificada	Secção de âmbito e metodologia	PCI DSS 4.0.1, requisito 11.4
Teste de segmentação do ambiente de cartões	Secção de segmentação	PCI DSS 4.0.1, requisito 11.4
Evidência de exploração e impacto	Achados	Exigências de teste independente (por exemplo, DORA e NIS2, consoante o setor)
Correção e nova verificação	Secção de reteste	Requisitos de correção documentada
Testes de controlo de acesso e proteção de dados	Achados de autorização e dados	Medidas de segurança do RGPD (art. 32.º)

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

O relatório inicial mostra o problema; o reteste mostra que desapareceu. A secção de reteste deve registar a data, o estado de cada achado (corrigido, parcialmente corrigido, não corrigido, risco aceite) e a evidência de que o ataque original já não funciona. Muitos auditores consideram que um relatório sem reteste deixa o requisito em aberto. Antes de assinar, pergunte ao fornecedor se o reteste está incluído e em que prazo.

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

Os clientes empresariais raramente querem o relatório completo: ele detalha as suas vulnerabilidades. O que pedem é uma carta de atestação (ou resumo) que confirme quem testou, quando, o âmbito, a metodologia e o resultado geral, sem expor pormenores técnicos. Confirme que o fornecedor entrega os dois documentos: o relatório técnico completo, de circulação restrita, e a carta para partilhar.

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

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

Checklist para receber o relatório

[ ] Sumário executivo com veredicto e prioridades.
[ ] Âmbito, janela, abordagem e limitações declarados.
[ ] Metodologia identificada (OWASP, PTES, NIST SP 800-115).
[ ] CVSS com vetor e gravidade 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 ocultados e confidencialidade do documento definida.

Perguntas a fazer ao fornecedor antes de assinar

Posso ver um relatório de exemplo anonimizado antes de assinar?
Quem redige e quem revê o relatório? Existe 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? Quantas rondas e em que prazo?
Recebo a carta de atestação para mostrar a clientes?
Como são tratados, guardados e destruídos os dados sensíveis encontrados durante o teste?
O relatório associa os achados à norma que motivou o teste?

Quer ver como isto fica na prática?

Podemos enviar-lhe um relatório de exemplo anonimizado para comparar com o que o seu fornecedor atual entrega. Peça-o através do formulário de orçamento, indicando que quer o exemplo; se já tem um âmbito em mente, aproveite para pedir a proposta.

Perguntas frequentes

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

Não existe um número certo. Depende do âmbito e dos achados. A estrutura importa mais do que a extensão: 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?

O relatório técnico completo costuma ter circulação restrita, porque descreve fragilidades do seu ambiente. Para terceiros use a carta de atestação ou um resumo, e partilhe 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 explora-as, encadeia-as e demonstra o impacto. Muitas normas e auditores esperam a segunda abordagem.

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

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

Durante quanto tempo devo guardar o relatório?

Depende da norma e da política da sua empresa. Entidades reguladas e programas de conformidade costumam exigir a conservação das evidências durante vários anos. Confirme o prazo com a equipa de conformidade e guarde o relatório e o reteste em conjunto, com acesso restrito.

Quem deve receber o relatório dentro da empresa?

O relatório completo deve seguir para um grupo pequeno e definido: o CISO ou responsável de segurança, os responsáveis técnicos que corrigem e, se necessário, a conformidade. Defina-o antes do teste, porque o documento descreve como atacar o seu ambiente.

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

Depende do contrato. Antes de assinar, confirme se o reteste está no preço, quantos ciclos, em que prazo, e se o relatório é reemitido com o estado atualizado.

Como sei se as gravidades estão corretas?

Peça o vetor CVSS completo e a justificação do impacto no seu negócio. Se a gravidade parecer vir apenas da ferramenta, sem análise, questione.