Auditoria de segurança

Orientação de segurança e revisão de vulnerabilidades da Cloudflare para codebases, APIs, serviços, CLIs, libs e daemons. Perguntas do dia a dia, ou fluxo completo de auditoria/pen-test quando você precisa de um relatório de verdade.

O que é Auditoria de segurança?

Auditoria de segurança (cloudflare/security-audit) dá aos agentes revisão disciplinada: orientação threat-aware no cotidiano, mais um caminho completo de auditoria/pen-test para revisões end-to-end explícitas e artefatos de relatório. Cobre apps, APIs, serviços, CLI, libs e daemons — findings acionáveis, não «tenha cuidado» genérico.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/cloudflare/security-audit-skill/tree/main/skills/security-audit

Installed? Explore more Programação e Desenvolvimento skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que Auditoria de segurança faz?

Encontre vulnerabilidades que violam um limite de confiança real e, em seguida, forneça aos proprietários as evidências de origem, a reprodução segura, a prioridade e a menor correção eficaz. Este é um fluxo de trabalho defensivo, orientado pela fonte. Um candidato sem um principal afetado concreto, recurso ou resultado de segurança não é uma descoberta confirmada.

Modos de operação

Esta habilidade é uma orientação por padrão. Carregá-la não autoriza o fluxo de trabalho completo de auditoria ou a criação de arquivos.

  • Modo de orientação: Para perguntas de segurança, revisões focadas, metodologia, triagem ou investigação de descobertas específicas, use apenas as partes relevantes desta habilidade. Não execute automaticamente todas as seis fases, crie um diretório de saída ou escreva artefatos de auditoria. Você pode iniciar agentes focados quando útil; eles retornam resultados para a tarefa atual.
  • Modo de auditoria completa: Use o fluxo de trabalho completo quando o usuário solicitar explicitamente auditar ou testar a segurança de uma base de código, pedir uma revisão de segurança completa, abrangente ou de ponta a ponta, ou solicitar artefatos de relatório. Execute todas as seis fases e escreva os arquivos definidos abaixo.

Se a solicitação puder significar qualquer um dos modos, faça uma pergunta focada antes de criar arquivos ou iniciar o fluxo de trabalho completo.

Terminologia da plataforma

Esta habilidade é neutra em relação ao agente:

  • Pai é o agente que coordena a execução e possui o estado compartilhado.
  • Ferramenta de tarefa é o mecanismo de delegação ou subagente da plataforma.
  • Agente pesquisa é um agente delegado para exploração focada da fonte e verificação factual.
  • Agente geral é um agente delegado para investigação ampla e execução local limitada.
  • tipo_de_subagente: em um cabeçalho nomeia qual destes dois papéis de agente delegado executa esse trabalho.

Use capacidades equivalentes da plataforma, preservando os limites de função, isolamento de escrita, prompt e independência.

Segurança universal de execução

Estas regras se aplicam em ambos os modos de operação. A inspeção da fonte é somente leitura. Execute builds, testes, processos, navegadores, emuladores, fuzzers e processamento de fixtures controlados pelo alvo apenas dentro de um sandbox imposto pelo SO que forneça todos estes controles:

  • sem rede externa; use apenas um namespace loopback isolado quando a verificação precisar de tráfego local cliente/servidor;
  • um ambiente vazio preenchido a partir de uma lista de permissões explícita com valores seguros, com HOME, diretórios temporários e caches locais ao scratch;
  • um alvo e toolchain somente leitura, com o processo controlado pelo alvo capaz de escrever apenas dentro de seu diretório scratch/ designado; e
  • limites explícitos baixos de CPU, memória, processos, tamanho de arquivo, disco e tempo real.

O agente, fora do processo controlado pelo alvo, pode fazer uma cópia descartável da fonte em um diretório scratch/ designado quando um build precisar escrever ao lado da fonte. No modo de orientação, não retenha arquivos controlados pelo alvo. No modo de auditoria completa, apenas código confiável do lado do pai pode promover o resultado não secreto mínimo para artifacts/ retidos, usando o procedimento sob Isolamento de escrita. Nunca exponha um diretório de saída retido (que não seja o próprio diretório scratch/ designado do agente), o diretório de outro agente, o diretório home do host, credenciais, sockets ou serviços compartilhados ao código alvo. Não instale dependências nem permita que builds as busquem. Use apenas ferramentas e dependências já disponíveis localmente. Se todos os controles não puderem ser aplicados, não execute o código alvo: relate a capacidade de sandbox ausente como um bloqueador de necessidade de validação e forneça um plano de validação seguro.

