Agora você já pode auditar a segurança do seu código com IA usando o security-audit, a skill MIT que a Cloudflare usou como base do seu harness interno de vulnerabilidades. Ela é instalada com um único npx skills add e funciona com qualquer coding agent capaz de lançar subagentes em paralelo. No momento em que esta nota foi escrita, o repositório estava em alta no GitHub: 6,2 mil estrelas, 1,2 mil delas em um único dia.
O que a diferencia de pedir ao seu agente que “procure bugs” é que ela não confia na primeira resposta. Os agentes que encontram um candidato a vulnerabilidade nunca são os que o confirmam. Tudo o que não tiver um atacante concreto, um limite de confiança cruzado e um resultado observável acaba rejeitado ou fica em aberto.
O que é a skill security-audit da Cloudflare?
É um conjunto de instruções, prompts e dois validadores pequenos que transforma um coding agent generalista em um auditor de segurança estruturado. A Cloudflare a liberou junto com seu artigo de 18 de junho de 2026, Build your own vulnerability harness, no qual explica que seu sistema de varredura em escala de toda a sua frota de repositórios nasceu desta skill de um único repositório, e que seus prompts ainda conservam quase sem mudanças os cenários de ataque e as classes de bugs da skill original.
Ela não depende de nenhum agente específico. O SKILL.md descreve papéis genéricos — um agente parent que coordena, agentes research para leitura focada do código e agentes general para investigação mais ampla — e pede ao seu agente que use o mecanismo de subagentes que a plataforma dele tiver.
Como ela faz a análise de vulnerabilidades?
Uma auditoria completa percorre seis fases em ordem:
- Reconhecimento. Agentes em paralelo mapeiam a arquitetura, os limites de confiança, os pontos de entrada e os caminhos de build locais. Tudo fica em
architecture.mde em um plano de cobertura,coverage-ledger.json. - Caça guiada por cobertura. Agentes caçadores (hunters) isolados pegam unidades do plano e as atacam por classe: injeção, controle de acesso, lógica de negócio, lacunas de confiança entre componentes e mais. Depois de cada onda, agentes críticos de cobertura procuram lacunas.
- Validação de candidatos. Cada candidato passa para um verificador novo cujo trabalho é refutá-lo.
- Saída estruturada. Todos os resultados são escritos em
findings.jsone validados contra um esquema JSON. - Verificação independente. Agentes novos voltam a checar as afirmações finais contra o código-fonte.
- Relatório.
REPORT.md,FINDINGS-DETAIL.mdeNEEDS-VALIDATION.mdsão gerados apenas a partir dos registros já verificados.
A ordem importa: o relatório é escrito no final, depois da verificação, então a prosa para humanos não pode contradizer o registro em JSON.
Durante o reconhecimento, a skill também decide quais dos seus dez arquivos especializados carregar: por exemplo, AI-AND-LLM.md para prompt injection e MCP, SUPPLY-CHAIN-AND-RELEASE.md para CI e assinatura de releases, ou MEMORY-SAFETY-AND-BINARY.md para código nativo. As instruções são explícitas: um arquivo é selecionado porque existe um limite de confiança real, não porque o nome de uma linguagem ou de uma dependência aparece no repo.
Modo guia ou auditoria completa?
Carregar a skill não inicia sozinho as seis fases. Por padrão, ela trabalha em modo guia: responde a perguntas de segurança e faz revisões pontuais sem criar um diretório de saída. O fluxo completo só é ativado quando você pede explicitamente para auditar ou fazer um pen test de um código, uma revisão completa ou arquivos de relatório. Se o seu pedido admite as duas leituras, ela pergunta antes.
Como instalar o security-audit?
Instale com a CLI de Skills:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
Para uma instalação no nível do usuário em vez de por projeto, adicione --global:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit \
--global
Outras opções úteis da CLI: --list mostra as skills do repositório sem instalar nada, -a, --agent escolhe em quais agentes instalar e -y pula as confirmações. Execute npx skills --help para ver a lista completa.
Como fazer uma auditoria de segurança do seu repositório?
Abra seu coding agent no repositório e peça a auditoria em linguagem natural. O README dá estes exemplos:
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
Se você não indicar um diretório de saída, os resultados vão para ~/security-audit-skill/<repo-name>/run-<N>, fora do seu repositório, então nenhum achado acaba em um commit por acidente. A skill só escreve dentro do repo se você escolher explicitamente um diretório que o controle de versão ignore.
Quick, standard ou deep?
Uma auditoria completa tem três perfis:
quickfaz uma única onda de caça e uma passada crítica, pensado para alvos pequenos ou uma primeira olhada.standardé o perfil padrão.deepdivide o trabalho com mais detalhe e mantém a validação e a verificação final como agentes separados, para código grande ou crítico.
Você também pode limitar a execução a caminhos específicos, a um subsistema, a um domínio especializado ou ao diff entre duas refs do código. Nesse caso, a skill marca o relatório como cobertura parcial.
Trocar de perfil muda quanto terreno a auditoria cobre, não quanta evidência ela exige. Até o quick mantém o filtro de validação e a verificação independente dos achados confirmados.
O que você precisa antes de executá-la?
Segundo o README, três coisas:
- Um coding agent cujo modelo suporte tool use e subagentes em paralelo.
- Node.js, para os dois validadores, que não têm dependências.
- Um sandbox aplicado pelo sistema operacional para qualquer build, teste ou processo que execute código do próprio alvo. Ele deve ter:
- nenhum acesso à rede externa,
- um ambiente construído a partir de uma lista explícita de variáveis permitidas,
- o alvo somente leitura, com escrita permitida apenas em um diretório
scratch/designado, - limites explícitos de CPU, memória, processos e tempo.
Leia com calma esse terceiro requisito. Se o seu ambiente não consegue garantir todos esses controles, a skill não pega atalhos: ela não executa o código do alvo e marca a pista como needs_validation, com o bloqueio exato e um plano seguro para resolvê-lo.
Se você usa o Claude Code, ele tem um /sandbox integrado que isola o sistema de arquivos e a rede para os comandos bash. Verifique se a sua configuração também cumpre os requisitos de ambiente e de limites de recursos antes de contar com a reprodução local.
A skill também é rigorosa com seus próprios limites: nada de sondar endpoints implantados nem infraestrutura compartilhada, nada de instalar dependências durante a auditoria e apenas principais, fixtures e segredos fictícios. Ela descreve as correções, mas não modifica o seu código.
É gratuito?
A skill é open source com licença MIT; o custo está no uso do modelo, e uma auditoria multiagente consome bem mais que um único prompt. A skill torna esse gasto contabilizável: em linhas gerais, uma unidade do plano equivale a uma atribuição de caçador, e cada candidato que sobrevive precisa de um ou dois verificadores, conforme o perfil.
Você pode fixar um orçamento como número máximo de chamadas a agentes. A skill reserva as chamadas de crítica e validação antes de começar a caçar. Se o orçamento não alcança nem o mínimo, ela não lança nenhum agente e avisa você, em vez de entregar em silêncio uma auditoria mais pobre.
Como referência, a Cloudflare descreve as varreduras completas do seu harness como varreduras periódicas do backlog que podem levar horas em um repo complexo, não como uma checagem por PR. Isso vale para o harness, não para esta skill, mas é uma boa pista de onde esse tipo de auditoria se encaixa.
Como ler os resultados da varredura de vulnerabilidades?
Comece pelo findings.json. Cada registro tem um de três veredictos:
confirmed: um rastreamento completo no código-fonte e um resultado observado e delimitado. Só esses recebem severidade (critical,high,medium,lowouinformational).needs_validation: uma hipótese concreta, ancorada no código, bloqueada por um único dado não resolvido, como uma configuração de proxy ou uma política de identidade que não está no repo. Não recebem severidade. São perguntas em aberto, não vulnerabilidades de baixa confiança.rejected: um candidato que a validação refutou. Ele é mantido para que as próximas execuções não voltem a persegui-lo.
A skill executa os dois validadores por conta própria, e você pode executá-los de novo:
node <skill-dir>/validate-findings.cjs <output-dir>/findings.json
node <skill-dir>/validate-coverage-ledger.cjs <output-dir>/coverage-ledger.json
Uma execução só pode terminar de duas maneiras: com todos os relatórios escritos e os dois validadores aprovados, ou com run_status: "incomplete" e o motivo exato declarado no relatório.
Por que executá-la mais de uma vez?
Segundo os testes da própria Cloudflare, uma única execução encontrou aproximadamente metade das vulnerabilidades que várias execuções encontraram no total. É um dado autorrelatado pela Cloudflare. Cada execução lê os planos e achados anteriores, revisa de novo tudo o que mudou no código e se concentra nas lacunas. Um achado confirmed anterior só é mantido se o código dele não mudou e se continua passando pela verificação.
Claude Code security review ou security-audit: qual usar?
Eles resolvem problemas diferentes, e muitas equipes vão querer os dois:
- O comando
/security-reviewdo Claude Code faz, segundo a documentação da Anthropic, uma revisão de segurança sob demanda das mudanças da sua branch atual. É rápido, vive dentro do seu fluxo habitual e serve para revisar o trabalho antes do commit. security-auditaudita um código completo (ou uma parte delimitada). Constrói um plano de cobertura, tenta refutar os próprios candidatos e deixa um registro legível por máquina que você pode ampliar a cada execução. Parece-se mais com uma auditoria programada do que com uma etapa de revisão.
Se você leu nossa nota sobre o VulnHunter, o caçador de vulnerabilidades open source da Capital One, a abordagem vai parecer familiar: raciocinar a partir do atacante e se autoverificar de forma adversarial. A skill da Cloudflare dá mais peso ao acompanhamento de cobertura, ao veredicto explícito needs_validation e a não depender de nenhum agente específico.
Funciona com Cursor, Codex ou outros agentes?
Ela foi projetada para isso. O SKILL.md se descreve como agnóstico em relação ao agente, e a CLI de Skills pode instalar em muitos agentes, entre eles Cursor e Codex. O requisito prático é o do README: seu agente e seu modelo precisam suportar tool use e subagentes em paralelo. Confirme isso antes de esperar uma auditoria completa.
Se você ainda não trabalha com skills, aqui está uma seleção de skills para agentes de IA para começar.
Qual é a relação com o harness da Cloudflare?
A skill é o ponto de partida para um único repositório; o harness é o que a Cloudflare construiu por cima. Segundo o artigo, o harness acrescenta:
- estado persistente em SQLite,
- agentes de deduplicação,
- rastreamento de dependências entre repositórios,
- um sistema de triagem separado que usa um modelo diferente do da fase de descoberta,
- um agente que gera correções, cujos patches ainda exigem revisão humana antes do merge.
Os números do harness nesse artigo são da Cloudflare e descrevem o harness, não a skill:
- 20.799 candidatos brutos, dos quais cerca de 12.057 passaram pela validação.
- Um pool combinado de 13.841 achados (incluindo a saída de outro harness), dos quais 7.245 ficaram acionáveis depois da deduplicação e da triagem.
- Uma queda na taxa de rejeição na validação inicial de 40 para 11 graças a um contexto de reconhecimento melhor.
Quando publicou o artigo, a Cloudflare disse que esperava liberar o harness em breve. No momento da publicação desta nota, a Cloudflare não havia liberado o harness.
Como evitar instalar uma cópia não oficial?
Instale sempre a partir de github.com/cloudflare/security-audit-skill e leia o SKILL.md antes de executar qualquer coisa. Skills populares atraem cópias, e no diretório de skills já aparece pelo menos um reempacotamento de terceiros com outro nome. O ecossistema já produziu skills que roubam credenciais, e um auditor de segurança é justamente a última coisa que você quer tirar de uma fonte não oficial.
Vale a pena?
Sim, se você usá-la como foi pensada. O security-audit é aquela rara ferramenta de segurança mais rigorosa com o que não afirma do que com o que encontra. Teste primeiro com o perfil quick em um serviço pequeno, leia o findings.json antes do REPORT.md e trate cada registro needs_validation como uma pergunta para o dono do serviço, não como um bug. Depois, execute de novo.