Cloudflare Security Audit: seis fases para provar vulnerabilidades

ANÁLISE EDITORIAL

Cloudflare Security Audit é uma Agent Skill para conduzir auditorias de segurança em código por seis fases: reconhecimento, caça a vulnerabilidades, validação adversarial, relatório, saída estruturada e verificação independente. A proposta não é empilhar alertas de checklist. Cada finding precisa descrever um atacante, um caminho reproduzível e um impacto concreto antes de entrar no relatório.

O método serve para aplicações web, APIs, serviços, CLIs, bibliotecas, componentes nativos e sistemas com IA. Ele também é exigente: lê o repositório em profundidade, distribui trabalho entre vários subagentes, pode executar builds e testes e grava quatro artefatos de auditoria. Por isso, deve ser usado somente em código autorizado, com alvo, diretório de saída, rede e limites de execução definidos antes do início.

O download hospedado pelo Bastidores é um recorte documental com doze arquivos textuais. Ele preserva o SKILL.md, oito referências Markdown, o schema JSON, a licença MIT e o registro ORIGEM.md. O script validate-findings.cjs foi excluído porque é código executável. O ZIP permite inspeção, mas não é uma instalação funcional completa.

Ilustração editorial exclusiva do Bastidores da IA. Não é captura de tela, código real, relatório de vulnerabilidade, prova de exploração, benchmark nem certificação de segurança.

O que esta Skill faz de verdade

O arquivo principal fixa uma regra editorial e técnica importante: vulnerabilidade não é sinônimo de ausência de uma defesa recomendada. Um achado só deve ser confirmado quando existe uma sequência concreta de entrada, propagação e efeito, com dano observável. Se outra camada já impede o ataque, o texto orienta tratar a situação como nota de endurecimento, não como finding inflado.

A primeira fase usa agentes de pesquisa para mapear arquitetura, stack, usuários, superfícies de entrada, autenticação, autorização, separação de privilégios e integrações. As instruções completas estão em RECONNAISSANCE.md no commit auditado. O agente principal consolida o resultado em architecture.md, que passa a ser o contexto comum das investigações seguintes.

Na segunda fase, agentes generalistas recebem escopos diferentes, por exemplo injeção, controle de acesso, lógica de negócio, segredos, tratamento de arquivos e ataques encadeados. O método de caça está em HUNTING.md, enquanto ATTACK-CLASSES.md separa famílias de ataque. Arquivos complementares cobrem código nativo, sistemas de IA, protocolos HTTP e clientes web.

As fases finais tentam derrubar cada hipótese, escrevem relatórios humanos e estruturados e pedem a agentes novos que confiram caminhos, linhas, condições, payloads e correções no código real. A separação é útil porque o mesmo agente que propôs uma vulnerabilidade tende a conservar a própria interpretação. Ainda assim, independência entre agentes não substitui revisão humana, execução controlada nem validação por uma equipe de segurança.

Para quem serve

A Skill atende equipes de AppSec, engenharia, resposta a incidentes, manutenção de software e revisão de fornecedores que tenham autorização para analisar o código. Ela é mais adequada quando o objetivo é encontrar falhas exploráveis e explicar o caminho completo, em vez de apenas verificar presença de cabeçalhos, versões ou regras de estilo.

Ela não duplica a NVIDIA Skill Inspector. A ferramenta da NVIDIA avalia outra Agent Skill antes da instalação, com foco em arquivos, permissões e comportamento do pacote. A Cloudflare Security Audit aponta para o código de uma aplicação ou biblioteca e organiza uma investigação ofensiva em várias fases.

Também não substitui a Trail of Bits CodeQL. CodeQL cria bancos de análise estática e executa consultas rastreáveis. A Skill desta página é uma metodologia coordenada que pode pedir leitura manual, teste dinâmico, comparação de parsers e exploração de lógica de negócio. As duas abordagens podem se complementar, mas produzem evidências diferentes.

O nome Cloudflare também não deve confundir esta página com Cloudflare Troubleshooting, dedicada a DNS, TLS, redirecionamentos e origem. O projeto auditado aqui foi publicado pela Cloudflare, mas não se limita à plataforma Cloudflare e não altera configurações de zona por conta própria.

Compatibilidade e pré-requisitos

O mantenedor descreve a Skill como neutra em relação ao agente. Na prática, o cliente precisa carregar Agent Skills, oferecer ferramentas de leitura de arquivos e suportar delegação paralela com papéis independentes. O SKILL.md fixado chama esse mecanismo de Task tool e pede agentes de pesquisa e agentes generalistas. Cada plataforma deve mapear esses papéis sem eliminar as fronteiras de independência.

O fluxo integral requer Node.js para executar o validador da quinta fase. O schema está em report-schema.json, e a implementação oficial fica em validate-findings.cjs. Esse script não está no ZIP local e precisa ser obtido e auditado na origem antes do uso funcional.

