Security Audit Skill de Cloudflare: Auditorías IA con Hallazgos Verificados

1. Qué Es la Security Audit Skill

La descripción de GitHub es precisa: “A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings.” El README agrega que “orchestrates isolated agents through reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and target-neutral reporting.” Dicho en simple: tu agente pasa a ser el coordinador (la skill lo llama parent) y cada unidad de trabajo va a un subagente nuevo, con sus propias instrucciones y sin saber qué concluyeron los demás.

Lo que instalás es Markdown más dos scripts de Node: sin binario, sin servicio, sin API key propia. El modelo de tu agente hace la lectura y el razonamiento; la skill aporta el método — quién hace qué, qué cuenta como hallazgo, qué evidencia necesita y cómo probarlo. Por eso mismo los resultados dependen del agente y del modelo con que la ejecutes, y por eso el mismo repo puede dar resultados distintos en distintas ejecuciones.

2. La Arquitectura en 4 Pasos

El README lista seis fases. Yo las agrupo en cuatro pasos, porque las fases 3 y 5 son verificación independiente y las fases 4 y 6 son salida:

3. Quickstart con Claude Code

El README lista tres requisitos. El tercero es el que casi todos se saltan:

Instalala con la Skills CLI. Estos son los comandos del propio README — primero a nivel de proyecto, después a nivel de usuario con --global:

# Project-level install (README)
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

# User-level install, available in every repo (README)
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

Para saltarte el selector de agentes y apuntar directo a Claude Code, la Skills CLI documenta -a (agente) y -y (omitir las confirmaciones). Su tabla de agentes coloca las skills de Claude Code en .claude/skills/ para un proyecto y en ~/.claude/skills/ a nivel global:

# Target Claude Code only and skip the prompts (-a and -y from the Skills CLI docs)
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit -a claude-code -y

# Project: .claude/skills/security-audit/
# Global (--global): ~/.claude/skills/security-audit/

Después abrí Claude Code dentro del repo que querés auditar (o apuntando a él) y pedíselo. Estos tres prompts salen tal cual del README; la skill se activa con pedidos como “security audit”, “find vulnerabilities” o “pen-test the code”, y también podés invocarla explícitamente con /security-audit:

security audit this codebase

find security vulnerabilities in ./src

do a security review, output to ~/audits/my-project

Dos comportamientos que conviene conocer antes de apretar enter. Primero, un pedido directo de auditoría o pentest ejecuta el modo full audit, mientras que una pregunta de seguridad o una revisión acotada usa el modo guidance, que no escribe archivos de auditoría; si el pedido es ambiguo, SKILL.md le indica al agente que te haga primero una sola pregunta. Segundo, la salida va por defecto a ~/security-audit-skill/<repo-name>/run-<N>, fuera de tu repo. Solo escribe dentro del objetivo si elegís explícitamente un directorio que el control de versiones ignore.

SKILL.md también define tres perfiles de ejecución — quick (una oleada de hunters, un critic final, un verificador por candidato), standard (el predeterminado) y deep (unidades más finas, oleadas de critics hasta una pasada limpia, verificadores separados) — más ejecuciones acotadas a rutas concretas, a un subsistema o al diff entre dos refs, y un presupuesto opcional medido en invocaciones de agentes. El perfil se toma de tu pedido, así que simplemente lo indico (la redacción es mía; lo escribo en inglés, como los ejemplos del README):

security audit this codebase, quick profile, scoped to src/api, budget 20 agents

Cuando termine la ejecución, volvé a correr vos los validadores. Estas son las invocaciones de VALIDATION-AND-REPORTING.md, con las rutas que generan una instalación de Claude Code a nivel de proyecto y el directorio de salida predeterminado:

node .claude/skills/security-audit/validate-findings.cjs \
  ~/security-audit-skill/my-api/run-1/findings.json

node .claude/skills/security-audit/validate-coverage-ledger.cjs \
  ~/security-audit-skill/my-api/run-1/coverage-ledger.json

4. Cómo Es la Salida

Un directorio de ejecución en modo full audit, armado a partir de los archivos que definen SKILL.md y las guías de fase (los comentarios son mi resumen):

~/security-audit-skill/my-api/run-1/
├── run-metadata.json      # run_id, repo, source_ref, profile, scope_paths, budget, run_status
├── architecture.md        # phase 1 map: stack, principals, trust boundaries, entry surfaces
├── coverage-ledger.json   # units: planned → in_progress → covered | candidate | blocked | deferred
├── findings.json          # confirmed + needs_validation + rejected records
├── REPORT.md              # profile, scope, posture, findings table, coverage summary
├── FINDINGS-DETAIL.md     # full trace + local reproduction for medium/high/critical
├── NEEDS-VALIDATION.md    # leads with exact blockers and resolution plans, no severity
└── agents/<agent-id>/
    ├── scratch/           # the only place a sub-agent (and target code) may write
    └── artifacts/         # parent-owned, filled only by the safe promotion procedure

findings.json es un array de registros, cada uno con un veredicto. El schema usa additionalProperties: false, así que cada veredicto tiene un contrato de campos estricto:

Así es la forma de un registro confirmed. Los nombres de campo salen de report-schema.json; los valores son un ejemplo inventado por mí, recortado con “…”:

