PentestRelatórioMetodologiaGestão de Risco

Anatomia de um relatório de pentest que serve pra alguma coisa

Lista de CVE com CVSS colado do scanner não é relatório de pentest, é um PDF bonito. O que separa um do outro são três coisas: evidência reproduzível, severidade ajustada ao seu ambiente e remediação que o dev consiga aplicar. Como reconhecer cada uma antes de assinar.

Por Equipe VorvexPublicado em 22 de agosto de 20266 min de leitura

O relatório é o único produto que sobra depois que o pentest acaba. As horas de teste viram esse documento, e é ele que vai circular entre o time de desenvolvimento, a diretoria e, muitas vezes, um auditor. Mesmo assim, boa parte do que o mercado brasileiro entrega com o nome de relatório de pentest é a mesma coisa: a saída bruta de um scanner de vulnerabilidade, reformatada num PDF com a logo do fornecedor. Uma lista de CVE, cada um com sua nota CVSS, ordenada por cor. Nenhuma prova de que aquilo foi explorado, nenhuma leitura do que significa naquele ambiente, nenhuma instrução que um desenvolvedor consiga seguir. Quem contrata por exigência regulatória costuma descobrir isso tarde, quando o documento precisa aguentar uma auditoria de verdade e não aguenta.

Side by side comparison of two penetration test reports. On the left, a thin report that is just a sorted list of CVE identifiers each with a colored CVSS score badge, clearly a reformatted scanner export. On the right, a thicker structured report showing a reproducible evidence section with request and response, a context-adjusted severity note, and a remediation block addressed to a developer. — À esquerda, o output de scanner vestido de relatório: lista de CVE ordenada por CVSS. À direita, um relatório que prova, contextualiza e instrui. O mesmo preço, produtos diferentes.

O relatório é o produto, não um efeito colateral do teste

Quando alguém contrata pentest, o que compra de fato é o relatório. O teste em si não deixa nada palpável: ninguém da empresa assiste ao testador trabalhar, ninguém guarda as requisições que ele mandou. Tudo o que resta é o documento, e o valor do serviço inteiro fica preso à qualidade dele. Um teste excelente descrito num relatório ruim vale, na prática, o que o relatório conseguir comunicar, que é quase nada. Por isso avaliar fornecedor de pentest pelo relatório não é detalhe: é olhar direto para o único entregável que você vai receber.

O problema é que o relatório de scanner e o relatório de pentest de verdade se parecem à primeira vista. Os dois têm capa, sumário executivo, lista de achados com severidade e uma seção de recomendações. A diferença está no conteúdo de cada achado, e ela aparece em três lugares específicos: como o achado é provado, como a severidade é justificada e como a correção é descrita. Um relatório que falha nos três é um scan com roupa nova. Vale conhecer cada um, porque são exatamente os três que você consegue checar sozinho antes de fechar contrato.

Elemento 1: evidência reproduzível, não print genérico

A primeira coisa que separa um relatório sério de um enfeitado é a evidência. Achado sem prova é opinião, e opinião não sobrevive a uma contestação do time de desenvolvimento nem a um auditor cético. Um scanner entrega, no máximo, a assinatura que casou e um print da tela. Um relatório de pentest de verdade entrega o caminho: a requisição exata que foi enviada, a resposta exata que voltou, e os passos para reproduzir do zero. Se o leitor não consegue repetir o achado com o que está escrito, não é evidência, é alegação.

http

# Achado: acesso a pedido de outro cliente (BOLA)
# Endpoint: GET /api/v2/orders/{id}

# Passo 1 - autenticado como cliente A (id 8842), lendo o proprio pedido
GET /api/v2/orders/8842 HTTP/1.1
Host: app.cliente.com.br
Authorization: Bearer <token-do-cliente-A>
-> 200 OK  {"order_id":8842,"customer_id":8842, ...}