O projeto-alvo também determina requisitos adicionais. Uma biblioteca pode exigir compilador e suíte de testes. Uma API pode depender de serviços locais. Um componente nativo pode precisar de sanitizadores, depurador ou harness isolado. A presença desses recursos não autoriza execução automática. Liste comandos, dependências, rede, tempo, armazenamento e dados envolvidos antes de permitir qualquer teste.

Instalação recomendada

O README documenta o comando npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit. O procedimento e a opção global estão no README do commit auditado. Como npx consulta a rede, executa um pacote e grava arquivos, comece em um projeto de teste e confira o destino e o diff antes de aceitar.

Evite a instalação global no primeiro contato. Fixe o commit 8bac42001ddd90a4dcd8d5a5045199283a8eba75, compare os arquivos instalados com o diretório oficial fixado e leia a licença MIT preservada. O site Skills CLI explica o instalador, mas a origem do conteúdo continua sendo o repositório da Cloudflare.

Use o ZIP do Bastidores apenas para inspeção documental. Como o validador executável foi removido, copiar esse recorte para a pasta ativa de Skills cria uma instalação incompleta. Para operar todas as fases, obtenha o conjunto integral da origem oficial, verifique o script e mantenha a versão aprovada registrada.

Configuração antes do primeiro uso

Defina dois caminhos explícitos: o alvo e o diretório de saída. O alvo deve ser um clone ou snapshot autorizado, preferencialmente sem credenciais e sem acesso de escrita ao repositório principal. O diretório de saída deve ficar fora do código analisado para que relatórios, payloads e rastros não sejam incluídos por engano em commits ou pacotes.

Depois estabeleça limites. Quantos agentes podem rodar? Eles podem criar subagentes? Quais comandos estão liberados? Há rede? Builds podem baixar dependências? Testes podem tocar banco, filas ou serviços? Payloads ofensivos podem sair do ambiente local? Um bom briefing transforma cada resposta em uma regra verificável. A permissão para ler código não inclui automaticamente autorização para atacar uma implantação.

Separe também dados e segredos. Tokens, arquivos .env, chaves, dumps, cookies, dados pessoais e relatórios anteriores podem aparecer no repositório ou no histórico. Use cópia saneada quando possível. Se o agente precisar de um segredo para reproduzir uma falha, trate isso como nova autorização, nunca como detalhe implícito.

Primeiro uso seguro

Escolha uma biblioteca pequena ou serviço de laboratório sem dados reais. Comece apenas com a fase de reconhecimento e leia architecture.md. O documento deve explicar o que o software faz, quem o chama, onde dados não confiáveis entram, quais identidades existem e quais arquivos sustentam essa conclusão. Se essa base estiver errada, a caça seguinte ficará precisa no lugar errado.

Na fase de caça, limite o primeiro ciclo a três ou quatro agentes e classes pertinentes ao alvo. O arquivo de código nativo MEMORY-SAFETY-AND-BINARY.md só faz sentido para C, C++, Rust inseguro, kernels, parsers e binários. Sistemas com modelos e ferramentas usam AI-AND-LLM.md.

Gateways, proxies e autenticação têm um roteiro próprio em WEB-PROTOCOL-AND-AUTH.md. Aplicações de navegador usam CLIENT-SIDE.md. Não distribua todas as classes por reflexo. Escopo amplo demais multiplica custo, ruído e risco de executar uma hipótese no ambiente errado.

Como o fluxo deve funcionar

O ciclo começa pelo modelo de confiança. Cada agente deve seguir o dado da entrada ao destino, verificar ramos de erro, condições de fronteira, operações concorrentes e diferenças entre parsers. Uma suspeita precisa sobreviver a testes de autorização, comportamento esperado e mitigação em outras camadas. A pergunta não é apenas se falta uma proteção, mas se alguém consegue atravessar o limite e obter algo que não deveria.

Depois, agentes separados tentam refutar os achados. Eles conferem caminhos, funções, condições, controles e impacto. A referência VALIDATION-AND-REPORTING.md determina os relatórios e a verificação final. Findings rejeitados não devem continuar no resumo humano com linguagem ambígua.

O arquivo estruturado precisa corresponder ao relatório. O schema exige veredito, causa raiz, comportamento esperado, rastreio por arquivo e linha, condições, execução, correção, severidade e confiança. Passar na validação JSON prova somente estrutura. Não prova que o endpoint existe, que o payload chega ao sink ou que a correção funciona.

Resultado esperado

Uma execução correta entrega architecture.md, REPORT.md, FINDINGS-DETAIL.md e findings.json. O relatório principal apresenta somente vulnerabilidades confirmadas ou declara honestamente que nenhuma falha explorável foi encontrada. O documento detalhado preserva os rastros de achados médios ou superiores, e o JSON permite automação sem inventar campos fora do schema.

