Pentest | Vulnerability Assessment | Gestão de Riscos
Pentest vs. Vulnerability Assessment: quando cada um é a resposta certa
Categoria: Pentest | Vulnerability Assessment | Compliance Nível: Iniciante a Intermediário Ambiente: Laboratório controlado — cenário totalmente anonimizado, sem dados reais de clientes
Introdução
Todo mês chega ao time de segurança uma proposta de "teste de vulnerabilidades" com preço baixo e relatório automático em 48 horas. Ao mesmo tempo, o auditor de PCI-DSS pergunta se o pentest anual já foi feito. Para quem não vive de segurança, a confusão é legítima: vulnerability assessment (VA) e penetration test (pentest) parecem a mesma coisa — ambos "procuram vulnerabilidades". Não são.
A diferença não é de preço, é de pergunta. O scan responde "quais CVEs conhecidas existem nesses ativos?". O pentest responde "o que um atacante consegue fazer, na prática, com o que existe — e o que isso custa para o negócio?". Uma organização madura precisa dos dois, em momentos diferentes, com propósitos diferentes. Este artigo explica a diferença em cenário anonimizado, mostra quando cada um se aplica e por que nenhum dos dois sozinho atende o que LGPD, PCI-DSS e ISO 27001 exigem.
1. O que é cada um (definições sem jargão)
Vulnerability Assessment (VA / scan de vulnerabilidades)
É uma varredura automatizada que compara versões de software e configurações de um alvo contra um banco de conhecimento de vulnerabilidades conhecidas (CVEs, plugins, bibliotecas). O entregável é uma lista priorizada por severidade (CVSS), com a indicação de qual CVE potencialmente afeta cada ativo.
- Pergunta que responde: "O que está desatualizado, mal configurado ou com CVE conhecida?"
- Como funciona: ferramenta roda na rede ou no host (Nessus, Qualys, OpenVAS, nuclei, scanners de SAST no código), compara com feeds de CVE, gera relatório.
- Velocidade: dias, quando não horas — depende do tamanho do escopo.
- Falso positivo: alto. O scan correlaciona versão com CVE, mas não confirma se a condição de exploração existe de fato (ex.: CVE que exige configuração específica, WAF bloqueando, feature desativada).
- Depende de inventário: um scan só enxerga o que ele consegue alcançar e reconhecer. Se o ativo não está no escopo ou a versão é customizada, fica cego.
Penetration Test (pentest)
É um teste manual, adversarial e com objetivo, executado por um profissional que pensa como atacante — com autorização escrita, escopo definido e regras de engajamento. O pentester usa ferramentas automatizadas como apoio (enumeração, fuzzing), mas o núcleo do trabalho é humano: encadear vulnerabilidades, testar lógica de negócio, tentar escalar privilégio, validar impacto real.
- Pergunta que responde: "O que um atacante consegue fazer com isso — e qual o impacto real para o negócio?"
- Como funciona: reconhecimento → modelagem de ameaça → exploração controlada → validação de cada achado com PoC reproduzível → relatório com evidência.
- Velocidade: semanas (típico 2-3 semanas para uma aplicação web).
- Falso positivo: baixo — todo achado é validado manualmente com prova de exploração antes de entrar no relatório.
- Depende de escopo e contexto: o valor está justamente no que o scanner não vê — lógica de negócio, fluxos de autenticação, encadeamento de falhas.
2. Cenário de laboratório: a "Alfa Retail"
Para tornar a diferença concreta, usamos um cenário fictício: a Alfa Retail, varejista com 400 lojas, e-commerce próprio e um sistema interno de CRM com dados de clientes (LGPD na cabeça da diretoria). O time de TI roda um scan trimestral com uma ferramenta de VA há dois anos. Ninguém questionou o processo — até o relatório do último scan sair "100% limpo" na semana em que um pentest de laboratório (autorizado, em ambiente de staging) encontrou o que o scan não viu.
O que aconteceu no cenário:
Achado 1 — [CRÍTICO] IDOR no CRM: o scanner não testa lógica de negócio
O scan varreu o CRM, encontrou a versão do framework sem CVE conhecida e seguiu em frente. O pentester, com uma conta de usuário comum, alterou o ID de um registro na URL e acessou a ficha completa de outro cliente — nome, CPF, telefone, histórico de compras. O backend confiava no ID enviado pelo cliente sem validar autorização.
- Por que o scan não viu: acessos indevidos por objeto (IDOR) não são CVE — são falha de lógica de autorização. Nenhum feed de CVE descreve "o sistema da Alfa valida IDs". Só um teste funcional, pensado de forma adversarial, encontra isso.
- O que o scan reportaria: nada. O relatório saiu "limpo".
- Mapeamento OWASP Top 10 (2021): A01 Broken Access Control.
Achado 2 — [ALTO] Encadeamento: upload de avatar → RCE no servidor
O scan identificou a versão do componente de upload como "sem CVE conhecida". O pentester descobriu que o upload aceitava extensões arbitrárias, enviou um arquivo com conteúdo executável e, combinado com a falta de segregação entre o diretório de upload e o servidor web, executou comandos no servidor.
- Por que o scan não viu: cada peça isolada parecia inofensiva (upload "validado" por extensão, diretório no mesmo host). O risco só existe no encadeamento das duas falhas — exatamente o tipo de raciocínio que um scanner não faz.
- Mapeamento OWASP Top 10 (2021): A03 Injection + A05 Security Misconfiguration (encadeado).
Achado 3 — [MÉDIO] Vazamento de dados em resposta de API
Um endpoint legítimo retornava, junto com o dado pedido, campos que a tela não usa: CPF completo do usuário logado e de terceiros, tokens internos de integração. O scan de infraestrutura não faz chamadas funcionais autenticadas; só o teste manual com a aplicação em uso encontrou o excesso de dados na resposta.
- Por que o scan não viu: o VA avalia o alvo "por fora" (banner, versão, porta). O excesso de dados em payload de API exige autenticação e conhecimento do fluxo de negócio.
- Mapeamento OWASP Top 10 (2021): A01 Broken Access Control (exposição excessiva de dados).
O resumo do cenário
| Achado | Scan (VA) | Pentest | Por quê |
|---|---|---|---|
| IDOR no CRM | Não viu | Encontrou | Falha de lógica, não de versão |
| Upload → RCE encadeado | Não viu | Encontrou | Risco existe na combinação |
| Excesso de dados em API | Não viu | Encontrou | Exige fluxo funcional autenticado |
| CVE conhecida em plugin | Viu | Confirma/valida | Comparação de versão vs. feed |
O scan não é inútil — ele é incompleto para o que a Alfa precisava: saber se um atacante conseguiria acessar dados de clientes. Para essa pergunta, só o teste manual serve.
3. Quando usar cada um (e quando os dois)
Use vulnerability assessment quando:
- Frequência alta, custo baixo: cobertura contínua entre pentests (ex.: scan mensal/trimestral, scan no CI a cada deploy).
- Inventário grande e dinâmico: rede com centenas de ativos, onde o primeiro passo é saber o que existe e o que está desatualizado.
- Triagem inicial: reduzir o universo antes do teste manual — o scan aponta candidatos a CVE que o pentester valida depois.
- Patch management: alimentar o processo de correção com priorização por CVSS e exposição.
Use pentest quando:
- A pergunta é "o que um atacante consegue fazer?" — não "o que está desatualizado?".
- Exigência de compliance: PCI-DSS Req. 11.4 (v4.0) exige pentest interno e externo anuais; LGPD Art. 46 exige medidas de segurança técnicas — que auditores e o DPO esperam ver evidenciadas por teste, não por scan.
- Aplicações com lógica de negócio: e-commerce, fintech, CRM, sistemas de pagamento — onde o risco está em fluxos, não em versões.
- Antes de mudanças significativas: lançamento de produto, nova integração, migração de arquitetura.
- Validação de controles: o pentest testa se WAF, IDS e patches realmente impedem a exploração — o scan só atesta que existem.
A combinação correta
Uma postura realista de segurança usa os dois em camadas:
[VA contínuo] → [triagem e patch] → [pentest periódico/anual] → [remediação] → [re-teste]
↑ │
└────────────────────── loop contínuo (cadência por risco) ←────────────────┘
O VA mantém a higiene básica entre os ciclos; o pentest valida se a higiene resiste a um atacante real. O erro mais comum não é escolher um — é tratar o scan como substituto do teste e descobrir a diferença em um incidente.
4. Por que o scan não atende compliance sozinho
Auditores e reguladores pedem evidência de teste, não evidência de varredura:
| Norma | Exigência | Por que scan sozinho não basta |
|---|---|---|
| LGPD Art. 46 | Medidas de segurança técnicas e administrativas aptas a proteger dados pessoais | A norma avalia eficácia, não presença de ferramenta. IDOR acessando CPF de clientes = medida ineficaz, mesmo com scan "limpo" |
| PCI-DSS Req. 11.4 (v4.0) | Teste de invasão (pentest) anual interno e externo + após mudanças significativas | O requisito nomeia penetration testing (11.4.2 interno / 11.4.3 externo), não scanning (que é a Req. 11.3 — varredura trimestral: 11.3.1 interna / 11.3.2 externa —, separada e adicional) |
| PCI-DSS Req. 6.3.1 / 11.3 (v4.0) | Processo de gestão de vulnerabilidades + varredura trimestral | O scan aqui é obrigatório — mas como camada contínua, complementar ao pentest |
| ISO 27001 A.8.8 | Gestão de vulnerabilidades técnicas | O controle espera identificação e tratamento de vulnerabilidades com evidência de teste |
| ISO 27001 A.8.29 | Teste de segurança em desenvolvimento | Teste de aplicações em DevSecOps — escopo funcional, não só versão de componente |
O ponto prático: o relatório de um pentest é assinado por um profissional, traz PoC reproduzível para cada achado e descreve impacto em linguagem de negócio — o que um auditor aceita como evidência. O relatório de scan é um inventário de risco potencial, útil para o time técnico, mas não responde "a vulnerabilidade é explorável?".
5. Como avaliar uma proposta de pentest (checklist para quem contrata)
Nem toda proposta chamada de "pentest" é um pentest. Antes de assinar:
- Escopo explícito — o que será testado (aplicações, APIs, rede, mobile), com quais acessos (blackbox/graybox/whitebox) e em qual ambiente (staging preferível).
- Metodologia declarada — OWASP WSTG/PTES como base, testes manuais de lógica de negócio previstos (não só "rodar ferramenta X").
- Evidência por achado — o relatório deve trazer PoC reproduzível (payload, passo a passo, screenshot) para cada vulnerabilidade.
- Profissional responsável — relatório assinado, com nome e senioridade; existe um humano por trás da análise.
- Validação de impacto — severidade classificada por contexto de negócio (CVSS é ponto de partida, não a resposta final).
- Re-teste incluído — verificação de remediação após correções (comum: 1 ciclo de re-teste no escopo).
- Prazo compatível — pentest de aplicação web leva semanas, não 48 horas. Entrega relâmpago é sinal de scan rebatizado.
6. Conclusão (e o que fazer na segunda-feira)
- Se você não tem scan: comece por ele — é a camada de higiene contínua e o custo é baixo.
- Se você tem scan e nenhum pentest: a pergunta "o que um atacante consegue fazer?" segue sem resposta. Programe o primeiro pentest nos ativos que movimentam dados sensíveis ou dinheiro.
- Se você tem os dois: verifique se o pentest cobre lógica de negócio e fluxos autenticados — se o relatório só lista CVEs, você contratou um scan mais caro.
No cenário da Alfa Retail, o scan "100% limpo" existia havia dois anos; o pentest de uma semana encontrou três falhas exploráveis em dados de clientes. A diferença não está na ferramenta — está na pergunta que cada um responde.
Este artigo descreve um cenário de laboratório totalmente fictício, construído para fins educacionais. Nenhum dado real de cliente foi utilizado. A exploração de vulnerabilidades em sistemas sem autorização explícita é ilegal.