Cloudflare libera skill para auditar vulnerabilidades con IA

¿Qué es security-audit-skill y por qué Cloudflare lo libera?

Cloudflare publicó como open source bajo licencia MIT su security-audit-skill, un paquete para coding agents que ejecuta auditorías de seguridad en seis fases orquestadas. En pruebas internas del propio equipo, una sola corrida encuentra cerca de la mitad de las vulnerabilidades que aparecen tras varias corridas repetidas sobre el mismo repositorio, según el README del proyecto.

El paquete es el punto de partida mínimo —un único repositorio— a partir del cual Cloudflare construyó un harness interno de detección de vulnerabilidades de múltiples etapas y desplegado sobre toda su flota, descrito en el post corporativo Build your own vulnerability harness. La versión abierta conserva la arquitectura de fases pero apunta a un solo repo a la vez.

Cómo funciona una auditoría de seguridad en seis fases

El skill no solo orquesta agentes: trae un catálogo curado de clases de ataque divididas por superficie. El repositorio incluye archivos específicos para memory safety y binarios, IA y LLM, web y autenticación, DOM del lado cliente, supply chain, cloud y deployment, RPC y messaging, resource exhaustion, data isolation y desktop/móvil. Cada hunt se ancla en una de esas clases, lo que evita el patrón clásico del auditor junior que busca "todo a la vez" y termina confirmando nada.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La pipeline en sí tiene validadores escritos en Node.js sin dependencias externas. Cada fase deja artefactos en disco y se valida contra un esquema antes de pasar a la siguiente:

Reconocimiento: el agente mapea arquitectura, límites de confianza, superficies de entrada y cobertura previa, y deja el resultado en architecture.md y coverage-ledger.json. El coverage ledger es la pieza clave: evita que el auditor "rellene" hallazgos para inflar el reporte.
Caza dirigida por cobertura: reparte unidades del ledger entre hunters aislados; cada check queda registrado y un coverage critic busca huecos antes de cerrar la fase.
Validación de candidatos: cada candidato único se entrega a un verificador "fresco" cuya única tarea es intentar refutarlo.
Salida estructurada: los hallazgos se escriben en findings.json y se validan contra report-schema.json.
Verificación independiente de registros: agentes nuevos vuelven a leer el código citado en cada hallazgo y confirman que la fuente sigue diciendo lo que el reporte afirma.
Reporte target-neutral: el sistema genera REPORT.md, FINDINGS-DETAIL.md y NEEDS-VALIDATION.md a partir únicamente de los registros verificados.

El README es explícito en una regla que define toda la arquitectura: "el agente que verifica un hallazgo nunca es el mismo agente que lo descubrió". Los tres veredictos posibles —confirmed, needs_validation y rejected— tienen criterios distintos: solo confirmed exige trazabilidad completa de la fuente y resultado observado acotado; needs_validation mantiene un hecho no resuelto sin severidad, y rejected registra candidatos refutados.

Por qué importa para el ecosistema de seguridad

Tres señales del mercado hacen que un skill así deje de ser curiosidad y pase a ser infraestructura.

1. El volumen de CVEs explotó. El NIST reportó que los envíos de vulnerabilidades a la base Common Vulnerabilities and Exposures (CVE) crecieron 263% entre 2020 y 2025, y que el primer trimestre de 2026 superó en casi un tercio al mismo periodo del año anterior, según un artículo de Nextgov. La propia agencia reconoció en un blog de agosto que el enriquecimiento manual no da abasto y derivó a un enfoque basado en riesgo.

2. Los propios vendors de IA ya están ejecutando esto internamente. Google Mandiant lleva diez meses operando AVDH (Agentic Vulnerability Discovery Harness), un pipeline de agentes especializados que encontró más de 100 vulnerabilidades verificadas de alta severidad en apenas dos días durante una investigación real sobre repositorios corporativos robados, según un post de Help Net Security de agosto. El sistema produjo 12 CVEs asignados —incluidos CVE-2026-13242 y CVE-2026-55803— y mantiene "una docena adicional en disclosure activa". El detalle clave: cada hallazgo confirmado pasa por reproducción humana antes de contar, lo que coincide con el principio adversarial del skill de Cloudflare.

3. El patrón "agente auditor + agente verificador" se está volviendo commodity. En Black Hat 2026, Palo Alto Networks, SentinelOne, Bugcrowd (Savant Pathseeker) y Snyk (Evo Continuous Offensive Security) presentaron versiones de pentesting continuo basado en agentes, según un repaso de CRN sobre el evento. Cloudflare entra en esa misma conversación, pero en formato abierto, descargable y con menos dependencias externas.

La diferencia con un escáner tradicional. Un SAST clásico compara el código contra reglas y patrones conocidos. Un harness como este (security-audit-skill o AVDH) encadena agentes que primero modelan la amenaza, después hipotetizan sobre entry points, y por último someten cada hallazgo a un verificador independiente. La consecuencia práctica es menos ruido: en lugar de miles de warnings sin contexto, el reporte final trae vulnerabilidades con trazabilidad de fuente y veredicto claro.

¿Qué significa esto para tu startup?

Si tu producto es SaaS, fintech, healthtech o cualquier vertical donde una vulnerabilidad rompe el negocio, la pregunta ya no es si vas a auditar tu código con IA, sino cómo auditas sin que la IA te mienta.

Empieza por el sandbox, no por el modelo. El propio README exige un entorno con red externa deshabilitada, recursos limitados y allowlists. Sin estos controles, el skill degrada los hallazgos dudosos a needs_validation en lugar de ejecutar el código. La calidad del reporte depende más de tu infraestructura de aislamiento que del modelo que elijas.
Separa quien encuentra de quien verifica. El principio "el verificador nunca es quien descubrió" no es decoración: es lo único que separa una vulnerabilidad real de un falso positivo que contamina tu backlog. Diseña los prompts para que cada candidato pase por al menos dos agentes distintos antes de tocar un ticket.
Mide con código sintético, no con datasets públicos. Mandiant construyó codebases sintéticos con vulnerabilidades conocidas para evaluar AVDH, según Help Net Security, precisamente porque sospechaba que los modelos ya habían visto los datasets públicos durante el entrenamiento. Si entrenas tu propio benchmark, hazlo igual: las vulnerabilidades que están en internet probablemente ya están en los pesos del modelo.
No confundas defensa en profundidad con vulnerabilidad. El skill marca una anti-patrón explícita en su SKILL.md: si la capa A ya previene el ataque, la ausencia de la capa B es una nota de hardening, no un finding. Esto evita inflar el backlog con "te falta rate limiting" cuando ya hay autenticación robusta.

Para probarlo hoy: instala el skill con npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit, apunta tu coding agent a un repositorio sandbox y pide un "security audit". El primer reporte aparece en ~/security-audit-skill/<repo>/run-1 y conviene revisar los hallazgos marcados como confirmed antes de moverlos a Jira.