Comparativos de scanners costumam ser folder de marketing disfarçado. Este benchmark segue metodologia reprodutível: 20 aplicações reais brasileiras (com autorização escrita dos donos), 8 ferramentas testadas em condições idênticas, mesmas métricas para todas. A planilha completa fica aberta para revisão.

Metodologia

Amostra de aplicações

• 20 apps brasileiros em produção ou pré-produção.
• 10 em Node.js (majoritariamente Nest/Express), 8 em PHP (Laravel/Symfony), 2 em Python (Django/FastAPI).
• Setores: 4 fintech, 5 e-commerce, 3 healthtech, 4 SaaS B2B, 2 mídia, 2 educação.
• Superfície média: 47 endpoints REST, 3 páginas com formulário, 1 fluxo de autenticação.

Ground truth

Cada aplicação passou por pentest manual profundo prévio (16 a 40h por app) para estabelecer inventário de vulnerabilidades reais. Total: 312 vulnerabilidades confirmadas — 41 críticas, 89 altas, 132 médias, 50 baixas.

Ferramentas testadas

1. Varredura (nossa)
2. Ferramenta A — DAST comercial líder de mercado global
3. Ferramenta B — DAST open-source (OWASP ZAP em modo autenticado)
4. Ferramenta C — SaaS DAST especializado em API
5. Ferramenta D — plataforma nacional concorrente
6. Ferramenta E — scanner IaC + web
7. Ferramenta F — DAST commercial focado em performance
8. Ferramenta G — DAST open-source com heurística ML

Os nomes reais das ferramentas 2 a 7 estão na planilha aberta (evitamos citar aqui para não virar tabela de fabricante contra fabricante fora de contexto). A ferramenta B é o ZAP com scripts autenticados customizados.

Condições idênticas

• Mesma URL alvo por ferramenta.
• Mesmo perfil de autenticação (cookie ou token JWT, dependendo do app).
• Sem "tuning por app" além do login — como o cliente médio usaria.
• 6h de teste por app por ferramenta (168 combinações), rodadas em paralelo em janelas de baixo tráfego.

Métricas

• TPR (True Positive Rate): vulnerabilidades encontradas ÷ vulnerabilidades reais.
• FPR (False Positive Rate): findings falsos ÷ total de findings reportados.
• Cobertura OWASP: fração dos 10 do OWASP 2026 detectada em ao menos 1 caso.
• Velocidade: tempo médio para completar o scan (min).
• Ruído por app: número médio de findings por app (indicador prático de trabalho de triagem).

Resultados

| Ferramenta | TPR | FPR | Cobertura OWASP | Velocidade (min) | Findings/app | |------------|-----|-----|------------------|------------------|--------------| | Varredura | 78% | 6% | 10/10 | 41 | 18 | | A (líder global) | 74% | 12% | 10/10 | 62 | 27 | | B (ZAP autenticado) | 51% | 19% | 8/10 | 48 | 22 | | C (API-first) | 69% | 8% | 9/10 | 38 | 15 | | D (nacional) | 58% | 14% | 9/10 | 51 | 24 | | E (IaC + web) | 45% | 9% | 7/10 | 55 | 19 | | F (performance) | 61% | 11% | 9/10 | 33 | 17 | | G (ML heurística) | 55% | 22% | 8/10 | 44 | 31 |

Análise por categoria

Vulnerabilidades críticas (n=41):

• Varredura e A detectaram 34 e 33 respectivamente.
• Diferença veio majoritariamente em SSRF blindado e IDOR em endpoints aninhados. Se o assunto é SSRF, vale revisar a anatomia clássica.

Vulnerabilidades OWASP LLM: só Varredura, A e C testam parte da matriz LLM. Cobertura ainda parcial em toda a indústria (LLM01 e LLM04 são mais fáceis; LLM07 e LLM10 quase ninguém detecta bem).

Autenticação: todos aceitaram cookie ou JWT. Fluxos com OAuth (5 apps) foram desafio: B, E, F precisaram de setup manual; Varredura, A, C, D suportaram nativamente.

Ruído: FPR alto se traduz em custo real. Ferramenta G, com 31 findings/app e 22% de FPR, gera ~7 falsos por app — 140 falsos no total, que consomem 30h/mês de triagem. Ferramenta com FPR baixo economiza tempo do time de segurança.

Onde cada uma brilha

• Varredura: melhor TPR combinado com FPR baixo. Cobertura OWASP completa. Boa velocidade.
• A (líder global): cobertura completa, mas mais falso positivo e mais lento.
• B (ZAP): grátis, cobre bem se configurado por especialista. Ruído alto.
• C (API-first): ótima para APIs REST/GraphQL. Fraca em app com muita UI.
• D (nacional): boa integração local (LGPD, ANPD templates), mas TPR mediano.
• E (IaC + web): força está em IaC, web é secundário.
• F (performance): mais rápida. TPR médio.
• G (ML): promete muito por ML, entrega muito ruído.

Como escolher para seu contexto

Três perguntas guiam a decisão:

1. Quem vai triar findings? Se time pequeno (< 3 pessoas em AppSec), FPR importa mais que TPR marginal. Baixo ruído > detecção marginal.
2. Qual sua stack dominante? API-heavy → C ou Varredura. UI-heavy → A ou Varredura. Multi-stack → priorize cobertura OWASP.
3. Qual sua frequência de release? Deploys diários exigem scan rápido (< 30 min). Deploys semanais permitem scans profundos.

Não existe ferramenta única para todos os casos. Muitas empresas rodam duas em paralelo: uma rápida no CI, uma profunda semanal em produção.

Planilha aberta

Todo o dataset — 312 vulnerabilidades classificadas, 168 execuções de scan, tempo por app, findings brutos por ferramenta — está em planilha aberta (placeholder). Revise, replique, discorde.

Metodologia reprodutível

Metodologia importa mais que ranking. Os apps são amostra de conveniência (grandes o suficiente para representar produção real, pequenos o suficiente para pentest exaustivo). O ranking muda em outras amostras — mas a metodologia continua válida.

A Varredura foi construída para o cenário BR: TPR alto em vetores frequentes em stacks Node/PHP, FPR baixo para times pequenos, cobertura OWASP completa incluindo LLM. Rode agora e compare no seu app real.