Por que seu relatório de pentest está mentindo para você e o que fazer a respeito

Publicado pela Pentesty · Série para profissionais de segurança

Você contratou um pentester. Ele executou suas ferramentas, passou alguns dias no local ou trabalhando remotamente e entregou um PDF.

O PDF tem 147 achados.

Seu desenvolvedor olha, suspira e pergunta: "Quais destes realmente importam?"

Ninguém sabe. O pentester já está no próximo trabalho. O relatório fica em uma pasta. Nada é corrigido.

Se isso parece familiar, você não está sozinho. E o problema não é sua equipe. O problema é que a maioria dos relatórios de pentest prioriza a abrangência, em vez da clareza. Eles documentam tudo o que o scanner encontrou. Raramente dizem o que você deve fazer primeiro.

Este artigo explica por que isso acontece, como deveria ser um bom relatório e como obter mais valor da sua próxima avaliação de segurança, independentemente de quem a execute.

O problema dos falsos positivos de que ninguém fala

Quando um scanner de segurança é executado contra sua aplicação, ele não pensa. Dispara milhares de payloads, observa as respostas e sinaliza tudo o que parece suspeito.

O resultado? Ruído. Muito ruído.

Achados de injeção SQL em endpoints que exigem tokens de autenticação que o scanner nunca teve. Alertas de XSS em campos renderizados no servidor que nunca são refletidos para os usuários. Travessia de diretórios com "vulnerabilidades" em caminhos que retornam 404 para todos, inclusive para os atacantes.

Estudos mostram consistentemente que scanners automatizados produzem taxas de falsos positivos entre 30% e 70% dependendo da ferramenta e do alvo. Isso significa que, se seu relatório tem 100 achados, entre 30 e 70 deles podem não exigir nenhum esforço de correção.

Mas há um problema: você não sabe quais são.

A solução tradicional é ter um pentester sênior verificando manualmente cada achado. Isso leva tempo. É caro. E é por isso que pentests de verdade custam de US$ 15.000 a mais de US$ 50.000 e levam semanas para serem entregues.

O que as pontuações CVSS deixam de considerar

A maioria dos relatórios usa o CVSS, Common Vulnerability Scoring System, para comunicar a gravidade. Um achado recebe uma pontuação de 0 a 10. Crítico = vermelho. Alto = laranja. Médio = amarelo.

O CVSS é uma referência útil, mas tem uma limitação fundamental: pontua as vulnerabilidades isoladamente, ignorando seu ambiente.

Uma vulnerabilidade crítica de execução remota de código com CVSS 9,8 é assustadora, a menos que o serviço afetado só esteja acessível pela sua rede interna, atrás de uma VPN e sem exposição pública. Nesse contexto, ela pode ter baixa prioridade em comparação a um achado com CVSS 6,5 na sua página pública de login.

O contexto importa mais que o número.

Um relatório bem escrito faz mais do que pontuar vulnerabilidades. Ele as relaciona à sua superfície real de ataque e diz: considerando como este sistema está implantado, este é o risco realista para seu negócio.

Essa é a diferença entre informação e inteligência.

A anatomia de um relatório que realmente gera correções

Depois de anos trabalhando com equipes de segurança, o padrão é consistente: achados corrigidos rapidamente têm três características em comum.

Em vez de: "SQLi detectada. CWE-89. CVSS 9,1."

Os desenvolvedores precisam entender por que isso importa para priorizar a correção em relação ao backlog da sprint. Os responsáveis pelo negócio precisam entender o que pode acontecer para aprovar o orçamento de correção. Jargão de segurança sem contexto não leva as pessoas à ação.

Um bom achado inclui evidências suficientes para confirmar que a vulnerabilidade é real: uma captura de tela, uma requisição preparada, uma resposta observada. Sem transformar o relatório em um guia de exploração caso ele vaze.

O objetivo de uma PoC é comprovar que o problema é real, eliminando dúvidas, e ajudar os desenvolvedores a reproduzi-lo durante os testes da correção.

"Atualize a biblioteca" não é uma orientação executável.

Quanto mais próxima a recomendação estiver da alteração de código necessária, mais rápido ela será realizada.

A fase de reconhecimento: onde a maioria das ferramentas automatizadas deixa a desejar

Varredura não é pentest. A varredura é uma etapa dentro de um processo maior.

Antes de disparar um único payload, um atacante real dedica tempo ao reconhecimento: entender a arquitetura da aplicação, mapear seus fluxos de autenticação, identificar integrações com terceiros, enumerar subdomínios e procurar segredos expostos em repositórios públicos.

Essa fase de reconhecimento frequentemente revela os achados de maior impacto. Não porque as vulnerabilidades sejam mais graves, mas porque estão em lugares onde os scanners nunca procuram.

Um arquivo config.js enviado acidentalmente a um repositório público do GitHub. Um bucket S3 deixado aberto com permissões de leitura para qualquer pessoa. Um ambiente de homologação acessível em staging.yourcompany.com com credenciais padrão.

Isso não aparece nos resultados de um scanner do OWASP Top 10. Aparece quando alguém realmente pensa como um atacante.

As melhores abordagens automatizadas tentam reproduzir essa camada de raciocínio sobre os resultados do scanner, complementando o julgamento humano e perguntando: este achado existe em um contexto que permite explorá-lo na prática?

Como ler um relatório de pentest como um profissional

Seja você CTO, desenvolvedor ou engenheiro de segurança, este é um método prático para extrair sinal de um relatório denso.

O custo real de um pentest sobre o qual ninguém age

Avaliações de segurança têm um custo que vai além da fatura. Há o tempo da engenharia para preparar o ambiente de teste, coordenar acessos e participar das reuniões de apresentação. Há o custo de oportunidade dos engenheiros que deveriam estar construindo recursos, mas estão lendo um relatório de 200 páginas.

Se o relatório não se transforma em vulnerabilidades corrigidas, todo esse custo é perdido.

O retorno de um pentest não é o relatório. São as vulnerabilidades corrigidas antes que um atacante as encontre.

Tudo no processo, da definição do escopo ao formato do relatório e ao fluxo de correção, deve ser otimizado para esse resultado.

Uma observação sobre onde a IA se encaixa

A IA está mudando como os relatórios de segurança são gerados e consumidos. Ela assume as partes repetitivas e demoradas do fluxo de trabalho, complementando os pentesters: filtrar falsos positivos dos resultados do scanner, pontuar achados no contexto da implantação e traduzir descobertas técnicas para uma linguagem sobre a qual pessoas sem formação técnica consigam agir.

A questão interessante não é se a IA consegue executar um scanner. Consegue. A questão é se consegue raciocinar sobre o contexto, entendendo que um achado em um endpoint público de API é materialmente diferente do mesmo achado em um painel administrativo interno.

Estamos explorando exatamente esse problema na Pentesty. Nosso pipeline combina os mais de 8.000 modelos de vulnerabilidades do Nuclei com agentes de IA Claude que analisam cada achado no contexto, filtram falsos positivos, pontuam a possibilidade de exploração e geram um relatório em PDF pronto para apresentação à diretoria em menos de 10 minutos. Isso não substitui um trabalho manual aprofundado em um sistema complexo. É uma forma de obter cobertura séria de segurança para aquilo que a maioria das equipes nunca tem tempo de testar.

Se tiver curiosidade, você pode solicitar acesso antecipado aqui.

Tem dúvidas sobre metodologia de pentest ou análise de relatórios? Entre em contato pelo LinkedIn ou obtenha acesso antecipado à Pentesty.