Cloudflare revela como construir um harness de vulnerabilidades com IA: do script de 450 linhas a patches automatizados em 14h por repositório
Aprofundamento CEVIU
Aprofundamento
A Cloudflare não está apenas trocando modelos de IA, está reconstruindo a engenharia de segurança como uma operação de plataforma. O harness descrito na notícia atual é a evolução lógica do que já vinha sendo testado desde abril: um sistema orquestrado, com estado persistente em SQLite, agentes especializados (Recon, Hunt, Validate, Trace) e sandboxing real para execução de PoCs em C/Rust. Diferente de ferramentas de SAST ou code review baseadas em regras, esse sistema opera como um time de engenheiros de confiabilidade distribuído: o Recon gera ameaças específicas por repositório, os Hunters atacam ativamente (compilando, crashando, explorando), e o VVS força uma validação adversarial com modelo distinto, não como checagem extra, mas como requisito arquitetural de confiança.
O pulo de qualidade técnico veio da externalização completa do estado. Em vez de tentar manter contexto em janelas de LLM, cada agente é stateless e escreve no banco após cada passo. Isso resolve três limitações críticas de agentes genéricos: perda de memória em longas sessões, falhas catastróficas por timeout ou rate limit, e cegueira cross-repo. A dependência entre repositórios não é inferida, é rastreada via índice simbólico unificado e grafo de dependências real, o que explica por que 9% das tarefas surgem de 'sibling forking' e por que o wishlist acumulou 25 mil pedidos (como 'preciso de uma VM FreeBSD').
O que mudou
Em menos de duas semanas, o sistema deixou de ser um experimento de triagem (relatado em 18/06) para uma operação produtiva com métricas fechadas: 7.245 achados acionáveis em 128 repositórios, com patches gerados em ~14h/repo, um salto direto do 'script de 450 linhas' para um pipeline com controle de contexto rigoroso, aprovação humana obrigatória e integração com fluxos de CI/CD. A mudança mais concreta foi a migração do VVS de um módulo teórico para um sistema em produção: ele agora gerencia 13.841 achados em 145 repositórios, com deduplicação automatizada de 5.442 itens e roteamento inteligente de 1.154 como 'repositório errado' ou 'baixo risco'. Isso só foi possível porque o harness passou de um artefato isolado para uma camada de infraestrutura, integrada ao mesmo ecossistema que já processava 131 mil revisões de código/mês com sete agentes especializados.
Por que isso importa
Isso importa porque a Cloudflare está operacionalizando o que o Relatório de Ameaças 2026 chamou de 'industrialização das ameaças': se atacantes usam IA para escalar exploração em velocidade, defensores precisam automatizar não só detecção, mas triagem, validação e correção, tudo com garantias de confiabilidade. O custo médio de US$ 1,19 por revisão de código mostra que essa orquestração não é luxo, mas escalabilidade econômica. Mais ainda: o aumento de 322% em caminhos de escalonamento de privilégios no código gerado por IA exige exatamente esse tipo de pipeline, não para substituir humanos, mas para filtrar ruído em escala e entregar só o que merece atenção humana. É DevSecOps como serviço de plataforma, não como script pontual.
Linha do tempo
Cloudflare lança sistema de design autorregenerativo com Claude Code como orquestrador
Sistema multi-agente de code review entra em produção com 131.246 revisões em um mês
Testes do Mythos Preview da Anthropic detectam exploits funcionais em 50+ repositórios internos
Projeto Glasswing identifica mais de 10.000 vulnerabilidades de alta severidade em softwares críticos
Cloudflare publica detalhes técnicos do harness de vulnerabilidades com foco em estado persistente e controle de contexto
Cloudflare revela evolução do harness: de script de 450 linhas a patches automatizados em 14h/repositório, com 7.245 achados acionáveis
Perguntas frequentes
O que significa 'model-agnostic' nesse contexto?
Significa que o harness não depende de nenhum modelo específico. Ele usa um modelo para descoberta (VDH) e outro totalmente distinto para validação (VVS), podendo trocar qualquer um sem refatorar a arquitetura. Isso protege contra obsolescência de modelos e variações inesperadas de comportamento entre versões.
Como o sistema lida com falsos positivos?
Com dupla validação: primeiro, um agente adversarial tenta refutar cada achado; depois, um modelo diferente no VVS re-verifica todos os sobreviventes contra o código-fonte. Além disso, o sistema deduplica achados com base em lógica de vulnerabilidade, não em strings ou caminhos, e roteia 1.154 casos como 'repositório errado' antes da análise humana.
Por que o sandbox é crítico para linguagens como C e Rust?
Porque ler código não revela undefined behavior. O sistema compila trechos, executa em sandbox com unshare e força crashes para validar exploits reais, algo impossível em análise estática. Sem isso, vulnerabilidades como use-after-free ou memory corruption ficariam invisíveis até produção.
Qual é o papel do 'wishlist' na operação diária?
É o canal de feedback dos agentes para humanos. Quando um Hunter precisa de uma VM FreeBSD ou um Validator pede um arquivo de configuração de produção, ele escreve no wishlist. Isso transforma lacunas operacionais em tarefas rastreáveis, e 25 mil entradas em 128 repositórios mostram que é a principal forma de os agentes sinalizarem dependências reais do mundo físico.
Fontes
- blog.cloudflare.comfonte original
- Categoria
- CEVIU DevOps
- Publicado
- 19 de junho de 2026
- Editoria
- CEVIU DevOps

