A Cloudflare abriu o auditor que usa em casa: o ponto é a contestação

A Cloudflare publicou nesta semana uma skill que transforma um agente de código em auditor de segurança, e ela se tornou o repositório de crescimento mais rápido na lista semanal do GitHub: cerca de 16,400 estrelas em sete dias, 51.000 no total. A descrição da própria empresa é de uma modéstia incomum: este é o ponto de partida de repositório único do qual evoluiu seu arnês interno de descoberta de vulnerabilidades, publicado para que outras pessoas construam o seu.

O que vale ler não é o catálogo de classes de ataque, embora ele seja extenso. É a parte sobre como os achados são derrubados.

Seis fases, uma delas é só contabilidade

O fluxo de trabalho é estruturado, não conversacional, e isso é a primeira coisa que o separa de «peça ao Claude para achar bugs».

A fase um é reconhecimento: mapear a arquitetura, as fronteiras de confiança, as superfícies de entrada e, aqui está o incomum, registrar tudo em architecture.md e coverage-ledger.json. A fase dois distribui caçadores isolados pelas unidades desse registro, anota o que cada um verificou e então roda críticos de cobertura para achar o que ninguém olhou. A fase três entrega cada candidato único a um verificador novo, cujo trabalho é refutá-lo. A fase quatro grava registros confirmed, needs_validation ou rejected em findings.json e os valida contra um schema JSON. A fase cinco faz agentes novos verificarem as afirmações finais sobre o código, e qualquer substituição material passa por outro verificador independente. A fase seis deriva os relatórios dos registros verificados.

Os dois validadores são scripts Node sem dependências: validate-coverage-ledger.cjs roda depois da criação do registro e a cada atualização, validate-findings.cjs roda na fase quatro e de novo depois de cada substituição da fase cinco. São os arquivos menos interessantes do repositório e a razão pela qual o resto se sustenta. Um agente que não consegue produzir um achado válido pelo schema não pode afirmar que encontrou um.

Os três veredictos são o projeto de verdade

Quase toda ferramenta de segurança para agentes tem duas saídas: uma lista de bugs ou nada. Esta tem três, e a categoria do meio é onde está o raciocínio.

confirmed significa um rastro completo no código-fonte mais um resultado delimitado e observado. needs_validation significa um fato não resolvido e exato, sem severidade atribuída. rejected significa um candidato ativamente refutado, registrado em vez de apagado.

O terceiro é incomum e, na minha opinião, correto. Um candidato refutado é evidência sobre a base de código: diz à execução seguinte para não gastar tempo ali e mostra ao revisor o que foi considerado. Quase todas as ferramentas jogam isso fora.

O princípio de projeto por baixo está escrito sem rodeios no README: confirmar apenas falhas de fronteira já estabelecidas e, se uma pista ancorada no código ficar travada, mantê-la como needs_validation com seu fato exato não resolvido em vez de promovê-la a achado. Há uma regra relacionada: lacunas de defesa em profundidade não são vulnerabilidades. Se a camada A bloqueia o ataque, a ausência da camada B é uma nota de endurecimento.

Quem já leu um relatório de vulnerabilidades gerado por máquina sabe exatamente por que essas regras existem. O modo de falha da revisão de segurança com LLM não é perder bugs. É ruído confiante: padrões que parecem vulnerabilidades, reportados com severidade alta, queimando uma semana de um time de triagem.

Validação adversarial, ao pé da letra

A frase mais importante: o agente que confere um achado nunca é o agente que o encontrou.

Não é uma instrução de prompt, é uma restrição de orquestração, e é o único caminho para esse tipo de ferramenta produzir algo confiável. Um LLM questionado sobre se o próprio achado está correto vai concordar consigo mesmo. Dê a ele um contexto novo, outra instância de agente e a tarefa explícita de refutar a afirmação, e você chega a algo mais próximo de uma revisão de código.

A fase cinco estende isso: agentes novos verificam as afirmações finais sobre o código e, se uma afirmação for substituída de forma material, outro verificador independente confere a substituição. São dois níveis de separação entre o caçador e o registro que sobrevive.

O número honesto

Enterrado nos princípios de projeto está isto: nos testes da Cloudflare, uma execução única encontrou aproximadamente metade das vulnerabilidades que execuções repetidas encontraram no total.

