O relatório de pentest é o que sobra quando os testers vão embora. Os exploits, as shells de madrugada e as cadeias criativas só valem se terminarem em um documento que executivos entendam, que desenvolvedores consigam executar e que um auditor aceite como evidência. Um relatório fraco transforma um bom pentest em um PDF que ninguém lê.
Neste guia você encontra um modelo de relatório de pentest completo para copiar, o que colocar em cada seção, um achado de exemplo escrito do começo ao fim e dicas para escrever o mesmo relatório para dois leitores bem diferentes: executivos e desenvolvedores.
Para que serve um relatório de pentest
Um pentest é um ataque autorizado, com tempo definido, contra um escopo combinado. O relatório tem quatro funções:
- Apoiar decisões. A liderança precisa saber o quão exposta a empresa está e quanto custa corrigir.
- Viabilizar correções. Os desenvolvedores precisam de detalhe suficiente para reproduzir cada problema sem ligar para o tester.
- Gerar evidência. Clientes, auditores e frameworks como SOC 2, ISO 27001 ou PCI DSS costumam pedir um relatório recente e prova de remediação.
- Criar uma linha de base. O pentest do ano que vem será comparado com este.
Se uma seção não cumpre nenhuma dessas funções, corte. Páginas de output de ferramenta coladas como anexo quase nunca ajudam ninguém.
A estrutura de um bom relatório de pentest
| Seção | Leitor principal | O que responde |
|---|---|---|
| Sumário executivo | CEO, CTO, conselho, clientes | Qual a gravidade, o que importa mais, o que fazer |
| Escopo e regras de engajamento | Todos, auditores | O que foi testado, quando, de onde e o que ficou de fora |
| Metodologia | Time de segurança, auditores | Como o teste foi feito e com qual padrão |
| Resumo dos achados | Líderes de engenharia | A lista completa, ordenada por severidade |
| Achados detalhados | Desenvolvedores | Como reproduzir, por que importa, como corrigir |
| Rating de risco | Liderança, segurança | A postura geral em uma frase |
| Reteste | Auditores, clientes | O que foi verificado como corrigido e quando |
Modelo de relatório de pentest grátis (copiar e colar)
Copie o bloco abaixo para o seu editor de documentos ou para um repositório em Markdown e substitua o que está entre colchetes.
RELATÓRIO DE PENETRATION TEST
Cliente: [Nome da empresa]
Aplicação / ambiente: [Nome, versão, URL ou repositório]
Janela de teste: [Data de início] a [Data de fim]
Versão do relatório: [1.0] Data: [Data] Classificação: [Confidencial]
Elaborado por: [Tester, certificações] Revisado por: [Revisor de QA]
1. SUMÁRIO EXECUTIVO
1.1 Objetivo: [Por que o teste foi feito: pedido de cliente, release, auditoria]
1.2 Rating de risco geral: [Critical / High / Medium / Low]
1.3 Resultados principais:
- [N] achados: [x] Critical, [x] High, [x] Medium, [x] Low, [x] Informativos
- Risco mais importante: [Uma frase em termos de negócio]
- Pontos fortes observados: [O que estava bem feito]
1.4 Recomendações principais:
1. [Ação, responsável, prazo sugerido]
2. [Ação, responsável, prazo sugerido]
3. [Ação, responsável, prazo sugerido]
2. ESCOPO E REGRAS DE ENGAJAMENTO
2.1 Dentro do escopo: [URLs, faixas de IP, APIs, repositórios, apps mobile]
2.2 Fora do escopo: [Serviços de terceiros, alteração de dados de produção, DoS]
2.3 Tipo de teste: [Black box / grey box / white box]
2.4 Contas fornecidas: [Perfis e quantidade de usuários de teste]
2.5 IPs de origem dos testers: [IPs]
2.6 Restrições e limitações: [Tempo, funções indisponíveis, testes bloqueados]
3. METODOLOGIA
3.1 Padrões seguidos: [PTES, OWASP WSTG, NIST SP 800-115]
3.2 Fases: reconhecimento, mapeamento, descoberta de vulnerabilidades,
exploração, pós-exploração, relatório
3.3 Ferramentas usadas: [Lista]
3.4 Modelo de severidade: score base CVSS [v3.1 / v4.0] mais contexto de negócio
None 0.0 | Low 0.1-3.9 | Medium 4.0-6.9 | High 7.0-8.9 | Critical 9.0-10.0
4. RESUMO DOS ACHADOS
| ID | Título | Severidade | CVSS | CWE | Ativo | Status |
|--------|-------------------------|------------|------|---------|------------------|---------|
| PT-01 | [Título] | [High] | [x.x]| [CWE-x] | [Endpoint/arquivo]| Aberto |
| PT-02 | [Título] | [Medium] | [x.x]| [CWE-x] | [Endpoint/arquivo]| Aberto |
5. ACHADOS DETALHADOS
ID: [PT-01]
Título: [Curto e específico]
Severidade: [High] CVSS: [score] ([vetor]) CWE: [CWE-x: nome]
Ativo afetado: [URL, parâmetro, arquivo e linha]
Descrição: [O que é a vulnerabilidade]
Passos para reproduzir:
1. [Passo]
2. [Passo]
Evidência: [Request/response, referência a print, dados mascarados]
Impacto: [O que um atacante consegue fazer, em termos de negócio]
Remediação: [Correção concreta, com exemplo de código ou configuração]
Referências: [OWASP, CWE, documentação do fornecedor]
Status: [Aberto / Corrigido / Risco aceito]
6. RATING DE RISCO GERAL
[Rating] porque [motivos principais]. Probabilidade: [x]. Impacto: [x].
7. RETESTE
Data do reteste: [Data]
| ID | Severidade original | Resultado do reteste | Evidência |
|-------|---------------------|-------------------------|--------------|
| PT-01 | High | Corrigido | [Referência] |
| PT-02 | Medium | Parcialmente corrigido | [Referência] |
ANEXOS
A. Contas de teste e dados criados (e removidos)
B. Glossário para leitores não técnicosSeção por seção: o que escrever
Sumário executivo
Uma página, no máximo. Nada de payloads ou headers HTTP. Coloque o objetivo, o rating geral, a quantidade de achados por severidade, o risco (ou os dois riscos) que realmente importam em linguagem de negócio e as três ações principais. "Um cliente logado consegue baixar as faturas de qualquer outro cliente, com nomes, endereços e valores" é muito melhor do que "IDOR na API de faturas".
Escopo e regras de engajamento
É a seção que protege os dois lados. Liste exatamente o que foi testado e o que não foi, as datas, o tipo de teste (black, grey ou white box) e qualquer limitação. Se o painel de admin ficou fora do ar em dois dos cinco dias, escreva. Um auditor que lê "toda a aplicação foi testada" quando metade estava inacessível não vai confiar no resto.
Metodologia
Diga qual padrão você seguiu: PTES (Penetration Testing Execution Standard), o OWASP Web Security Testing Guide (WSTG) ou o NIST SP 800-115. Mapear os achados para o OWASP Top 10 também ajuda o leitor a situar cada problema. Cite as ferramentas principais, mas lembre que o relatório é sobre resultados, não um catálogo de ferramentas de pentest.
Achados: severidade, CVSS e CWE
Cada achado precisa de uma severidade comparável. O padrão de mercado é o CVSS, Common Vulnerability Scoring System mantido pelo FIRST. O CVSS v4.0 foi publicado em 1 de novembro de 2023 e a v3.1 ainda é muito usada. As duas compartilham as mesmas faixas qualitativas: None 0.0, Low 0.1 a 3.9, Medium 4.0 a 6.9, High 7.0 a 8.9, Critical 9.0 a 10.0. Informe sempre a versão e o vetor completo, não só o número, para que qualquer pessoa possa recalcular.
Inclua um identificador CWE (Common Weakness Enumeration, mantido pelo MITRE). O CWE diz ao desenvolvedor qual é a classe do bug, leva a guias de prevenção e permite acompanhar fraquezas que se repetem entre relatórios.
Rating de risco e reteste
O rating geral é um julgamento, não uma média. Um único Critical em um fluxo de pagamento exposto à internet torna o rating Critical mesmo que todo o resto seja Low. O reteste registra, para cada achado, se a correção foi verificada, com data e evidência. Quando um cliente pede "o último pentest", quase sempre é esta seção que ele quer ver.
Exemplo de achado, escrito por completo
Veja como fica um achado completo na prática. É uma vulnerabilidade IDOR, um dos problemas mais comuns em apps web e APIs modernas.
ID: PT-03
Título: Qualquer usuário logado consegue ler faturas de outros clientes
Severidade: Medium
CVSS v3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
CWE: CWE-639 Authorization Bypass Through User-Controlled Key
Ativo afetado: GET /api/invoices/:id
src/routes/invoices.js, linha 42
Descrição:
O endpoint carrega uma fatura pelo ID numérico e a devolve para
qualquer usuário logado. Não verifica se a fatura pertence à conta
que fez o request.
Passos para reproduzir:
1. Fazer login como usuário A (tenant 101) e abrir a fatura 5120.
2. Repetir o request trocando o ID para 5121.
3. A API responde HTTP 200 com a fatura do tenant 205.
Evidência:
GET /api/invoices/5121 HTTP/1.1
Authorization: Bearer <token do usuário A>
HTTP/1.1 200 OK
{"id":5121,"tenant_id":205,"customer":"[MASCARADO]","total":"[MASCARADO]"}
Impacto:
Os IDs são sequenciais, então um atacante com uma conta grátis
consegue baixar todas as faturas da plataforma: nomes, endereços e
valores. É um vazamento de dados pessoais segundo a LGPD e a maioria
das leis de privacidade.
Remediação:
Limitar a query ao tenant atual e responder 404 quando a fatura
não pertence a ele:
const invoice = await Invoice.findOne({
where: { id: req.params.id, tenantId: req.user.tenantId }
});
if (!invoice) return res.status(404).end();
Adicionar um teste automatizado que peça a fatura de outro tenant e
espere 404. Aplicar o mesmo controle a PUT e DELETE nesta rota.
Referências: OWASP WSTG Authorization Testing, CWE-639
Status: AbertoRepare nos detalhes que tornam esse achado útil: um título que um CEO entende, o arquivo e a linha exatos, um request reproduzível, evidência mascarada, impacto em termos de negócio e uma correção que o desenvolvedor pode colar. Repare também que o CVSS dá Medium enquanto o impacto de negócio é sério. Por isso o sumário executivo pode colocá-lo entre as prioridades. Diga isso de forma explícita em vez de inflar o score em silêncio.
Escrever para executivos vs. para desenvolvedores
Para executivos
- Comece pela conclusão. A primeira frase diz o risco geral e o problema mais importante.
- Traduza o impacto. Fale de dados de clientes, dinheiro, indisponibilidade, contratos e compliance, não de parâmetros e payloads.
- Entregue decisões, não listas. Três ações priorizadas com responsável e prazo valem mais do que vinte achados.
- Seja honesto com os limites. Diga o que não foi testado. Um relatório limpo sobre um escopo pequeno não é atestado de saúde.
- Evite o alarmismo. Linguagem calma e factual gera mais confiança do que faixas vermelhas.
Para desenvolvedores
- Todo achado reproduzível. Request exato, perfil da conta, ambiente e resposta esperada versus real.
- Aponte para o código quando puder. Em um white box ou em uma auditoria de segurança de código, arquivo e linha economizam horas.
- Proponha uma correção concreta na stack do time e sugira um teste de regressão para o bug não voltar.
- Agrupe problemas relacionados. Se doze endpoints não têm a mesma checagem de ownership, reporte uma causa raiz com a lista completa de rotas afetadas.
- Mascare dados sensíveis em prints e respostas. O relatório vai circular por e-mail.
Erros comuns em relatórios de pentest
- Colar output de scanner como achado. Resultados não verificados vão, no máximo, para um anexo. Se você quer a camada automática, rode scanners de vulnerabilidades open source antes do pentest, não dentro do relatório.
- Severidade sem vetor. Um "High" sem vetor CVSS não pode ser questionado nem verificado.
- Remediação genérica. "Validar o input" não é correção. Mostre a mudança.
- Sem reteste. Um relatório sem remediação verificada é só metade da evidência que os clientes pedem.
- Limites de escopo ausentes. Se você não diz o que não foi testado, o leitor entende que tudo foi testado.
Teste contínuo entre relatórios de pentest
Um relatório de pentest manual é uma foto. Seu código muda toda semana, então muitos times complementam o relatório anual com teste contínuo do próprio código. Com o Nurbak, por exemplo, você conecta o GitHub e escaneia um repositório: o próprio modelo de IA self-hosted analisa o código (a análise não envia seu código para a OpenAI nem para a Anthropic) e reporta vulnerabilidades exploráveis com arquivo e linha, CVEs em dependências, misconfigurações de GitHub Actions, Docker, Terraform e Kubernetes e segredos no histórico do git, com um score de 0 a 100 e explicações em linguagem simples. Ele também pode abrir um Pull Request com a correção mais um teste de regressão de segurança (a correção usa o Claude, só com o seu consentimento explícito). Veja como funciona na página de pentest com IA.
Isso não substitui um tester humano para lógica de negócio e ataques encadeados. Se você está escolhendo um, leia nosso guia de empresas de pentest e peça a cada fornecedor um relatório de exemplo antes de assinar.
Resumo
Um relatório de pentest útil é curto no topo e preciso no detalhe: um sumário executivo de uma página, um escopo claro, uma metodologia com nome, achados com vetor CVSS, CWE, evidência e correção concreta, um rating geral honesto e um reteste. Copie o modelo acima, adapte ao seu contexto e escreva cada seção para o seu leitor. E se quiser encontrar problemas antes do próximo pentest, comece com um pentest com IA do seu repositório.