Ya puedes auditar la seguridad de tu código con IA usando security-audit, el skill MIT que Cloudflare usó como base de su harness interno de vulnerabilidades. Se instala con un solo npx skills add y funciona con cualquier coding agent capaz de lanzar subagentes en paralelo. Al momento de escribir esta nota, el repositorio es tendencia en GitHub: 6,2 mil estrellas, 1,2 mil de ellas en un solo día.
Lo que lo separa de pedirle a tu agente que “busque bugs” es que no se fía de su primera respuesta. Los agentes que encuentran un candidato a vulnerabilidad nunca son los que lo confirman. Todo lo que no tenga un atacante concreto, un límite de confianza cruzado y un resultado observable termina rechazado o queda abierto.
¿Qué es el skill security-audit de Cloudflare?
Es un conjunto de instrucciones, prompts y dos validadores pequeños que convierte a un coding agent generalista en un auditor de seguridad estructurado. Cloudflare lo liberó junto con su artículo del 18 de junio de 2026, Build your own vulnerability harness, donde explica que su sistema de escaneo a escala de toda su flota de repositorios nació de este skill de un solo repositorio, y que sus prompts todavía conservan casi sin cambios los escenarios de ataque y las clases de bugs del skill original.
No depende de ningún agente concreto. SKILL.md describe roles genéricos —un agente parent que coordina, agentes research para lectura enfocada del código y agentes general para investigación más amplia— y le pide a tu agente que use el mecanismo de subagentes que tenga su plataforma.
¿Cómo hace el análisis de vulnerabilidades?
Una auditoría completa recorre seis fases en orden:
- Reconocimiento. Agentes en paralelo mapean la arquitectura, los límites de confianza, los puntos de entrada y las rutas de build locales. Todo queda en
architecture.mdy en un plan de cobertura,coverage-ledger.json. - Caza guiada por cobertura. Agentes cazadores (hunters) aislados toman unidades del plan y las atacan por clase: inyección, control de acceso, lógica de negocio, brechas de confianza entre componentes y más. Tras cada ola, agentes críticos de cobertura buscan huecos.
- Validación de candidatos. Cada candidato pasa a un verificador nuevo cuyo trabajo es refutarlo.
- Salida estructurada. Todos los resultados se escriben en
findings.jsony se validan contra un esquema JSON. - Verificación independiente. Agentes nuevos vuelven a comprobar las afirmaciones finales contra el código fuente.
- Reporte.
REPORT.md,FINDINGS-DETAIL.mdyNEEDS-VALIDATION.mdse generan solo a partir de los registros ya verificados.
El orden importa: el reporte se escribe al final, después de la verificación, así que la prosa para humanos no puede contradecir el registro en JSON.
Durante el reconocimiento, el skill también decide cuáles de sus diez archivos especializados cargar: por ejemplo, AI-AND-LLM.md para prompt injection y MCP, SUPPLY-CHAIN-AND-RELEASE.md para CI y firma de releases, o MEMORY-SAFETY-AND-BINARY.md para código nativo. Las instrucciones son explícitas: un archivo se selecciona porque existe un límite de confianza real, no porque aparezca el nombre de un lenguaje o de una dependencia en el repo.
¿Modo guía o auditoría completa?
Cargar el skill no arranca por sí solo las seis fases. Por defecto trabaja en modo guía: responde preguntas de seguridad y hace revisiones puntuales sin crear un directorio de salida. El flujo completo se activa solo cuando pides explícitamente auditar o hacer un pen test de un código, una revisión completa o archivos de reporte. Si tu petición admite las dos lecturas, te pregunta antes.
¿Cómo instalar security-audit?
Instálalo con la CLI de Skills:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
Para una instalación a nivel de usuario en lugar de por proyecto, agrega --global:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit \
--global
Otras opciones útiles de la CLI: --list muestra los skills del repositorio sin instalar nada, -a, --agent elige en qué agentes instalarlo y -y omite las confirmaciones. Ejecuta npx skills --help para ver la lista completa.
¿Cómo hacer una auditoría de seguridad de tu repositorio?
Abre tu coding agent en el repositorio y pide la auditoría en lenguaje natural. El README da estos ejemplos:
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
Si no indicas un directorio de salida, los resultados van a ~/security-audit-skill/<repo-name>/run-<N>, fuera de tu repositorio, así que ningún hallazgo termina en un commit por accidente. El skill solo escribe dentro del repo si eliges explícitamente un directorio que el control de versiones ignore.
¿Quick, standard o deep?
Una auditoría completa tiene tres perfiles:
quickhace una sola ola de caza y una pasada crítica, pensado para objetivos pequeños o una primera mirada.standardes el perfil por defecto.deepdivide el trabajo con más detalle y mantiene la validación y la verificación final como agentes separados, para código grande o crítico.
También puedes acotar la ejecución a rutas concretas, a un subsistema, a un dominio especializado o al diff entre dos refs del código. En ese caso el skill marca el reporte como cobertura parcial.
Cambiar de perfil cambia cuánto terreno cubre la auditoría, no cuánta evidencia exige. Incluso quick mantiene el filtro de validación y la verificación independiente de los hallazgos confirmados.
¿Qué necesitas antes de ejecutarlo?
Según el README, tres cosas:
- Un coding agent cuyo modelo soporte tool use y subagentes en paralelo.
- Node.js, para los dos validadores, que no tienen dependencias.
- Un sandbox aplicado por el sistema operativo para cualquier build, test o proceso que ejecute código del propio objetivo. Debe tener:
- sin acceso a red externa,
- un entorno construido a partir de una lista explícita de variables permitidas,
- el objetivo en solo lectura, con escritura permitida únicamente en un directorio
scratch/asignado, - límites explícitos de CPU, memoria, procesos y tiempo.
Lee con calma ese tercer requisito. Si tu entorno no puede garantizar todos esos controles, el skill no toma atajos: no ejecuta el código del objetivo y marca la pista como needs_validation, con el bloqueo exacto y un plan seguro para resolverlo.
Si usas Claude Code, tiene un /sandbox integrado que aísla el sistema de archivos y la red para los comandos bash. Revisa si tu configuración también cumple los requisitos de entorno y de límites de recursos antes de contar con la reproducción local.
El skill también es estricto con sus propios límites: nada de sondear endpoints desplegados ni infraestructura compartida, nada de instalar dependencias durante la auditoría y solo principales, fixtures y secretos ficticios. Describe las correcciones, pero no modifica tu código.
¿Es gratis?
El skill es open source con licencia MIT; el costo está en el uso del modelo, y una auditoría multiagente consume bastante más que un solo prompt. El skill hace ese gasto contable: a grandes rasgos, una unidad del plan equivale a una asignación de cazador, y cada candidato que sobrevive necesita uno o dos verificadores según el perfil.
Puedes fijar un presupuesto como número máximo de llamadas a agentes. El skill reserva las llamadas de crítica y validación antes de empezar a cazar. Si el presupuesto no alcanza ni para el mínimo, no lanza ningún agente y te lo dice, en lugar de entregarte en silencio una auditoría más pobre.
Como referencia, Cloudflare describe los escaneos completos de su harness como barridos periódicos del backlog que pueden tardar horas en un repo complejo, no como un chequeo por PR. Eso aplica al harness, no a este skill, pero es una buena pista de dónde encaja este tipo de auditoría.
¿Cómo leer los resultados del escaneo de vulnerabilidades?
Empieza por findings.json. Cada registro tiene uno de tres veredictos:
confirmed: una traza completa en el código fuente y un resultado observado y acotado. Solo estos reciben severidad (critical,high,medium,lowoinformational).needs_validation: una hipótesis concreta, anclada en el código, bloqueada por un único dato sin resolver, como una configuración de proxy o una política de identidad que no está en el repo. No reciben severidad. Son preguntas abiertas, no vulnerabilidades de baja confianza.rejected: un candidato que la validación refutó. Se conserva para que las próximas ejecuciones no lo vuelvan a perseguir.
El skill ejecuta los dos validadores por su cuenta, y tú puedes volver a ejecutarlos:
node <skill-dir>/validate-findings.cjs <output-dir>/findings.json
node <skill-dir>/validate-coverage-ledger.cjs <output-dir>/coverage-ledger.json
Una ejecución solo puede terminar de dos maneras: con todos los reportes escritos y ambos validadores en verde, o con run_status: "incomplete" y el motivo exacto declarado en el reporte.
¿Por qué ejecutarlo más de una vez?
Según las pruebas del propio Cloudflare, una sola ejecución encontró aproximadamente la mitad de las vulnerabilidades que hallaron varias ejecuciones en total. Es un dato autorreportado por Cloudflare. Cada ejecución lee los planes y hallazgos anteriores, vuelve a revisar todo lo que cambió en el código y se concentra en los huecos. Un hallazgo confirmed previo solo se arrastra si su código no cambió y sigue superando la verificación.
Claude Code security review o security-audit: ¿cuál usar?
Resuelven problemas distintos, y muchos equipos van a querer los dos:
- El comando
/security-reviewde Claude Code hace, según la documentación de Anthropic, una revisión de seguridad bajo demanda sobre los cambios de tu rama actual. Es rápido, vive dentro de tu flujo habitual y sirve para revisar el trabajo antes de hacer commit. security-auditaudita un código completo (o una parte acotada). Construye un plan de cobertura, intenta refutar sus propios candidatos y deja un registro legible por máquina que puedes ampliar ejecución tras ejecución. Se parece más a una auditoría programada que a un paso de revisión.
Si leíste nuestra nota sobre VulnHunter, el cazador de vulnerabilidades open source de Capital One, el enfoque te va a resultar familiar: razonar desde el atacante y verificarse a sí mismo de forma adversarial. El skill de Cloudflare pone más peso en el seguimiento de cobertura, en el veredicto explícito needs_validation y en no depender de ningún agente concreto.
¿Funciona con Cursor, Codex u otros agentes?
Está diseñado para eso. SKILL.md se describe como agnóstico respecto al agente, y la CLI de Skills puede instalar en muchos agentes, entre ellos Cursor y Codex. El requisito práctico es el del README: tu agente y tu modelo tienen que soportar tool use y subagentes en paralelo. Confírmalo antes de esperar una auditoría completa.
Si todavía no trabajas con skills, aquí tienes una selección de skills para agentes de IA para empezar.
¿Qué relación tiene con el harness de Cloudflare?
El skill es el punto de partida para un solo repositorio; el harness es lo que Cloudflare construyó encima. Según su artículo, el harness agrega:
- estado persistente en SQLite,
- agentes de deduplicación,
- trazado de dependencias entre repositorios,
- un sistema de triage separado que usa un modelo distinto al de la fase de descubrimiento,
- un agente que genera correcciones, cuyos parches igual requieren revisión humana antes del merge.
Las cifras del harness en ese artículo son de Cloudflare y describen el harness, no el skill:
- 20.799 candidatos en bruto, de los que unos 12.057 superaron la validación.
- Un pool combinado de 13.841 hallazgos (incluida la salida de otro harness), de los que quedaron 7.245 accionables tras la deduplicación y el triage.
- Una caída de la tasa de rechazo en la validación inicial del 40 al 11 gracias a un mejor contexto del reconocimiento.
Cuando publicó el artículo, Cloudflare dijo que esperaba liberar pronto el harness. Al momento de publicar esta nota, Cloudflare no había liberado el harness.
¿Cómo evitar instalar una copia no oficial?
Instálalo siempre desde github.com/cloudflare/security-audit-skill y lee SKILL.md antes de ejecutar nada. Los skills populares atraen copias, y en el directorio de skills ya figura al menos un reempaquetado de terceros con otro nombre. El ecosistema ya produjo skills que roban credenciales, y un auditor de seguridad es justo lo último que quieres sacar de una fuente no oficial.
¿Vale la pena?
Sí, si lo usas como fue pensado. security-audit es esa rara herramienta de seguridad más estricta con lo que no afirma que con lo que encuentra. Pruébalo primero con el perfil quick sobre un servicio pequeño, lee findings.json antes que REPORT.md y trata cada registro needs_validation como una pregunta para el dueño del servicio, no como un bug. Después, ejecútalo otra vez.