Em outubro de 2025 o falso positivo rate do scanner da Varredura era de 34%. Em agosto de 2026 caiu para 4,4%. Redução de 87%. Este é o postmortem técnico do que mudou, publicado por transparência com nossos clientes.

Por que falso positivo importa mais do que falso negativo (nesse caso)

Contraintuitivo? Não. Se seu scanner marca 100 findings/scan e 34 são falso positivo, o time gasta 3-6h investigando lixo. Depois do 3º scan, o time desliga o scanner. Falso positivo alto = ferramenta abandonada = zero cobertura.

O ponto inicial (Q4 2025)

• Findings/scan médio: 42.
• Falso positivo rate: 34%.
• Tempo médio pra investigar: 12 min por finding.
• Feedback do cliente: "seus alertas são bons mas cansam".

Categorização de falsos positivos

Analisamos 2.400 findings marcadas como falso positivo por clientes:

• Endpoint de teste/exemplo (28%): scanner acha SSRF em /api/echo — mas é rota intencional.
• Falso match de header (22%): CSP presente em resposta parcial, ausente em outra.
• Comportamento por design (18%): "senha em URL" em feature de compartilhamento com token.
• CORS legítimo aberto (12%): API pública que aceita origem * intencionalmente.
• Retry gera duplicata (10%): scanner conta o mesmo finding 2x.
• Falso match de padrão (10%): regex de secret pegando foo_key=bar_placeholder.

O que mudamos

1. Baseline por endpoint

Cada endpoint testado tem um baseline. Se comportamento é constante, é característica, não falha.

Exemplo: /api/echo sempre reflete input. Baseline reconhece. Não vira SSRF alarmante.

Impacto: eliminou 28% dos FP (endpoint de teste/exemplo).

2. Verificação em segunda passada

Toda finding "alta" ou "crítica" tem uma verificação em segunda passada com técnica diferente. Se as duas técnicas confirmam, sobe. Se só uma, entra como "possível".

Impacto: eliminou 22% dos FP (falso match de header).

3. Escopo declarado pelo cliente

Cliente marca uma vez comportamentos intencionais ("/api/webhook aceita CORS aberto por design"). Scanner aprende.

Impacto: eliminou 12% dos FP (CORS legítimo).

4. Deduplicação de findings similares

Findings com mesmo vetor + mesmo endpoint + mesmo parâmetro contam como uma. Não como 3 pelo retry.

Impacto: eliminou 10% dos FP (retry).

5. Regex de secret com validação semântica

sk_test_xxxxx reconhecido como placeholder de teste do Stripe. sk_live_... continua sendo tratado como crítica.

Impacto: eliminou 10% dos FP (falso match).

6. Feedback loop com o cliente

Cliente marca "falso positivo" com 1 clique. Isso vira input do dataset de retreino. Scanner aprende no cliente.

Impacto: contínuo, refina o restante.

O que NÃO mudamos

Mantivemos falso negativo baixo. Reduzir FP sacrificando FN não vale — cliente prefere gastar 5 min descartando 1 alerta ruim do que ter 1 crítica escondida.

Métricas atuais (Agosto 2026)

• Findings/scan médio: 22 (redução 48% — não porque perdemos achados, mas porque deduplicamos e categorizamos melhor).
• Falso positivo rate: 4,4%.
• Tempo médio pra investigar: 3 min por finding.
• Score de satisfação (NPS): +47 (era +8 em Q4 2025).

Trade-off que fizemos

Verificação em segunda passada aumenta tempo de scan em 20-30s. Cliente prefere: 90s com FP baixo vs 60s com FP alto.

Ferramentas open-source usadas

• Nuclei — base para templates de detecção.
• Semgrep — verificação em segunda passada de padrões.
• CodeQL — análise semântica para categorização.

Construímos o pipeline em cima. Publicaremos templates customizados em Q4 2026.

TL;DR

• Redução de 34% → 4,4% em FP.
• 6 mudanças concretas, cada uma responsável por parte da redução.
• Falso negativo mantido baixo — não sacrificamos cobertura.
• Cliente marca FP com 1 clique, entra no retreino.

Isso é o que faz uma ferramenta contínua sobreviver. Testar.