Use principals, fixtures e segredos fictícios. Não investigue endpoints implantados, serviços externos, infraestrutura compartilhada, identidades de produção, dados de outros usuários ou painéis de controle ativos. Não teste disponibilidade contra um processo ativo ou compartilhado, publique artefatos, altere versões, gaste cota de API paga ou continue além do efeito local mínimo necessário para estabelecer um defeito. Se o fato decisivo estiver fora da fonte ou da fixture do sandbox, relate-o como necessitando de validação.

Configuração de auditoria completa

No modo de auditoria completa, resolva estes valores antes do reconhecimento:

  • Diretório da habilidade: o caminho absoluto que contém este SKILL.md.
  • Alvo: o caminho absoluto da raiz do repositório sob revisão.
  • Nome do repositório: um identificador estável do repositório a partir do diretório ou do repositório Git local remoto.
  • Diretório de saída: um novo diretório gravável fora do alvo, com padrão ~/security-audit-skill/<nome-do-repo>/run-<N>, onde <N> é o próximo inteiro não utilizado. Use um diretório dentro do alvo apenas quando o usuário o selecionar explicitamente e o pai verificar que o controle de versão ignora o diretório inteiro. Caso contrário, pare e solicite um caminho externo.
  • Ref da fonte: o commit revisado e se a árvore de trabalho está suja. Não trate arquivos gerados ou modificados não revisados como outra revisão.

Isolamento de escrita

O pai cria e é o único escritor dos arquivos de execução compartilhados:

  • run-metadata.json
  • architecture.md
  • coverage-ledger.json
  • findings.json
  • REPORT.md
  • FINDINGS-DETAIL.md
  • NEEDS-VALIDATION.md

Cada caçador ou verificador recebe uma raiz única sob <output-dir>/agents/<id-do-agente>/, com diretórios scratch/ e artifacts/ separados. IDs de agente canônicos correspondem a ^[a-z0-9][a-z0-9_-]{0,63}$ e não devem ser iguais a um nome de dispositivo do Windows, como con, prn, aux, nul, com1 a com9 ou lpt1 a lpt9. IDs em minúsculas evitam colisões de maiúsculas/minúsculas. O agente e cada processo controlado pelo alvo podem escrever apenas em scratch/; artifacts/ retidos são de propriedade do pai, nunca expostos ao sandbox e graváveis apenas pelo código de promoção confiável do lado do pai. Agentes não podem alterar arquivos compartilhados, fonte do alvo, artefatos retidos ou o diretório de outro agente. Não use /tmp ou o diretório home do host como fallback gravável.

Antes da execução, o pai abre e retém descritores de diretório confiáveis e não herdáveis para as raízes scratch/ e artifacts/ do agente, e registra uma lista de permissões de arquivos de artefato esperados relativos ao scratch, mais limites explícitos de byte por arquivo e cumulativos. Nunca passe esses descritores para o agente ou sandbox. Após o sandbox e todos os seus processos terminarem, o código confiável do lado do pai promove cada arquivo da lista de permissões separadamente:

  1. Valide o caminho relativo declarado: rejeite componentes absolutos, vazios, ., .. ou com link simbólico.
  2. Percorra cada componente pai a partir do descritor de raiz scratch retido com operações relativas ao diretório sem seguir links; nunca reabra por caminho.
  3. Abra a folha sem seguir links e sem bloqueio.
  4. Verifique com fstat que é um arquivo regular com contagem de links exatamente um e dentro dos limites de byte por arquivo e cumulativos registrados.
  5. Aplique esses limites novamente durante a leitura a partir desse descritor.
  6. Copie exatamente o tamanho verificado, repita fstat e rejeite uma identidade, tipo, contagem de links ou tamanho alterados.
  7. Para o destino, percorra cada componente pai a partir do descritor de raiz artifacts retido com operações relativas ao diretório sem seguir links; exija que cada componente existente seja um diretório real, e crie qualquer diretório ausente exclusivamente antes de reabri-lo e verificar que não segue links.
  8. Crie a folha exclusivamente sem seguir links, verifique que o destino aberto é um arquivo regular com contagem de links exatamente um, e copie a partir do descritor de origem verificado sem reabrir nenhum dos caminhos.
  9. Use APIs equivalentes seguras contra condições de corrida em sistemas não POSIX.
  10. Nunca copie recursivamente ou faça glob no scratch, extraia um arquivo em artifacts, ou abra ou promova um link simbólico, FIFO, socket, dispositivo, diretório, arquivo com hard link, arquivo em alteração ou arquivo que exceda seu limite.
  11. Se alguma verificação não estiver disponível, não puder ser aplicada ou falhar, descarte a entrada scratch; se for evidência decisiva, retenha `needs_va

Habilidades Relacionadas