Cada finding confirmado deve responder quem ataca, qual acesso inicial possui, quais entradas envia, por quais funções o dado passa, qual controle falha e qual resultado observável comprova o impacto. A severidade combina probabilidade e dano. Um desvio de checklist que não atravessa uma fronteira fica fora da lista de vulnerabilidades.

O resultado não é uma certificação. O próprio projeto afirma que execuções adicionais podem explorar caminhos diferentes. A publicação da Cloudflare sobre a evolução do método está em Build your own vulnerability harness. O texto mostra a relação com um sistema maior, mas não transforma uma única execução local em cobertura completa.

Permissões, privacidade e riscos

O risco principal é alcance. A Skill pode ler grande parte do repositório, inclusive configuração, histórico, testes e arquivos gerados. Pode sugerir ou executar builds, payloads, fuzzing e harnesses. Pode criar relatórios com nomes de arquivos, linhas, rotas, condições e segredos encontrados. Limite pastas, faça uma cópia do alvo e mantenha toda saída privada até a triagem responsável.

A delegação aumenta a superfície. Agentes de caça podem abrir subagentes, e o método recomenda paralelismo. Isso consome contexto, tempo e recursos e pode espalhar trechos sensíveis entre várias execuções. Fixe quantidade, papel e escopo de cada agente. O agente que valida deve ser independente do que encontrou o problema, mas todos continuam sujeitos às mesmas permissões do ambiente.

Testes dinâmicos merecem aprovação separada. Um payload seguro contra um parser local pode ser inadequado contra um serviço compartilhado. Não execute exploração em produção, sistemas de terceiros ou infraestrutura pública sem autorização específica. Se a confirmação depender de uma implantação indisponível, marque o achado como requer teste de implantação e não o publique como confirmado.

Erros comuns

Transformar ausência de defesa extra em vulnerabilidade. Verifique se outra camada bloqueia o ataque. Se bloqueia, registre endurecimento, não eleve a severidade.

Usar linhas antigas. O repositório pode mudar depois da auditoria. Fixe commit e valide novamente caminhos e linhas antes de entregar ou corrigir.

Confundir JSON válido com fato verificado. O validador confere estrutura e enums. Um agente independente ainda precisa reler o código e confrontar todas as afirmações.

Instalar o ZIP documental como pacote completo. O recorte local não inclui validate-findings.cjs. Use-o para leitura. A execução funcional deve vir da origem oficial auditada.

Rodar agentes demais sem arquitetura. Paralelismo antes de um mapa de confiança confiável produz repetição e falsos positivos. Corrija architecture.md primeiro.

Apagar findings rejeitados sem registro. Preserve a razão factual da rejeição no processo interno, mas retire alegações incorretas do relatório destinado a decisão.

Versão, licença e origem verificadas

A curadoria foi refeita em 06/09/2026. A API pública do GitHub registrou 3.239 estrelas, repositório público, não arquivado e licença MIT. O commit fixado é 8bac42001ddd90a4dcd8d5a5045199283a8eba75, e o último commit específico do SKILL.md é c1239b903704f5ea063b6dc0de3ba905f4cca3e4. O arquivo não declara uma versão semântica.

Confira o repositório oficial, o commit auditado e o histórico de commits antes de atualizar. Estrelas medem interesse, não segurança, qualidade nem adequação ao seu alvo.

O pacote local tem doze arquivos textuais e SHA-256 87016d879ae43dbb352ed14fef5a203ed2427565e4436e56804f80957263f1af. Ele não inclui o script executável, Node.js, Skills CLI, dependências, código analisado, relatórios, findings, payloads, credenciais, tokens, cookies ou dados. A licença MIT permite redistribuição com preservação do aviso, que acompanha o ZIP.

Checklist antes de automatizar

• Registre autorização, proprietário, alvo, commit e diretório de saída.
• Use clone ou snapshot saneado, sem escrita no repositório principal.
• Defina quantidade de agentes, rede, comandos, tempo e armazenamento.
• Leia todos os arquivos da Skill e audite o script excluído antes do uso funcional.
• Comece pelo reconhecimento e corrija o modelo de confiança.
• Escolha somente classes de ataque pertinentes ao software.
• Exija ataque concreto, impacto e evidência reproduzível.
• Faça validação adversarial com agente independente.
• Compare relatório humano, detalhes e JSON.
• Revise manualmente cada afirmação antes de divulgar ou corrigir.

Fontes primárias

• Repositório oficial cloudflare/security-audit-skill.
• Árvore completa no commit auditado.
• README com instalação, requisitos e visão das fases.
• Licença MIT do projeto.
• SKILL.md auditado.
• Reconhecimento, caça e validação e relatório.
• Schema de findings e validador oficial excluído do ZIP.
• Artigo técnico da Cloudflare sobre o harness.