# Cómo auditar la seguridad de tu código con IA usando el skill que liberó Cloudflare

**URL:** https://www.yodev.dev/t/como-auditar-la-seguridad-de-tu-codigo-con-ia-usando-el-skill-que-libero-cloudflare/5358
**Category:** Cybersecurity
**Tags:** vulnerabilidades, seguridad, pentesting, auditoria-de-seguridad, claude-code, skills, agent-skills, cloudflare
**Created:** [16 Septiembre, 2026 17:41 UTC](https://www.yodev.dev/t/como-auditar-la-seguridad-de-tu-codigo-con-ia-usando-el-skill-que-libero-cloudflare/5358 "2026-09-16T17:41:38Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Team](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/team/32/2092_2.png) [@Team](https://www.yodev.dev/u/Team)
#### Post date: [16 Septiembre, 2026 17:41 UTC](https://www.yodev.dev/t/como-auditar-la-seguridad-de-tu-codigo-con-ia-usando-el-skill-que-libero-cloudflare/5358/1 "2026-09-16T17:41:38Z")

</div>

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:

1. **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.md` y en un plan de cobertura, `coverage-ledger.json`.
2. **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.
3. **Validación de candidatos.** Cada candidato pasa a un verificador nuevo cuyo trabajo es refutarlo.
4. **Salida estructurada.** Todos los resultados se escriben en `findings.json` y se validan contra un esquema JSON.
5. **Verificación independiente.** Agentes nuevos vuelven a comprobar las afirmaciones finales contra el código fuente.
6. **Reporte.** `REPORT.md`, `FINDINGS-DETAIL.md` y `NEEDS-VALIDATION.md` se 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:

```bash
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`:

```bash
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:

```auto
security audit this codebase

```

```auto
find security vulnerabilities in ./src

```

```auto
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:

- **`quick`** hace una sola ola de caza y una pasada crítica, pensado para objetivos pequeños o una primera mirada.
- **`standard`** es el perfil por defecto.
- **`deep`** divide 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`, `low` o `informational`).
- **`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:

```bash
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-review` de 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-audit`** audita 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](https://www.yodev.dev/t/vulnhunter-como-poner-el-cazador-de-vulnerabilidades-de-capital-one-a-trabajar-sobre-tu-propio-repo/3917), 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](https://www.yodev.dev/t/las-mejores-skills-para-agentes-de-ia-21-que-hacen-codear-a-tu-ia-como-un-senior/2418) 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](https://www.yodev.dev/t/las-skills-que-instalas-en-tu-agente-de-ia-pueden-estar-robandote-las-credenciales/2048), 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.

> **[GitHub - cloudflare/security-audit-skill: A coding-agent skill for multi-phase security...](https://github.com/cloudflare/security-audit-skill)**
>
> A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings
