Pentest vs Scan · 9 min

Pentest vs Vulnerability Scan: A Diferença Real que Auditor Reconhece

"Faço pentest, mas o cara entrega só uma lista de CVE com screenshot do Nessus." Essa é a queixa mais repetida em call de RFP em 2025-26. Existe uma confusão proposital no mercado entre vulnerability scan (varredura automatizada) e penetration test (simulação adversarial com mãos humanas). Esta página separa os dois e mostra por que auditor SOC 2 / ISO 27001 / PCI-DSS sabe distinguir — e recusa.

⟳

Scan = assinatura

Compara o ambiente contra um banco de CVE conhecidas. Roda em horas, custa centenas, ignora 100% da lógica de negócio.

⌘

Pentest = adversário

Simula atacante real com Threat Modeling, encadeamento de falhas, Post-Exploitation. Roda em semanas, custa dezenas de milhares.

▤

Compliance pede pentest

SOC 2 CC4.1, ISO 27001 A.8.8, PCI-DSS 11.4, BACEN 4.893 — todos pedem teste manual com cadeia de exploração documentada.

1. O que cada um faz, na prática

Vulnerability scan roda Nessus, Qualys, Tenable.io, OpenVAS ou similar contra alvos definidos por IP/URL. Bate cada serviço contra um banco de assinaturas, identifica versão vulnerável de software conhecido, gera relatório CVE-by-CVE com CVSS automático. Tempo médio: 4-24 horas. Resultado típico: lista de 200-2.000 findings, dos quais 30-40% são falso-positivo, 50-60% são informativos, e ~10% merecem ação.

Penetration test manual segue metodologia (PTES, OWASP Testing Guide v4.2, NIST SP 800-115). Inclui Threat Modeling, Intelligence Gathering, exploração ativa de falhas validadas, Post-Exploitation (lateral movement, persistência simulada) e relatório com PoC reproduzível por finding. Tempo médio: 3-8 semanas. Resultado: 15-60 findings reais, cada um com cadeia de exploração documentada.

2. O que scanner não enxerga (e nunca vai enxergar)

Toda a categoria de falha de lógica é invisível para scanner por definição — depende de entender intent do negócio:

• IDOR / BOLA — acessar prontuário/pedido/conta de outro usuário trocando o ID na URL. Scanner não tem como saber "este ID é de outro tenant".
• Race conditions — sacar saldo duas vezes em paralelo, aplicar cupom 3x simultaneamente, induzir overdraft. Demanda timing manual.
• Encadeamento de falhas — XSS baixo + CSRF baixo + endpoint privilegiado = takeover de admin. Scanner vê 3 médios isolados.
• Lógica de pricing/cupom/cashback — abuso de regra de negócio que não viola código, viola intenção.
• Multi-tenancy bypass — vazar dados entre clientes do mesmo SaaS.
• OAuth/SAML mal configurado — redirect_uri aberto, state não validado, JWT trocado por none.
• Privilege escalation horizontal — papel "vendedor" virando "gerente regional" por manipulação de claim.

Esses são exatamente os findings que geram impacto real e os que auditor pede para ver no relatório. Nenhum sai de scanner.

3. Como auditor distingue na hora

Auditor experiente abre o relatório e procura quatro coisas. Se faltar uma, é scan rotulado de pentest:

1. Threat Modeling escrito — quais atores de ameaça foram considerados, quais TTPs (MITRE ATT&CK) foram priorizados, quais ativos críticos foram mapeados. Scanner não faz.
2. Cadeia de exploração — uma narrativa do "do A consegui chegar até X" com etapas reproduzíveis. Scanner entrega findings isolados.
3. PoC reproduzível por finding — request HTTP, payload, screenshot, comando exato. Scanner cola a referência CVE.
4. Post-Exploitation — o que conseguiu fazer depois de comprometer (lateral movement, exfiltração simulada, persistência). Scanner para na detecção.

Sem esses quatro, o relatório vira indicador de scan disfarçado. SOC 2 Type II reprova. ISO 27001 audit reprova. PCI-DSS QSA reprova. BACEN questiona em fiscalização.

4. Quando scan é útil

Scanner tem lugar legítimo: cobertura contínua entre pentests anuais. Pipeline DevSecOps com Snyk/Dependabot/Trivy/Nuclei rodando em PR e produção é higiene mínima. Vulnerability management baseado em ASM (Attack Surface Management) com Detectify/Intrigue/Spyse mantém o radar aceso 365 dias.

O erro é tratar isso como entregável de pentest — ou comprar pacote "fechadinho" que mascara scan recorrente como teste anual de invasão.

5. Como pedir o relatório certo

Antes de assinar contrato, peça ao fornecedor:

• Amostra anonimizada de relatório anterior (índice + 2 findings completos);
• Lista de metodologia operada (PTES + OWASP + NIST + MITRE);
• Quem assina o relatório — pentester com CV verificável, não "equipe técnica";
• Estimativa de horas por fase (Pre-engagement, Recon, Threat Modeling, Vuln Analysis, Exploitation, Post-Exploitation, Reporting);
• Política de retenção de dados pós-encerramento.

Quem fornece scan vai recuar nesses pedidos. Quem opera pentest sério entrega antes de você terminar de pedir.

FAQ

Scanner pode substituir pentest em algum cenário?

Não em compliance (SOC 2, ISO 27001, PCI-DSS, BACEN), não em validação para auditor, não para descobrir lógica de negócio. Scanner é útil como cobertura contínua entre pentests anuais — não como entregável de pentest.

Posso pedir 'pentest barato' para passar no auditor?

Pode pedir. Pode receber um PDF chamado "relatório de pentest". E pode ser reprovado pelo auditor quando ele perguntar por Threat Modeling, Post-Exploitation e PoC reproduzível — itens que scan disfarçado não tem.

Quanto custa cada um?

Vulnerability scan recorrente: R$ 800-3.000/mês por ambiente. Pentest manual sério: R$ 35-150 mil por engajamento, conforme escopo. Quem cobra R$ 8 mil por "pentest" está vendendo scan.

Vocês usam scanner?

Sim, na fase 4 do PTES (Vulnerability Analysis). Burp Pro, Nessus, Nuclei como insumo de descoberta. Cada hit é validado manualmente — 60-80% dos críticos/altos são falso-positivo até confirmação manual.

Quero pentest, não scan Ver metodologia PTES →