"Já fazemos scan de vulnerabilidades, então não precisamos de pentest." A frase é comum e parte de um equívoco: as duas atividades respondem a perguntas diferentes. O scan pergunta quais falhas conhecidas existem no meu ambiente. O pentest pergunta o que um atacante consegue fazer com elas. Confundir as duas leva a pagar por um teste desnecessário ou a confiar em um relatório automático que nunca testou nada.
O que cada um faz
O scan de vulnerabilidades é uma varredura automatizada. Uma ferramenta identifica ativos, serviços e versões e compara o que encontra com bases de vulnerabilidades conhecidas e com verificações de configuração. É rápido, repetível e barato por execução, o que permite rodá-lo com frequência e sobre todo o parque. A contrapartida está nos limites: ele aponta a possibilidade de uma falha, gera falsos positivos e praticamente não enxerga erros de lógica de negócio, falhas de autorização entre usuários ou combinações de pequenas fraquezas que, juntas, abrem caminho para um ataque.
O pentest (teste de intrusão) é um exercício conduzido por pessoas, com escopo e regras acordados, que simula um atacante real. Os testadores usam ferramentas, inclusive scanners, mas o trabalho central é manual: validar se a falha é explorável, encadear achados, tentar escalar privilégios e mostrar até onde um invasor chegaria. O guia técnico do NIST para testes de segurança, o SP 800-115, faz exatamente essa distinção: a varredura identifica vulnerabilidades potenciais; o teste de intrusão valida se elas existem e qual é o seu impacto.
Em uma frase. O scan dá amplitude e frequência; o pentest dá profundidade e prova de exploração. Um não substitui o outro.
Quando usar cada um
Algumas situações típicas:
- Higiene contínua do parque. Scan recorrente, com cobertura de todos os ativos, internos e expostos à internet. É a base de qualquer programa de gestão de vulnerabilidades.
- Lançamento ou mudança relevante. Nova aplicação, nova integração, migração para nuvem ou reestruturação da rede pedem pentest antes ou logo depois de entrar em produção.
- Aplicações web e APIs críticas. Falhas de autenticação, controle de acesso e lógica de negócio raramente aparecem em scan. Aqui o pentest manual é o que encontra o problema.
- Exigência regulatória ou contratual. O PCI DSS, por exemplo, pede as duas coisas: varreduras internas e externas ao menos a cada três meses, as externas feitas por um ASV, fornecedor de varredura aprovado pelo PCI SSC (requisitos 11.3.1 e 11.3.2), e pentest interno e externo ao menos a cada 12 meses e após qualquer mudança significativa de infraestrutura ou aplicação (11.4.2 e 11.4.3).
- Validar controles. Quando a pergunta é "o firewall, o EDR e a segmentação resistem a um ataque real?", só um teste que tenta atacar responde.
Na prática, a maioria das organizações precisa dos dois, em cadências diferentes: scan sempre, pentest periódico e direcionado ao que mais importa.
Como escolher o pentest certo
Comece pelo escopo
Um pentest mal escopado gera um relatório que não responde à pergunta do negócio. Antes de pedir proposta, defina: quais ativos (perímetro externo, rede interna, aplicação web, API, aplicativo móvel, nuvem, Wi-Fi), o que está fora de escopo, janelas de teste, contatos de emergência e o que é proibido (negação de serviço, engenharia social, testes em produção em horário comercial). Esse acordo, chamado de regras de engajamento, protege as duas partes e deve estar por escrito.
Black box, gray box ou white box
- Black box. O testador começa sem informações internas, como um atacante externo. É o mais realista para o perímetro, mas parte do tempo vai em reconhecimento, e a cobertura tende a ser menor.
- Gray box. O testador recebe informações parciais, como credenciais de um usuário comum ou documentação básica. Equilibra realismo e cobertura e é a opção mais comum para aplicações, porque simula um cliente ou funcionário mal-intencionado.
- White box. Acesso amplo a arquitetura, configurações e às vezes código-fonte. É o mais profundo e eficiente para encontrar falhas, ao custo de menos realismo sobre o que um atacante externo veria.
Metodologia reconhecida
Pergunte qual metodologia o fornecedor segue e como ela aparece no relatório. As referências mais usadas são o NIST SP 800-115 (planejamento, descoberta, ataque e relatório), o OWASP Web Security Testing Guide para aplicações web, o OSSTMM, do ISECOM, voltado à medição operacional da segurança, e o PTES (Penetration Testing Execution Standard), que organiza o trabalho da pré-contratação ao relatório. Metodologia não é burocracia: é o que garante que dois testes do mesmo ambiente sejam comparáveis e que nada importante fique de fora por esquecimento.
Avalie quem vai testar
- Teste manual de verdade. Pergunte como o trabalho se divide entre ferramentas e análise manual. Saída de scanner reformatada não é pentest.
- Qualificação da equipe. Certificações com prova prática, como a OSCP, dizem mais sobre a capacidade de conduzir um teste do que certificações apenas teóricas.
- Experiência no seu escopo. Pentest de rede interna exige domínio de Active Directory; pentest de aplicação exige domínio de desenvolvimento web e APIs.
- Amostra de entregáveis. Peça um relatório de exemplo anonimizado e, se o teste for usado em auditoria, um modelo de carta de atestado.
O que deve vir no relatório
Um bom relatório de pentest traz:
- Sumário executivo. Em linguagem de negócio: o que um atacante conseguiria, quais ativos críticos estão em risco e o que fazer primeiro.
- Escopo e método. O que foi testado, quando, de que forma e o que ficou de fora.
- Achados com evidência. Cada falha com descrição, passos para reproduzir, evidências (capturas, requisições), ativos afetados e classificação de risco no contexto do ambiente.
- Cadeias de ataque. Como achados de severidade média se combinam em um comprometimento sério.
- Recomendações acionáveis. Correções específicas, não frases genéricas como "aplicar patches".
Exija o reteste. Pentest sem reteste termina com uma lista, não com risco reduzido. O reteste confirma que as correções funcionam e não abriram outros caminhos. O PCI DSS (requisito 11.4.4) exige que vulnerabilidades exploráveis encontradas no pentest sejam corrigidas e que o teste seja repetido para verificar as correções.
Como isso se encaixa na gestão contínua de vulnerabilidades
Pensar em "scan ou pentest" como decisão única é o erro de fundo. Os dois são entradas de um mesmo ciclo: identificar, avaliar, priorizar, tratar e verificar. O scan alimenta esse ciclo com volume e frequência. O pentest alimenta com profundidade e com a confirmação de quais falhas são realmente exploráveis no seu ambiente, o que é um dado valioso para a priorização. Para ordenar a fila de correções, vale combinar severidade, probabilidade de exploração e exposição, como discutimos em como priorizar vulnerabilidades com CVSS, EPSS e KEV.
O fluxo também corre no sentido inverso. Um achado de pentest que um scanner não detectou indica uma lacuna de cobertura: credenciais faltando na varredura, um ativo fora do inventário, uma classe de falha que precisa de outro controle. Tratá-las melhora o ciclo inteiro.
Por fim, o resultado precisa chegar à governança: auditorias de ISO 27001, PCI DSS e LGPD pedem cada vez mais evidência prática de que os controles funcionam, e o histórico de scans, pentests, correções e retestes é essa evidência.
Perguntas frequentes
Scan de vulnerabilidades substitui o pentest?
Não. O scan identifica falhas conhecidas em escala, mas não valida se elas são exploráveis nem encontra falhas de lógica, de autorização ou cadeias de ataque. O pentest faz isso, mas cobre um escopo menor e em momentos específicos. Os dois se complementam.
Com que frequência fazer pentest?
Uma referência de mercado é o PCI DSS: ao menos a cada 12 meses e após qualquer mudança significativa no ambiente. Aplicações críticas que mudam com frequência podem justificar testes mais próximos das entregas. O scan, por ser automatizado, deve rodar com muito mais frequência.
Qual modalidade escolher: black, gray ou white box?
Depende da pergunta. Para saber o que um atacante externo vê, black box. Para aplicações com usuários autenticados, gray box costuma dar o melhor equilíbrio. Para encontrar o máximo de falhas em um sistema crítico em pouco tempo, white box.
Fontes consultadas: NIST SP 800-115, Technical Guide to Information Security Testing and Assessment; OWASP Web Security Testing Guide; ISECOM, Open Source Security Testing Methodology Manual (OSSTMM 3); Penetration Testing Execution Standard (PTES); PCI DSS v4.0.1, requisitos 11.3 e 11.4 (varreduras de vulnerabilidade e testes de intrusão). Este artigo é educacional; consulte o texto oficial das normas antes de definir escopo e frequência dos seus testes.