Vou dizer algo que pode surpreender depois de 121 aulas sobre técnicas de ataque: o relatório é o produto mais importante de um pentest. Todo o trabalho técnico — o reconhecimento, a exploração, a escalação — é inútil para o cliente se não for comunicado de forma que ele possa entender e agir. O relatório é onde as horas de hacking viram valor real. Um pentester tecnicamente brilhante que escreve relatórios ruins é um profissional medíocre; um pentester competente que comunica com clareza é inestimável. Esta aula ensina a arte frequentemente subestimada de transformar achados técnicos em valor acionável. É, talvez, a aula mais importante do bloco profissional.

O cliente só vê o documento

Comece pela verdade central que reorienta a perspectiva: o cliente experimenta o pentest quase inteiramente através do relatório. Ele não viu você trabalhar; ele recebe um documento. Esse documento é o pentest, do ponto de vista dele — a totalidade do valor que ele pagou, corporificada em texto. Se o relatório é confuso, incompleto, ou não acionável, o pentest falhou para o cliente, independentemente de quão impressionante foi tecnicamente. Isso inverte a intuição do iniciante (que valoriza o hack e vê o relatório como burocracia chata): na verdade, o hack é o meio e o relatório é o produto. Profissionais experientes dedicam uma parcela enorme do tempo do engajamento ao relatório, porque sabem que é ali que o valor se concretiza.

Dois leitores, duas leituras

Um bom relatório tem uma estrutura de dois públicos, e entender isso é a chave. Há o sumário executivo (executive summary), escrito para a liderança (executivos, gestores) — pessoas que decidem orçamentos e prioridades, mas que não são técnicas. Ele deve comunicar, em linguagem de negócio e sem jargão, o quadro geral: qual o nível de risco geral, quais os problemas mais críticos, qual o impacto potencial para o negócio (perda financeira, vazamento de dados, interrupção, dano reputacional, implicações de LGPD), e o que fazer a respeito em termos estratégicos. O executivo não quer saber como você explorou uma SQLi; quer saber "estamos em risco? quão grave? quanto custa e o que priorizar para resolver?". E há os detalhes técnicos, escritos para a equipe técnica (a TI, os desenvolvedores) que vai corrigir as falhas — com toda a profundidade: cada vulnerabilidade, como reproduzi-la, evidências, e como corrigi-la. Um relatório que erra o público (jargão técnico para o executivo, ou vagueza para o técnico) falha em comunicar. Escrever para dois públicos distintos no mesmo documento é a habilidade central do relatório.

Anatomia de um achado acionável

Cada achado técnico, no corpo do relatório, deve ser documentado de forma completa e acionável. Os elementos essenciais de um bom achado: uma descrição clara da vulnerabilidade (o que é); a severidade/risco (tipicamente com CVSS — aula CVE, CVSS e CWE: a linguagem das vulnerabilidades — mas contextualizada ao negócio: uma falha "média" no CVSS pode ser crítica se está no sistema mais sensível); a localização (onde exatamente está — qual sistema, qual parâmetro); os passos para reproduzir (como confirmar a falha — crucial para o cliente validar e para os desenvolvedores entenderem); a evidência (screenshots, saídas, provas do impacto — mas sem dados sensíveis reais expostos desnecessariamente no relatório); o impacto (o que um atacante conseguiria — traduzido em termos de risco de negócio, não só técnico); e — o mais importante para o cliente — a remediação (como corrigir, de forma clara e específica). Um achado sem remediação clara é uma reclamação, não uma ajuda; o cliente quer saber o que fazer.

Cinquenta vulnerabilidades sem ordem não são um plano

A priorização é o que torna o relatório acionável na prática. Uma lista de 50 vulnerabilidades sem ordenação paralisa o cliente — ele não sabe por onde começar. O bom relatório prioriza: ordena os achados por risco real (severidade × impacto × probabilidade × contexto do negócio), destacando o que deve ser corrigido primeiro. Isso respeita a realidade de que o cliente tem recursos limitados e precisa alocá-los onde mais importam. Um relatório que diz "corrija estas 5 coisas primeiro, elas representam 80% do seu risco" é infinitamente mais útil que uma lista indiferenciada de 50 itens. A priorização transforma dados (uma lista de falhas) em orientação estratégica (o que fazer, em que ordem).

O valor não está em achar, está em comunicar