# Passo 2 - MESMO token, pedido de outro cliente
GET /api/v2/orders/8843 HTTP/1.1
Host: app.cliente.com.br
Authorization: Bearer <token-do-cliente-A>
-> 200 OK  {"order_id":8843,"customer_id":8843,"cpf":"***", ...}

# O token do cliente A leu o pedido do cliente B, com CPF.
# Reproduzido 4 vezes com ids sequenciais. Nenhuma versao
# desatualizada envolvida: e falha de logica de autorizacao.

Evidência de verdade: as duas requisições, as duas respostas e a nota de que foi reproduzido. Qualquer pessoa do time consegue repetir e confirmar. Isso um print de tela não entrega.

Anatomy diagram of a single reproducible finding entry in a penetration test report. It labels the parts: a title describing the flaw, the affected endpoint, a numbered sequence of steps, the exact request sent, the exact response received highlighted as the proof, and a note recording that the finding was reproduced multiple times. — As partes de um achado que se sustenta: título, endpoint, passos numerados, a requisição, a resposta que prova e o registro de que foi reproduzido. Sem a resposta real, o resto é alegação.

Elemento 2: severidade ajustada ao ambiente, não CVSS puro

O segundo elemento é a severidade, e é onde o relatório de scanner mais engana. A ferramenta atribui a nota CVSS base do CVE e para por aí. Só que a nota base é calculada para um mundo genérico, sem saber onde aquele ativo está, que dado ele guarda ou se está exposto na internet. O mesmo achado pode ser irrelevante num serviço interno de teste e crítico numa API pública que devolve dado pessoal. Um relatório que serve ajusta a severidade ao seu ambiente e explica o ajuste; um que só copia o número da ferramenta transfere pra você o trabalho de descobrir o que realmente importa.

bash

# Como o scanner reporta (nota base, isolada do ambiente):
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N  ->  6.5  "Medio"

# O mesmo achado, dois ambientes reais:

# Ambiente 1 - endpoint interno de homologacao, sem dado real,
#   so acessivel na VPN. Risco pratico: baixo.

# Ambiente 2 - MESMA falha, mas na API publica de producao que
#   retorna CPF e historico de compra do cliente. Dado sensivel
#   sob LGPD, exposto na internet. Risco pratico: alto.

# A nota base 6.5 nao muda entre os dois. O risco real, sim.
# O relatorio serio classifica pelo ambiente 2 e explica por que.

A nota base do CVSS é a mesma nos dois cenários; o risco real, não. Um relatório útil classifica pelo contexto e mostra o raciocínio, em vez de despejar o número genérico da ferramenta.

Ajustar severidade não é inflar nota pra assustar nem espremer pra tranquilizar. É fazer a leitura que a ferramenta não tem como fazer, porque não conhece a sua topologia, seu dado e sua exposição. Um relatório honesto às vezes rebaixa um achado que o scanner marcou como crítico, porque no seu ambiente aquilo não alcança nada, e explica por quê. Essa capacidade de subir e descer a severidade com justificativa é um dos sinais mais confiáveis de que houve gente pensando, não só ferramenta rodando.

Elemento 3: remediação acionável, escrita pra quem vai corrigir

O terceiro elemento é a remediação, e é o mais desperdiçado. Muito relatório fecha o achado com uma recomendação genérica do tipo "implemente controle de acesso adequado" ou "aplique as melhores práticas de segurança". Isso não é remediação, é o título do problema repetido. Quem vai corrigir é um desenvolvedor, e ele precisa saber onde no código, o que exatamente mudar e como confirmar que a correção funcionou. Remediação boa é escrita pra quem tem o teclado, não só pra quem apresenta o resumo pro board.

bash

# Remediacao generica (colada do scanner) - nao acionavel:
"Implemente controle de acesso adequado (OWASP A01)."

# Remediacao acionavel - escrita pra quem corrige:
# No handler de GET /api/v2/orders/{id}, depois de autenticar o
# token, validar que orders.customer_id == token.sub ANTES de
# retornar o objeto. O mesmo controller expoe PATCH e DELETE em
# /orders/{id}: os tres herdam a falha, corrigir os tres.
#
# Teste de regressao: token do cliente A pedindo pedido do B
# deve retornar 404 (nao 403 - o 403 ja confirma que o objeto
# existe). Adicionar esse caso na suite pra nao regredir.

