Construa Seu Próprio Harness de Descoberta de Vulnerabilidades Lições do Sistema de Produção da Cloudflare

Por que Agentes Genéricos de IA Falham em Segurança

A maioria das demos de segurança com IA foca em um único repositório ou benchmark curado. Na realidade, codebases empresariais abrangem dezenas de linguagens, milhares de dependências e milhões de linhas de código. Uma abordagem de agente único encontra três paredes fundamentais:

1. Exaustão de contexto — Depois de uma hora, a janela de contexto enche e o modelo esquece bugs que encontrou antes.
2. Hipótese única — Agentes exploram um caminho de ataque por vez, perdendo o panorama geral.
3. Sem persistência — Uma falha ou timeout perde todo o progresso.

A jornada da Cloudflare começou com um skill de auditoria de segurança de 450 linhas que rodava em um repo. Funcionava, mas uma única execução encontrava apenas cerca de metade dos bugs. A solução não foi um modelo melhor — foi uma camada de orquestração agnóstica a modelos que trata LLMs como motores de computação intercambiáveis.

Fonte: Blog da Cloudflare

Arquitetura: Pipeline de Dois Estágios

O sistema da Cloudflare divide o gerenciamento de vulnerabilidades em dois estágios independentes, cada um usando um modelo diferente:

Estágio 1: Harness de Descoberta de Vulnerabilidades (VDH)

Estágio 2: Sistema de Validação de Vulnerabilidades (VVS)

# Exemplo simplificado: orquestrando estágios com backend de banco de dados
import sqlite3
from enum import Enum

class Stage(Enum):
    RECON = "recon"
    HUNT = "hunt"
    VALIDATE = "validate"

class Harness:
    def __init__(self, db_path: str):
        self.conn = sqlite3.connect(db_path)
        self.conn.execute("""
            CREATE TABLE IF NOT EXISTS findings (
                run_id TEXT,
                repo TEXT,
                stage TEXT,
                data TEXT,
                status TEXT DEFAULT 'pending'
            )
        """)
    
    def run_stage(self, run_id: str, repo: str, stage: Stage, task: callable):
        # Verifica se já foi completado
        cursor = self.conn.execute(
            "SELECT status FROM findings WHERE run_id=? AND repo=? AND stage=?",
            (run_id, repo, stage.value)
        )
        row = cursor.fetchone()
        if row and row[0] == 'completed':
            return
        
        result = task()
        self.conn.execute(
            "INSERT OR REPLACE INTO findings VALUES (?,?,?,?,?)",
            (run_id, repo, stage.value, result, 'completed')
        )
        self.conn.commit()

Lições Críticas da Produção

1. Persistência Antes do Paralelismo

Cada estágio escreve em um banco SQLite chaveado por (run_id, repo, stage). Achados são transmitidos e salvos conforme acontecem — uma falha custa apenas a tarefa em andamento. Isso é inegociável para execuções que podem levar 14+ horas.

2. Cuidado com Erros Silenciosos de API

Às vezes, um erro transitório de API retorna como texto em uma resposta 200 OK em vez de lançar uma exceção. Você precisa classificar explicitamente o texto da resposta, não confiar apenas no código de status.

3. Sandboxing Precisa de Configuração Cuidadosa

Se seu harness roda dentro de Docker, o sandbox (usado para crashar binários) precisa de seccomp=unconfined e apparmor=unconfined ou vai falhar silenciosamente ao iniciar.

4. Não Coloque Análise Estática Cedo Demais

A Cloudflare integrou Semgrep em todo o pipeline. Em um mês de execuções, os Hunters o invocaram zero vezes. Eles preferiam ler e executar o código. A ferramenta mais usada? Uma wishlist central onde agentes solicitam recursos.

5. Deduplicação é um Problema Próprio

Em escala, comparar achados com correspondência simples de string falha. A Cloudflare usa código determinístico para construir índices invertidos sobre arquivos, funções e tokens raros, e só então usa um LLM para raciocinar sobre uma lista curta de candidatos.

6. Forje Verificação Adversarial

Cada achado deve incluir:

• Um modelo de ameaça declarado (quem é o atacante, qual fronteira é cruzada)
• Um PoC que roda contra o codebase original, intocado
• Um patch proposto

Um Validador separado (que não pode registrar seus próprios achados) tenta refutar tudo. Se um Hunter avalia seu próprio trabalho, ele vai validar com confiança qualquer absurdo.

Explore o skill open-source que começou tudo.

Métricas do Mundo Real e Limitações

Para um repositório padrão de ~30k LOC:

• Achados iniciais: ~100 candidatos brutos
• Após validação: ~80 bugs de alta fidelidade
• Tempo para corrigir com revisão humana: ~14 horas para o pipeline, depois 5 dias para correções críticas, 15-20 dias para hardening
• Compressão ao longo da vida: ~65% de redução em candidatos em toda a frota

Limitações e Cuidados

• Sem taxa de falso negativo: Não existe um conjunto rotulado de todos os bugs reais em um codebase. A equipe mede eficácia rastreando se reexecuções continuam encontrando novos bugs.
• Custo é pesado no estágio de caça: Faça orçamento por repositório, não por execução. Use um limite de tarefas e um pool de workers (50-200) para evitar desperdício de computação.
• Não para verificações por PR: Escaneamentos completos levam horas. Use harnesses menores e mais baratos para CI.
• Humano no loop é obrigatório: O Fixer nunca faz merge sem um humano aprovar em um dry run.

Próximos Passos

1. Comece com um skill de repositório único no seu ambiente de desenvolvimento. Deixe os prompts funcionando bem antes de construir infraestrutura.
2. Adicione persistência (SQLite) antes de adicionar paralelismo.
3. Adicione um mecanismo de wishlist — deixe os agentes te dizerem o que precisam.
4. Introduza verificação adversarial com um modelo separado para validação.
5. Só construa rastreamento entre repositórios quando você tiver mais de um repositório que importa.

Leitura Recomendada

• Astro Joins Cloudflare: O Que Isso Significa para o Futuro da Web Baseada em Conteúdo
• Como a Meta Depreciou Seu Fork Interno do FFmpeg: Um Mergulho Profundo na Colaboração Open Source em Escala