[
  {
    "verdict": "confirmed",
    "fingerprint": "api/invoices:cross-tenant-read",
    "title": "Invoice lookup skips the tenant check",
    "description": "…",
    "root_cause": "findInvoiceById filters by id only, not by tenant_id",
    "intended_behavior": "Users can read only invoices of their own tenant",
    "trace": [
      { "kind": "entrypoint", "file": "src/routes/invoices.ts", "line": 42,
        "scope": "GET /invoices/:id", "description": "…" },
      { "kind": "sink", "file": "src/db/invoices.ts", "line": 17,
        "scope": "findInvoiceById", "description": "…" }
    ],
    "evidence": [{ "file": "src/db/invoices.ts", "line": 17, "description": "…" }],
    "conditions": [{ "kind": "authentication_level", "description": "Any logged-in user" }],
    "execution": {
      "attacker_perspective": "Dummy user of tenant A",
      "payloads": ["GET /invoices/1002"],
      "instructions": ["Run the dummy-tenant integration test inside the sandbox", "…"],
      "observed_result": "The tenant B dummy invoice is returned with HTTP 200"
    },
    "remediation": { "strategy": "Scope the query by the session tenant_id", "code_changes": [] },
    "severity": {
      "likelihood": { "score": "high", "reason": "…" },
      "impact": { "score": "high", "reason": "Cross-tenant read" },
      "overall_severity": "high"
    },
    "confidence": { "score": "high", "reason": "…" }
  }
]

Como es JSON plano, el triage es una sola línea. Mi jq para listar los hallazgos confirmados con su severidad:

jq -r '.[] | select(.verdict=="confirmed") | "\(.severity.overall_severity)\t\(.title)"' \
  ~/security-audit-skill/my-api/run-1/findings.json

5. Costo, Límites de Uso y Sandbox

La skill es gratis; ejecutarla no. No hay un precio oficial por ejecución, pero los archivos te dicen cómo escala el gasto:

Después, el sandbox. Las reglas de “Universal execution safety” de SKILL.md aplican en ambos modos: la inspección del código es de solo lectura, y cualquier compilación, test, proceso, navegador, emulador, fuzzer o fixture controlado por el objetivo corre solo dentro de un sandbox impuesto por el sistema operativo con todos estos controles:

¿Cómo se compara el sandbox propio de Claude Code? Según su documentación, /sandbox usa Seatbelt en macOS y bubblewrap en Linux y WSL2, limita la escritura al directorio de trabajo (más un directorio temporal y los que agregues) y enruta el tráfico de red por un proxy cuya allowlist empieza vacía. Pero la documentación no menciona límites de CPU, memoria ni procesos, las variables de entorno se heredan salvo que las deniegues (sandbox.credentials.envVars o CLAUDE_CODE_SUBPROCESS_ENV_SCRUB), y si el sandbox no puede arrancar, los comandos corren sin él salvo que sandbox.failIfUnavailable sea true. Mi lectura: una capa útil, no el conjunto completo de controles que pide la skill.

6. Una Rutina Semanal o de CI con Sentido

El repo no documenta integración con CI, ni GitHub Action, ni un modo por PR, y el post de Cloudflare es explícito: “The Fixer never merges code on its own; a human must review the branch.” Lo que sigue es mi sugerencia, no algo que traiga el proyecto:

En modo headless, así es más o menos como la ejecutaría con Claude Code. Es un borrador sin probar: cada flag sale de la documentación headless de Claude Code, pero ajustá los permisos a tu entorno — Bash(node *) es amplio y solo es aceptable en una máquina desechable:

# Weekly sketch (mine, untested end to end): run it on a disposable VM, not your laptop
mkdir -p ~/security-audit-skill
cd ~/src/my-api && git pull --ff-only

claude -p "/security-audit Full security audit of this codebase, quick profile, scoped to src/api" \
  --add-dir ~/security-audit-skill \
  --permission-mode acceptEdits \
  --allowedTools "Bash(node *)" \
  --max-budget-usd 30 \
  --output-format json > ~/security-audit-skill/last-run.json

RUN=$(ls -d ~/security-audit-skill/my-api/run-* | sort -V | tail -1)
node .claude/skills/security-audit/validate-findings.cjs "$RUN/findings.json"
node .claude/skills/security-audit/validate-coverage-ledger.cjs "$RUN/coverage-ledger.json"
jq -r '.[] | select(.verdict=="confirmed") | "\(.severity.overall_severity)\t\(.title)"' "$RUN/findings.json"

7. Dónde Brilla: Casos de Uso

Donde creo que justifica lo que consume:

El patrón: código que es tuyo, límites que importan y una persona que va a leer la evidencia. Ese es el perfil para el que se escribieron las reglas de la skill.

8. Cuándo NO Usarla

Es un método sólido, no un botón mágico. Límites honestos:

Conclusión

La skill security-audit es el tipo de repo en tendencia más interesante: no una herramienta nueva, sino un método puesto por escrito — hunters aislados, verificadores adversariales, un coverage ledger y un schema estricto — que cualquier agente de código capaz puede seguir. Unas 48K estrellas en poco más de cuatro meses, 15K de ellas en una sola semana, dicen que muchos equipos quieren exactamente esa disciplina alrededor de la revisión de código con IA.

Mi sugerencia: instalala a nivel de proyecto, empezá con una ejecución quick y acotada sobre un servicio que conozcas bien, revisá a mano los registros confirmed y fijate si la lista de needs_validation coincide con las preguntas que te harías vos. Si se gana su lugar, pasala a un runner desechable con una ejecución semanal. Y antes de instalar cualquier skill de terceros — esta incluida — leela o escaneala primero.