A Anatomia de um Relatório de Pentest: O Que 394 Relatórios Públicos Revelam

Analisamos 394 relatórios públicos de teste de intrusão para responder a uma pergunta simples: como é, de verdade, esse documento depois que o teste termina? Relatórios públicos não são uma amostra aleatória do mercado. São uma vitrine, publicada de forma voluntária por empresas seguras o bastante do trabalho para assinar embaixo. Ainda assim, o formato dessa vitrine diz algo que vale a pena saber sobre como o setor produz o seu entregável central.

O que vem na caixa

O acervo reúne 82 empresas e fontes distintas, de boutiques de uma pessoa só a nomes como NCC Group e Trail of Bits. O relatório mediano tem 26 páginas, mas a variação é enorme: vai de 1 página a 157, com a metade central dos relatórios (do p25 ao p75) ficando entre 16 e 43 páginas. Tanto um memorando de uma página quanto um dossiê de 157 páginas contam como “um relatório de pentest” neste acervo. Não existe número de páginas padrão, porque não existe relatório padrão.

O que existe de padrão é um núcleo estreito. Escopo aparece em 88% dos relatórios e achados em 85%, o que os torna quase universais: as paredes estruturais do documento. Tudo depois disso vai se esvaindo numa ordem bem consistente: um sumário aparece em 69% dos relatórios, recomendações em 68%, metodologia em 65%, uma introdução em 57%.

Passado esse núcleo, a presença cai mais rápido do que a maioria dos profissionais imaginaria. Apenas 54% dos relatórios trazem uma seção explicitamente rotulada como sumário executivo, apesar de ser justamente a seção escrita para o leitor com menor probabilidade de ler o resto do documento. Uma conclusão aparece em 50%, um apêndice em 46%, um termo de isenção em 42%. Uma seção dedicada às ferramentas utilizadas — a parte que diria ao leitor como foi, na prática, a divisão entre varredura automatizada e teste manual — aparece em meros 10% dos relatórios, o menor índice entre todas as seções que acompanhamos.

Lido como uma sequência, o padrão não é aleatório: ele acompanha o quanto cada seção serve, de forma direta, à função central do entregável. Escopo e achados respondem “o que foi testado e o que você encontrou”, e as empresas raramente os deixam de fora. Tudo que vem depois disso — resumir para um leitor não técnico, explicar o processo, revelar o ferramental — é tratado como acabamento opcional, e não como parte obrigatória do formato.

Um relatório de pentest tem um esqueleto que toda empresa compartilha e um corpo que cada empresa monta de um jeito diferente. Escopo e achados são praticamente garantidos. Tudo que ajuda o leitor a confiar, contextualizar ou verificar esses achados é opcional, e é tratado assim na prática.

O ferramental conta uma história

Os metadados do PDF (os campos Producer e Creator gravados por qualquer software que tenha gerado o arquivo) oferecem uma segunda leitura, mais mecânica, de como esses relatórios são feitos. Não é um campo que alguém escreva pensando no leitor; é um subproduto do processo de exportação, o que faz dele um sinal bastante honesto do pipeline de produção por trás do documento.

Ao longo do acervo, o LaTeX responde por 84 relatórios, o LibreOffice ou OpenOffice Writer por 79, o Microsoft Word por 55, um pipeline de HTML para PDF via Chromium por 36, o Google Docs ou Skia por 27, o Apple Pages por 16 e o Apache FOP (um pipeline XSL-FO que renderiza XML estruturado num PDF finalizado) por 12. Mais abaixo na lista, iText ou Acrobat responde por 10 relatórios e o ReportLab por 2. Quarenta e dois relatórios trazem o macOS Preview nos metadados, o que significa que o arquivo foi aberto e salvo de novo depois da exportação original — muitas vezes a impressão digital de uma passada final de edição antes da publicação.

Some os editores de texto (Word, LibreOffice e Pages) e eles totalizam 150 relatórios. O LaTeX, a ferramenta que a maioria dos engenheiros apostaria como padrão do setor para um documento que precisa parecer técnico, responde por 84. Os editores de texto superam o LaTeX em quase dois para um.

Essa divisão não é uma nota de rodapé estilística. O LaTeX é, em grande parte, a ferramenta de empresas cujo trabalho se aproxima mais de um artigo técnico do que de um entregável para cliente: versionado, diagramado, feito para engajamentos em que o relatório precisa sobreviver ao escrutínio minucioso de um protocolo ou de uma prova. O Word e seus primos são as ferramentas de empresas que tratam o relatório como um documento de negócios: produzido sob prazo, no software que a equipe inteira já tem aberto. Nenhuma das duas abordagens, por si só, determina a qualidade do teste que está por baixo. Mas a ferramenta que uma empresa padroniza diz algo sobre como ela pensa o entregável que envia: se o relatório é encarado como um produto de engenharia ou como correspondência.

Toda empresa tem uma impressão digital de relatório

Assim que você agrupa os relatórios por quem os publicou, os dados de ferramental deixam de parecer ruído e passam a parecer uma assinatura. As empresas não escolhem um formato por engajamento. Elas montam um único pipeline de produção e passam todo relatório por ele.

A Cure53, a publicadora mais prolífica do acervo com 67 relatórios, usa LibreOffice Writer em 97% das vezes. A X41 D-Sec usa LaTeX em 100% das vezes; o NCC Group usa LaTeX em 90% dos seus 21 relatórios; a iSEC Partners em 81%. QuarksLab e Hackmanit também usam LaTeX em 100% das vezes cada uma — um agrupamento de empresas cujos engajamentos pendem para criptografia e hardware, onde o relatório precisa se sustentar como um artigo técnico.