O ponto conceitual que cristaliza o bloco profissional: o valor de um pentest não está em encontrar vulnerabilidades, mas em capacitar o cliente a reduzir seu risco — e o relatório é o instrumento dessa capacitação. Isso reconecta com a ideia de que o pentest é um serviço de valor, e não uma demonstração técnica, e com a lição ética do curso inteiro (o hacking ético existe para ajudar, aula Por que o hacking ético existe e o que ele quer de você). O relatório é onde a habilidade técnica se converte em benefício real para a organização — onde "eu consegui hackear" vira "veja como se proteger". Dominar a escrita de relatórios é tão parte de ser um pentester profissional quanto dominar o Metasploit; muitos subestimam isso e limitam suas carreiras por escreverem mal, enquanto os que comunicam com excelência se destacam. A comunicação é metade da profissão.

Para que a organização usa o relatório depois

Do lado defensivo e prático, o relatório serve à organização de várias formas que vale reconhecer: é a base para a remediação (a equipe usa os achados e remediações para corrigir); é um registro (para compliance, auditoria, e comparação com testes futuros — medir progresso); e é uma ferramenta de comunicação de risco (que ajuda a segurança a justificar investimentos à liderança — um bom sumário executivo pode desbloquear o orçamento que a defesa precisava). Para o pentester, as diretrizes de um bom relatório: conheça seus públicos (executivo e técnico), seja claro e sem jargão onde apropriado, priorize rigorosamente, torne cada achado acionável (sempre com remediação), documente com evidência (mas proteja dados sensíveis), e escreva profissionalmente (um relatório com erros e desorganização mina a credibilidade de todo o trabalho técnico). A lição culminante: o relatório é onde o pentest cumpre seu propósito — e escrevê-lo bem é o que transforma um hacker habilidoso num profissional de segurança valioso.

Fontes e leituras recomendadas

  • public-pentesting-reports — coletânea de relatórios reais publicados por Bishop Fox, NCC Group, Trail of Bits, Cure53 e outros
  • PTES — seção de reporting
  • The Hacker Playbook e Penetration Testing (Georgia Weidman) — capítulos de relatório
  • Guias sobre comunicação de risco de segurança para executivos

Exercícios

  1. Por que se diz que "o relatório é o produto mais importante de um pentest"?

    ✓ Resposta:

    Porque o cliente experimenta o pentest quase inteiramente através do relatório — ele não viu o trabalho, recebe um documento que, para ele, é a totalidade do valor pago. Se o relatório é confuso ou não acionável, o pentest falhou para o cliente, independentemente da qualidade técnica; o valor só se concretiza na comunicação.

  2. Explique a estrutura de "dois públicos" do relatório e o que cada seção deve comunicar.

    ✓ Resposta:

    Há o sumário executivo, para a liderança não técnica — comunica em linguagem de negócio o nível de risco geral, os problemas mais críticos, o impacto para o negócio e o que priorizar. E os detalhes técnicos, para a equipe que vai corrigir — com profundidade: cada vulnerabilidade, como reproduzi-la, evidências e como corrigi-la. Cada seção fala a linguagem de seu público.

  3. Cite os elementos essenciais que um bom achado técnico deve conter.

    ✓ Resposta:

    Descrição clara da vulnerabilidade, severidade/risco (CVSS contextualizado), localização exata, passos para reproduzir, evidência (sem expor dados sensíveis desnecessariamente), impacto (em termos de risco de negócio) e remediação (como corrigir, de forma clara e específica).

  4. Por que a priorização torna o relatório acionável, e qual o problema de uma lista indiferenciada de vulnerabilidades?

    ✓ Resposta:

    Porque o cliente tem recursos limitados e uma lista longa e indiferenciada o paralisa — ele não sabe por onde começar. A priorização ordena os achados por risco real, indicando o que corrigir primeiro (ex.: "estes 5 itens são 80% do seu risco"), transformando uma lista de falhas em orientação estratégica acionável.

  5. Como o relatório reconecta com a lição ética central do curso (o hacking ético existe para ajudar)?

    ✓ Resposta:

    Reconecta porque o valor do pentest não é encontrar falhas, mas capacitar o cliente a reduzir seu risco — e o relatório é o instrumento disso. É onde "eu consegui hackear" vira "veja como se proteger", concretizando o propósito do hacking ético de ajudar a organização a se defender.