Cloudflare abriu o código do skill de auditoria de segurança com IA: como funciona
O skill de código aberto da Cloudflare combina busca guiada por cobertura, validação independente e evidências estruturadas. Veja o que o fluxo pode comprovar — e quais são seus limites.
Além de ASPM
AppSec orientada por provas para equipes que desenvolvem com IA
A Plexicus usa AI Swarm Pentest para explorar caminhos autorizados da aplicação, validar o que é explorável e dar às equipes evidências para priorizar a remediação.
Explorar AI Swarm PentestA Cloudflare publicou um skill de código aberto que oferece aos agentes de programação compatíveis um processo estruturado para auditar uma base de código. A ideia central é simples: uma suspeita gerada por IA continua sendo uma hipótese até que alguém rastreie o código, verifique o limite de confiança e tente refutá-la de forma independente.
Essa diferença importa. Encontrar uma função que parece arriscada não prova que um invasor possa alcançá-la e afetar um recurso protegido. O repositório security-audit-skill da Cloudflare torna esse caminho de evidências parte do processo.

Ilustração da Plexicus. Todos os detalhes da interface — inclusive os contadores de estrelas e forks do repositório — são elementos ilustrativos, não dados atuais do repositório da Cloudflare nem uma captura de um produto da Cloudflare.
O que a Cloudflare abriu como código aberto?
O repositório público contém um skill para agente de programação que audita um repositório por vez: instruções, guias de classes de ataque, regras de validação, esquemas e scripts para produzir registros de auditoria. A licença é MIT. Esse skill foi o ponto de partida para um sistema interno mais amplo, mas não equivale ao sistema completo.
No artigo de 18 de junho de 2026, “Build your own vulnerability harness”, a Cloudflare descreveu primeiro um fluxo original de sete etapas e, depois, sua evolução para um sistema interno de descoberta de vulnerabilidades. O repositório público atual descreve seis fases. As descrições correspondem a versões e escopos distintos, portanto não devem ser reunidas em uma única sequência.
A Cloudflare relatou que seu sistema interno para vários repositórios cobriu 128 repositórios em cerca de seis semanas. A arquitetura interna inclui orquestração persistente e triagem posterior que não vêm automaticamente com a instalação do skill público. O projeto aberto deve ser entendido como um método auditável para um único repositório, que as equipes podem adaptar.
O que há no repositório?
O repositório inclui SKILL.md, com as regras do fluxo e de segurança; guias de reconhecimento e busca; referências de classes de ataque para áreas como segurança de IA/LLM, protocolos web, cadeia de suprimentos, nuvem e código do cliente; VALIDATION-AND-REPORTING.md; report-schema.json; e validadores Node.js sem dependências para descobertas e registros de cobertura.
O registro documenta quais partes do sistema foram examinadas, por quem e com quais evidências. As descobertas seguem um esquema que diferencia problemas confirmados, hipóteses não resolvidas e hipóteses refutadas. Esses artefatos tornam a auditoria mais fácil de revisar, mas sua existência não prova, por si só, que cada conclusão esteja correta.
As seis fases a seguir descrevem o Full audit mode (modo de auditoria completa). Por padrão, o skill funciona em modo de orientação: perguntas e revisões específicas usam apenas as orientações pertinentes e não iniciam automaticamente as seis fases nem criam artefatos de auditoria.
As seis fases atuais
1. Reconnaissance — reconhecimento
O agente mapeia a arquitetura, os usuários e serviços envolvidos, os pontos de entrada, os recursos sensíveis e os limites de confiança. Registra o resultado em architecture.md e cria um coverage-ledger.json com unidades de trabalho determinísticas. Assim, o escopo fica visível e as lacunas podem ser identificadas.
2. Coverage-led hunting — busca guiada por cobertura
Hunters isolados recebem unidades do registro, documentam as verificações realizadas e investigam hipóteses ligadas a limites reais de segurança. Críticos de cobertura procuram áreas esquecidas. Isso é mais específico do que pedir a vários agentes que “analisem o código”: o trabalho e as evidências de cobertura são registrados.
Uma boa hipótese identifica a capacidade inicial do invasor, o recurso protegido, o caminho pela aplicação e a possível violação de limite. Por exemplo, um handler que carrega uma fatura pelo ID não comprova automaticamente uma falha de autorização. É necessário verificar se o usuário controla o ID, se outra camada confere a propriedade e se a solicitação pode cruzar o limite entre tenants.
3. Candidate validation — validação de candidatos
Um novo verificador recebe cada candidato único e tenta refutá-lo. Ele verifica se a entrada está sob controle do invasor, se o caminho é acessível, se há uma proteção em outro ponto e se as evidências mostram um resultado de segurança real. O agente que encontrou o problema não valida a própria descoberta.
4. Structured output — saída estruturada
O skill grava as descobertas em findings.json com vereditos distintos:
| Veredito | Significado |
|---|---|
confirmed | Uma trilha completa no código e um resultado observado e limitado demonstram uma violação de limite. |
needs_validation | Um fato específico continua sem resposta; o registro não recebe severidade antes dessa verificação. |
rejected | O candidato foi refutado e o motivo está registrado. |
Um validador de esquema confere a estrutura. Ele não prova a explorabilidade por conta própria; por isso, a validação continua sendo uma fase separada.
5. Independent record verification — verificação independente dos registros
Novos agentes revisam as afirmações finais sobre o código-fonte e suas evidências. Se um registro for substituído de forma relevante, a nova versão recebe outra verificação independente. Essa etapa avalia o relatório como registro de segurança, não apenas repete a investigação original do código.
6. Target-neutral reporting — relatórios neutros em relação ao alvo
Os registros verificados e o ledger geram REPORT.md, FINDINGS-DETAIL.md e NEEDS-VALIDATION.md. As equipes podem ver o que foi confirmado, o que continua sem resolução e quais áreas foram cobertas sem que a incerteza seja apresentada como fato.
O skill público e o sistema interno da Cloudflare
O artigo de lançamento da Cloudflare descreve um Vulnerability Discovery Harness (VDH) e um Vulnerability Validation System (VVS). O VDH organiza investigações do código-fonte e gera candidatos a vulnerabilidade. O VVS conduz a análise posterior: deduplicação, aplicabilidade em produção, priorização e encaminhamento para engenharia. O sistema maior também adiciona orquestração persistente entre repositórios, contexto cruzado e ciclos de feedback operacional.
Esse contexto é importante para interpretar os resultados da Cloudflare. O skill público pode estruturar uma auditoria, mas quem o utiliza ainda precisa fornecer um ambiente de agente compatível, controles seguros de execução e uma forma de avaliar a exposição específica da implantação. Não se deve presumir que todos os recursos do sistema interno estejam incluídos no repositório independente.
O que significam os números divulgados pela Cloudflare?
A Cloudflare publicou números de seu sistema interno em junho de 2026. São resultados operacionais divulgados pela empresa, não um benchmark independente do skill público.
| Métrica divulgada | Número da Cloudflare |
|---|---|
| Repositórios no escopo inicial da frota VDH | 128 |
| Candidatos brutos do VDH | 20.799 |
| Candidatos que passaram pela validação do VDH | Aproximadamente 12.057 |
| Descobertas no conjunto combinado do VVS | 13.841 em 145 repositórios |
| Duplicatas identificadas nesse conjunto | 5.442 |
| Itens reciclados de baixo risco ou atribuídos ao repositório errado | 1.154 |
| Itens encaminhados à engenharia como acionáveis | 7.245 |
O número 128 descreve o escopo inicial da frota do VDH. O conjunto combinado do VVS foi reportado em 145 repositórios. São populações diferentes e não devem ser confundidas. A conta também importa: os 7.245 itens acionáveis resultam da remoção de duplicatas e itens reciclados de baixo risco ou atribuídos ao repositório errado do conjunto combinado.
“Acionável” não significa “comprovadamente explorável em um sistema de produção acessível pela Internet”. Os dados da Cloudflare dizem respeito a pesquisas isoladas e ao contexto operacional da própria empresa; alguns registros se baseavam em snapshots que podem ficar desatualizados quando o código ou a configuração mudam. Os números demonstram escala e triagem, não uma taxa universal de detecção nem uma contagem de falhas exploráveis externamente.
A Cloudflare também afirma não conseguir determinar uma taxa confiável de falsos negativos sem conhecer todas as vulnerabilidades presentes. A empresa relatou que uma execução encontrou aproximadamente metade dos problemas identificados ao longo de execuções repetidas em seus experimentos. Esse é um resultado daqueles testes, não a afirmação de que o skill detecta metade das vulnerabilidades em qualquer base de código.
Skill de auditoria, SAST e pentest
O skill complementa outros métodos de AppSec, em vez de substituí-los. SAST pode analisar o código repetidamente em busca de padrões e fluxos de dados conhecidos. Uma auditoria com agentes acrescenta uma investigação explícita da arquitetura e dos limites de confiança, registros de cobertura e revisão adversarial. Cada método tem diferentes modos de falha; analisadores estáticos modernos também podem raciocinar entre funções e componentes.
Uma auditoria de código-fonte também difere de um pentest em tempo de execução. A revisão do código pode rastrear uma condição de autorização e reproduzir um comportamento limitado localmente. Um pentest autorizado pode testar um ambiente implantado com contas aprovadas e escopo definido, mostrando como configuração de execução, provedores de identidade, gateways e infraestrutura afetam o caminho de ataque. Nenhum dos métodos, sozinho, prova segurança completa.
Não direcione o skill a um alvo ativo nem interprete o gatilho “pen-test” como autorização para sondar um serviço implantado. O fluxo documentado é defensivo e prioriza código-fonte. Qualquer build, teste, processo, navegador, emulador, fuzzer ou fixture controlado pelo alvo precisa ser executado em um sandbox imposto pelo sistema operacional que desative a rede externa, use um ambiente higienizado e limitado por allowlist, imponha limites de recursos e restrinja gravações aos diretórios temporários designados. Sem esses controles, o fluxo determina que o candidato permaneça como needs_validation e que o código do alvo não seja executado. Avalie somente código e ambientes próprios ou para os quais haja autorização explícita.
Como instalar o skill com segurança
O README do projeto documenta a instalação pela Skills CLI:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
Para uma instalação no nível do usuário, o README acrescenta --global. Inicie um agente de programação compatível dentro de um repositório autorizado, ou aponte o agente para ele, e solicite uma auditoria. Os validadores do projeto precisam do Node.js; o agente deve oferecer uso de ferramentas e subagentes em paralelo.
Instalar o skill não cria um sandbox de sistema operacional. Configure esses controles antes de permitir a execução de código controlado pelo repositório. Siga as condições de tratamento de dados aprovadas pela organização, use identidades e dados de teste, impeça builds de baixar dependências e não herde credenciais. Antes de agir, revise o registro de cobertura, as evidências de cada afirmação e todas as correções propostas.
O que isso representa para as equipes de AppSec
A contribuição mais forte é a disciplina do fluxo: registrar o que foi analisado, separar candidatos de descobertas confirmadas, contestar cada candidato de forma independente e preservar o fato exato que falta quando não há evidências suficientes. Isso pode tornar a pesquisa assistida por agentes mais fácil de revisar. Não garante cobertura completa, comportamento consistente do modelo ou impacto em produção.
Em um programa de AppSec mais amplo, as equipes ainda precisam correlacionar descobertas no código com contexto de execução, propriedade, exposição e testes das correções. Para avaliar aplicações em execução dentro de um escopo autorizado, conheça o Plexicus AI Swarm Pentest como uma abordagem separada de teste em tempo de execução. Ele não faz parte do skill da Cloudflare, que prioriza o código-fonte, e os dois métodos não são equivalentes. Avalie cada abordagem pelas evidências que pode fornecer para o escopo autorizado; a publicação da Cloudflare não comprova recursos de outros produtos.
O critério prático é simples: avalie um resultado de segurança pela rastreabilidade das evidências, pelo limite que ele demonstra, pela incerteza que preserva e pela possibilidade de reproduzi-lo e agir — não pelo número de descobertas em um painel.
Perguntas frequentes
O skill da Cloudflare é gratuito?
O repositório tem licença MIT. O uso do modelo, a computação e o ambiente do agente ainda podem gerar custos.
O skill público é o mesmo sistema interno da Cloudflare?
Não. O projeto público é um ponto de partida para um repositório. O sistema interno adiciona orquestração de frota, validação e triagem posteriores descritas no blog da Cloudflare.
Ele corrige vulnerabilidades automaticamente?
O skill público se concentra em auditoria, validação e relatórios. A Cloudflare descreve fluxos de correção separados em seu sistema interno, com testes de regressão e revisão humana. Não presuma que façam parte do skill independente.
A verificação independente elimina falsos positivos?
Não. Ela ajuda a questionar afirmações sem suporte e a preservar incertezas. Não garante que todas as classificações estejam corretas nem que nenhuma vulnerabilidade tenha passado despercebida.
Posso usá-lo contra um site de produção?
Não use o fluxo de auditoria de código para sondar serviços ativos. A validação em tempo de execução exige autorização explícita e um escopo seguro definido separadamente; os requisitos de execução documentados se referem a código local e isolado.
Fontes
- Cloudflare, Build your own vulnerability harness, 18 de junho de 2026.
- Cloudflare, repositório e README de security-audit-skill.
- Cloudflare, instruções do Security Audit skill.