A ponta produtizada do espectro é igualmente consistente. A Trail of Bits renderiza 68% dos seus 37 relatórios por um pipeline de HTML para PDF via Chromium, e a Consensys Diligence faz o mesmo com 100% da sua produção. A Radically Open Security vai ainda mais longe, gerando 80% dos seus relatórios via Apache FOP: os achados são escritos uma única vez em marcação estruturada, e o PDF é um artefato de build, não um arquivo montado à mão. E o padrão se mantém fora dos agrupamentos técnicos também: os relatórios da Doyensec são Apple Pages em 100% das vezes, os da 7ASecurity são Google Docs em 100% das vezes, e tanto a Hacken quanto a IncludeSecurity publicam exclusivamente via Microsoft Word.

É assim que a padronização de ferramental se parece quando você a rastreia empresa por empresa: uma decisão tomada uma vez, no nível do pipeline, que depois aparece de forma consistente ao longo de dezenas de engajamentos — não uma ferramenta escolhida por projeto, mas um padrão da casa. Auditores de criptografia e hardware se agrupam no LaTeX. Empresas que produtizaram o relatório (Trail of Bits, Consensys, Radically Open Security) renderizam a partir de código ou marcação em vez de compor cada relatório na mão. Isso reflete tanto a cultura de engenharia quanto a própria escrita: algumas empresas tratam o relatório como um artefato que vale a pena ser engenheirado, não apenas redigido. Dada uma pilha de relatórios anonimizados, só o campo Producer já permitiria devolver a maioria deles à sua empresa de origem: o metadado está mais perto de uma assinatura da casa do que o logotipo na capa.

O que o formato silenciosamente omite

As seções que são raras neste acervo são justamente as que fecham o ciclo entre um achado e sua resolução. Apenas 17% dos relatórios incluem uma seção de reteste ou verificação, o que significa que, para a grande maioria dos engajamentos públicos, o entregável termina em “eis o que encontramos”, sem nenhuma resposta documentada sobre se aquilo foi corrigido.

A severidade não se sai muito melhor. O CVSS aparece em apenas 11% dos relatórios por busca mecânica de texto, e uma leitura semântica mais profunda coloca o número abaixo de 8%. Uma seção dedicada à classificação de risco ou à definição de severidade — a parte que explica como uma empresa decidiu que “Crítico” significa o que significa — aparece em meros 28% dos relatórios. A maioria das empresas não está deixando a severidade sem explicação; está explicando em prosa, engajamento por engajamento, de um jeito que raramente sobrevive à comparação entre fornecedores. Um “Crítico” de uma empresa e um “Crítico” de outra não têm garantia de descrever o mesmo nível de risco.

O resto da cadeia de evidências é irregular na mesma direção. Os relatórios são confiavelmente bons em dizer ao leitor onde o problema mora (93% nomeiam a localização afetada com precisão) e a maioria inclui passos de reprodução (80%) ou código de prova de conceito (67%). Menos deles carregam o artefato que permitiria ao leitor verificar a afirmação de forma independente: uma requisição/resposta bruta ou um trace no nível do protocolo aparece em 33% dos relatórios, e capturas de tela em meros 24%. O relatório diz onde está a falha e como acioná-la de forma mais confiável do que mostra a evidência que o leitor poderia checar sem refazer o teste.

Nada disso reflete trabalho desleixado. Estes são, por definição, os relatórios que as empresas escolheram publicar, de empresas seguras o bastante da própria produção para assinar embaixo. É exatamente isso que torna a lacuna digna de menção: significa que até os melhores exemplos públicos do formato subdocumentam as duas coisas de que um leitor mais precisa seis meses depois: se um achado foi de fato verificado como corrigido, e por que ele foi classificado da forma como foi.

Uma nota de metodologia

Esta análise é mecânica, não editorial. Todos os 394 relatórios foram processados quanto à estrutura física: contagem de páginas, cabeçalhos de seção e idioma. A ferramenta de autoria foi inferida a partir dos campos Producer e Creator dos metadados do PDF, o que é confiável para identificar o pipeline de renderização, mas não diz nada sobre quem fez o teste ou a redação por baixo, e nada sobre qualidade. A detecção de seção e idioma rodou sobre os 352 relatórios legíveis por máquina do acervo e foi automatizada, não conferida à mão seção por seção, de modo que casos-limite de rotulagem ou formatação terão passado despercebidos. Onde citamos um número semântico (o valor de CVSS abaixo de 8%, por exemplo), ele vem de uma leitura automatizada por um grande modelo de linguagem de 349 relatórios: um sinal de direção, não uma auditoria humana certificada. Tratamos esses números como evidência de um padrão, não como um censo preciso. O acervo em si é o repositório public-pentesting-reports, mantido por Julio Cesar Fort, da Blaze Information Security.

O que isso deixa para nós construirmos

A lacuna que estes dados expõem não está no teste. Está no que o formato carrega adiante. Escopo, achados, o raciocínio de severidade e o estado de reteste são exatamente as coisas de que um leitor precisa para confiar num relatório e agir sobre ele — e são também as coisas que mais dependem de o redator específico ter lembrado de incluí-las. Estamos construindo a Tandera para que essa estrutura seja capturada como dado desde o início: escopo, achados, raciocínio de severidade e estado de reteste, todos registrados à medida que o engajamento acontece, para que sobrevivam até o entregável final em vez de depender de quais seções uma empresa lembra de escrever.

A Tandera estará aberta a todos a partir de 1º de setembro: um plano gratuito, sem cartão. No mês de lançamento, os planos anuais têm 30% de desconto (SOLO $700, PRO $3,500), com garantia de reembolso de 7 dias, usando o código ANATOMY30. Até lá, entre na lista de espera: [TODO: waitlist URL].