Publicar isso é uma escolha. Diz que a ferramenta é uma máquina de cobertura, não um oráculo, e reenquadra o fluxo de trabalho: você não roda uma vez antes de um lançamento, roda repetidamente e deixa os registros se acumularem. O repositório sustenta isso explicitamente: várias execuções no mesmo repositório são aditivas, usam registros e achados anteriores para mirar lacunas, revalidam o código alterado e carregam adiante as evidências do código atual sem tratar trabalho obsoleto como coberto.

Metade também é uma estimativa razoável para auditores humanos numa primeira passada, o que é reconfortante ou devastador dependendo de como você vê a profissão.

O requisito que vai barrar a maioria

O README lista um requisito rígido que quase todo usuário vai pular e depois encontrar: um sandbox imposto pelo sistema operacional para builds, testes, processos, navegadores, emuladores, fuzzers e fixtures, com rede externa desabilitada, ambiente saneado e em lista de permissões, limites de recursos aplicados e escrita restrita a caminhos temporários.

Sem esses controles, o fluxo de trabalho mantém a pista em needs_validation em vez de executar o código alvo. É a decisão certa — afinal você está rodando sugestões de um modelo de linguagem contra uma base de código — mas significa que a ferramenta degrada para um exercício de análise estática e raciocínio para quem não tem infraestrutura de contêineres.

Também significa que não é uma ferramenta de notebook, apesar da linha de instalação com npx. A instalação é um comando só:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

E o uso é só pedir:

security audit this codebase

O contraste é estranho: a invocação é uma frase, os pré-requisitos são uma política de sandbox. É nessa distância que vai morar a maior parte do esforço de implantação.

Como a saída realmente é

Três artefatos, derivados e não escritos: REPORT.md, FINDINGS-DETAIL.md e NEEDS-VALIDATION.md, além do findings.json por baixo e do registro de cobertura.

Essa separação é mais útil do que parece. Um relatório único de vulnerabilidades força todo achado para o mesmo registro, e é assim que você termina com uma injeção SQL crítica ao lado de um cabeçalho CSP ausente. Separar achados confirmados, perguntas abertas e resumos derivados faz com que quem lê NEEDS-VALIDATION.md saiba que está vendo trabalho, não resultados.

O diretório de saída padrão é ~/security-audit-skill/<repo-name>/run-<N>, e o fluxo só escreve dentro do repositório alvo se você apontá-lo explicitamente para um diretório ignorado pelo git. Detalhe pequeno, instinto correto: artefatos de auditoria em um repositório acabam commitados por acidente, e uma lista commitada de vulnerabilidades sem correção é um incidente por si só.

Como saber se funcionou

Rode duas vezes. É o teste que o README sugere sem enunciar: como as execuções são aditivas e uma só encontra mais ou menos metade, a segunda execução no mesmo commit é uma medição direta da cobertura da ferramenta no seu código. Se a segunda não trouxer nada novo, ou você está limpo ou as classes de caça não batem com a sua stack.

Depois olhe o log de rejeições. Uma execução que confirma cinco problemas e rejeita quarenta candidatos está fazendo o trabalho. Uma que confirma quarenta e não rejeita nenhum parou de verificar, e você deveria ler esses quarenta à mão antes de acreditar em qualquer um.

O que isso diz sobre a categoria

Três coisas, brevemente.

Skills de agente estão virando forma de distribuição. Não é uma biblioteca que você importa, é uma pasta de markdown e dois scripts de validação que um modelo lê em tempo de execução. O repositório são umas vinte e tantas instruções em arquivo mais catálogos de classes de ataque separados por tipo de alvo: segurança de memória e binários, superfícies de LLM e agentes, protocolo web e autenticação, lado cliente, cadeia de suprimentos, nuvem e implantação, RPC e mensageria, esgotamento de recursos, isolamento de dados, desktop e IPC local. Essa estrutura é o produto.

Verificação está virando o diferencial. Qualquer fornecedor já gera um achado plausível. Quase nenhum consegue dizer quais sobreviveram a uma passada adversarial, escritos contra um schema, com os refutados preservados.

E o hábito do número honesto está se espalhando. Um fornecedor que publica «encontramos metade» é um fornecedor cuja próxima afirmação é mais crível.

O repositório tem licença MIT, o que significa que a pergunta interessante não é se funciona, mas se o seu time pode pagar o sandbox de que ele precisa para funcionar direito.