Duas frases sobre o mesmo achado. A de cima repete o nome do problema; a de baixo diz onde, o que mudar, o efeito colateral esquecido e como testar. Só a segunda vira commit.

Diagram contrasting two remediation styles for the same finding. On one side, a vague one-line recommendation aimed at a boardroom summary. On the other, a detailed remediation addressed to a developer at a keyboard: the exact location in code, the specific check to add, related endpoints that share the flaw, and a regression test to confirm the fix. — A mesma correção, dois destinatários. A recomendação vaga serve pro slide da diretoria; a remediação detalhada é a que o desenvolvedor consegue transformar em commit no mesmo dia.

Por que isso reprova numa auditoria de verdade

Cada vez mais empresa contrata pentest porque uma norma passou a exigir. No setor financeiro e no de saúde suplementar, entre outros, o teste de segurança periódico virou item de conformidade, e o relatório é a prova de que ele aconteceu. O detalhe que muita gente descobre tarde é que ter o PDF na mão não é o mesmo que ter uma prova que se sustenta. Um auditor competente não conta quantos achados o documento lista; ele pergunta como cada um foi comprovado e o que foi feito depois. É aí que o relatório de scanner reformatado desmonta.

Um documento que só lista CVE com nota CVSS não mostra que houve teste de intrusão, mostra que uma ferramenta rodou, o que qualquer um faz sozinho. Sem evidência reproduzível, o auditor não tem como confirmar que a falha era real e não um falso positivo do scanner. Sem severidade ajustada ao ambiente, não dá pra justificar por que um achado foi tratado como prioridade e outro não. Sem remediação rastreável, não há como ligar o achado à correção que veio depois. Os três elementos que fazem um relatório útil no dia a dia são exatamente os três que uma auditoria exige, e não é coincidência: os dois querem a mesma coisa, evidência de que o risco foi entendido e endereçado, não uma lista de que ele foi apenas listado.

Como avaliar o relatório antes de assinar o contrato

A boa notícia é que dá pra checar tudo isso antes de fechar. Peça um relatório de exemplo (anonimizado) a qualquer fornecedor que você esteja avaliando, um pedido normal e que fornecedor sério atende, e leia um achado inteiro com estes pontos na mão.

Cada achado sério traz a requisição e a resposta reais, ou os passos exatos pra reproduzir, não só um print e a assinatura que casou. Se você não conseguiria repetir o achado lendo o relatório, não é evidência.
As severidades são justificadas pelo seu ambiente (onde o ativo está, que dado guarda, se é exposto), não só o número CVSS copiado da ferramenta. Um relatório que sobe e desce a nota com explicação teve gente pensando.
A remediação diz onde e o que mudar, e como testar a correção, em linguagem que um desenvolvedor aplica. "Implemente controle adequado" não é remediação, é o problema repetido.
Aparecem achados de lógica de negócio (acesso indevido a objeto, bypass de fluxo, escalonamento por combinação de permissão), não só versão desatualizada e configuração. Relatório 100% CVE de versão é scan com capa.
O relatório distingue o que foi testado à mão do que foi apoiado por ferramenta, e informa escopo e horas. Um scan puro não tem essa distinção pra fazer.

Contratar pentest sem olhar o formato do relatório é comprar às cegas o único produto que você vai receber. Antes de escolher fornecedor, peça o modelo de entregável e cobre os três elementos: prova reproduzível, severidade no seu contexto e correção que o dev aplica. Se você está avaliando ou comprovando um fornecedor e quer um relatório que aguente auditoria em vez de só preencher o requisito, fale com a gente em vorvex.com.br/orcamento: a conversa começa pelo que você vai receber no fim, não pela cor da capa.

← Voltar ao blog