O que é pentest? Tipos, escopo e o que esperar do relatório

Existe uma frase que resume por que o pentest existe: uma lista de vulnerabilidades não prova risco; um invasor dentro do banco de dados, sim.

Varredura automática é barata, rápida e útil — e devolve uma lista de possibilidades. Muita coisa nessa lista nunca seria explorável no seu ambiente real, por conta de uma configuração, de um controle compensatório ou de uma dependência que não existe. E, na direção contrária, a varredura não vê o que mais importa: a cadeia de três falhas medianas que, juntas, dão acesso administrativo.

O teste de intrusão existe para responder à pergunta que a automação não responde: até onde alguém realmente chegaria?

A tese em uma frase: o valor do pentest não está na lista de achados — está na demonstração de impacto, e é por isso que relatório sem evidência de exploração é varredura com capa bonita.

Pentest x varredura: a diferença que muda o preço

As duas coisas são complementares, não substitutas — e a ordem certa é conhecida: varredura contínua primeiro, pentest depois. A varredura sustenta o processo de gestão de vulnerabilidades; o pentest responde ao que sobra.

Se você contratar pentest com a gestão de vulnerabilidades ainda inexistente, o relatório vai listar sistemas desatualizados e serviços expostos — informação que uma ferramenta gratuita daria, por uma fração do custo.

Os três tipos, e como isso afeta o resultado

Caixa preta. O time recebe apenas o alvo — um domínio, um IP — e nada mais. Simula o atacante externo genuíno. É o mais realista e o menos eficiente por hora contratada, porque boa parte do tempo vai para reconhecimento que você poderia ter entregue de graça.

Caixa cinza. O time recebe credencial de usuário comum e alguma informação de arquitetura. É o formato mais contratado, e o mais próximo do cenário realista mais perigoso: o invasor que já conseguiu uma conta qualquer — por phishing ou por infostealer — e quer escalar.

Caixa branca. Acesso a código, arquitetura, credenciais e documentação. Rende mais achados por hora, porque o tempo vai inteiro para a análise. É o melhor custo-benefício quando o objetivo é encontrar o máximo de problemas.

A escolha depende do que você quer responder. "Somos invadíveis de fora?" pede caixa preta. "Onde estão nossos problemas?" pede caixa branca.

Vale citar dois primos próximos: o Red Team é um exercício mais longo e furtivo, que testa também a capacidade de detecção e resposta da sua equipe — só faz sentido se você já tem alguém monitorando. E o bug bounty é contínuo e pago por achado, útil para produto digital maduro, complementar e não substituto.

O que precisa estar no contrato

Esta seção evita a maior parte dos problemas.

Autorização por escrito. Não é formalidade: testar sistema sem autorização é crime, mesmo com boa intenção. E, se a infraestrutura é de terceiro — provedor de nuvem, hospedagem —, verifique as regras dele. A maioria permite teste no que é seu, com restrições explícitas.

Escopo, com o que está de fora nomeado. Quais domínios, IPs, aplicações e APIs. E o que não pode ser tocado: sistema legado frágil, integração com parceiro, ambiente de produção crítico.

Janela e canal de parada. Horário de execução e um telefone que interrompe tudo em minutos. Sistemas frágeis caem com pouco, e é melhor combinar isso antes do que descobrir às 15h de uma terça.

Regras de engajamento. Engenharia social contra funcionários entra? Negação de serviço entra? (Quase sempre não.) Exfiltração de dado real ou apenas prova de acesso? Recomendo prova de acesso: não há razão para o consultor sair com dado de cliente.

Qualificação de quem executa. Peça o perfil dos profissionais e exemplo de relatório anonimizado. Isso separa quem faz teste de quem roda scanner.

Reteste incluído. Depois das correções, alguém precisa confirmar que fecharam. Se não estiver no contrato, será cobrado à parte no pior momento.

Como ler o relatório

A metodologia de referência para aplicação web é o OWASP Web Security Testing Guide — vale perguntar ao fornecedor se ele a segue.

Um relatório bom tem quatro partes, e a ausência de qualquer uma é sinal de alerta:

1. Sumário executivo que uma pessoa não técnica entende, com o risco expresso em consequência de negócio — não em nota CVSS.
2. Achados priorizados, cada um com evidência da exploração: comando, captura de tela, caminho percorrido. Achado sem evidência é hipótese.
3. Caminhos de ataque encadeados — a parte mais valiosa. "Falha A dá usuário, falha B escala privilégio, falha C alcança o banco." É isso que a automação nunca produz.
4. Recomendações acionáveis, com correção definitiva e mitigação temporária. "Aplicar boas práticas" não é recomendação.

E dois sinais de que você recebeu varredura com capa: muitos achados de severidade informativa enchendo volume, e nenhuma prova de exploração em nenhum item.

Um detalhe que gera frustração e é normal: um pentest bom pode ter poucos achados. Se o ambiente está maduro, o relatório é curto. Contratar por quantidade de achados cria o incentivo errado.

Depois do relatório

É aqui que a maioria do valor se perde.

Corrigir por caminho de ataque, não item a item. Fechar a primeira falha da cadeia costuma neutralizar as três.

Registrar o que não vai ser corrigido, com mitigação, prazo e responsável. Achado sem decisão registrada é risco esquecido.

Retestar. Sem confirmação, você tem a impressão de ter corrigido.

Alimentar o processo. Se o pentest achou uma classe de problema — validação de entrada, permissão excessiva, segredo em repositório —, procure o mesmo padrão no resto do parque. É o que transforma um relatório num aprendizado.

Quando pentest não é a prioridade

Sendo franco, porque o mercado empurra na direção contrária:

• Se você não sabe o que está exposto à internet, comece pelo inventário.
• Se não há processo de patch, o relatório vai dizer exatamente isso.
• Se não há MFA nem backup testado, o dinheiro rende mais aí.
• Se ninguém vai corrigir, o relatório vira documentação do problema — e, em caso de incidente, prova de que você sabia.

Esse último ponto merece atenção jurídica: relatório de pentest não corrigido é evidência de conhecimento prévio. Ter o documento e ignorá-lo é pior do que não tê-lo.

Quando faz sentido: exigência de cliente ou de norma, aplicação nova indo para produção, mudança relevante de arquitetura, ou quando o básico já está em ordem e a pergunta virou "o que sobra?".

O ponto que fica

Pentest é caro porque depende de gente boa, e gente boa é escassa. É por isso que o mercado se encheu de "pentest" que é scanner com relatório — mesma capa, um décimo do custo, quase nenhum valor.

A forma de não cair nisso é saber o que você está comprando: evidência de exploração e caminhos encadeados. Se o relatório não tem isso, você comprou uma varredura.

E vale a pergunta antes de assinar: se o teste encontrar dez problemas sérios, existe alguém com tempo e orçamento para corrigi-los nos próximos três meses? Se a resposta for não, o dinheiro rende mais em corrigir o que você já sabe que está errado.