Cloudflare publica su skill de auditoría de seguridad con IA: así funciona

Cloudflare ha publicado un skill de código abierto que ofrece a los agentes de programación compatibles un proceso estructurado para auditar una base de código. La idea central es sencilla: una sospecha generada por IA sigue siendo una hipótesis hasta que alguien rastrea el código fuente, comprueba el límite de confianza e intenta refutarla de forma independiente.

La diferencia importa. Encontrar una función que parece arriesgada no demuestra que un atacante pueda alcanzarla y afectar a un recurso protegido. El repositorio security-audit-skill de Cloudflare integra ese recorrido de evidencias en el proceso.

Ilustración de Plexicus. Todos los detalles de interfaz —incluidos los contadores de estrellas y forks del repositorio— son elementos simulados, no datos actuales del repositorio de Cloudflare ni una captura de un producto de Cloudflare.

¿Qué publicó Cloudflare como código abierto?

El repositorio público contiene un skill para agentes de programación que audita un repositorio: instrucciones, guías de clases de ataque, reglas de validación, esquemas y scripts para generar registros de auditoría. Se distribuye con licencia MIT. Este skill fue el punto de partida de un sistema interno más amplio, pero no equivale a todo ese sistema.

En su artículo del 18 de junio de 2026, «Build your own vulnerability harness», Cloudflare describió primero un flujo original de siete pasos y explicó cómo evolucionó hasta convertirse en un sistema interno de descubrimiento de vulnerabilidades. El repositorio público actual describe seis fases. Las dos descripciones corresponden a versiones y alcances distintos; no deben combinarse en una sola secuencia.

Cloudflare indicó que su sistema interno para varios repositorios cubrió 128 repositorios en unas seis semanas. La arquitectura interna incorpora orquestación persistente y triaje posterior que no se obtienen automáticamente al instalar el skill público. El proyecto abierto se entiende mejor como un método auditable para un solo repositorio, que los equipos pueden adaptar.

¿Qué incluye el repositorio?

Incluye SKILL.md, con las reglas del flujo y de seguridad; guías de reconocimiento y búsqueda; referencias de clases de ataque para temas como IA/LLM, protocolos web, cadena de suministro, nube y código del cliente; VALIDATION-AND-REPORTING.md; report-schema.json; y validadores de Node.js sin dependencias para los hallazgos y el registro de cobertura.

El registro documenta qué partes del sistema se revisaron, quién las examinó y qué evidencias respaldan esa cobertura. Los hallazgos siguen un esquema que separa problemas confirmados, hipótesis sin resolver e hipótesis refutadas. Estos artefactos facilitan la revisión del trabajo, pero su mera existencia no demuestra que cada conclusión sea correcta.

Las seis fases siguientes corresponden al modo de auditoría completa (Full audit mode). De forma predeterminada, el skill funciona en modo de orientación: para preguntas o revisiones específicas usa solo la guía pertinente y no inicia automáticamente las seis fases ni crea artefactos de auditoría.

Las seis fases actuales

1. Reconnaissance — reconocimiento

El agente mapea la arquitectura, los principales usuarios y servicios, los puntos de entrada, los recursos sensibles y los límites de confianza. Guarda el resultado en architecture.md y crea coverage-ledger.json con unidades de trabajo definidas de forma determinista. Así se ve el alcance y se pueden detectar áreas sin revisar.

2. Coverage-led hunting — búsqueda guiada por cobertura

Hunters aislados reciben unidades del registro, documentan las comprobaciones realizadas e investigan hipótesis vinculadas a límites de seguridad reales. Los críticos de cobertura buscan huecos. Es más concreto que pedir a varios agentes que «analicen el código»: se registran tanto las tareas como las evidencias de cobertura.

Una hipótesis útil identifica la capacidad inicial del atacante, el recurso protegido, la ruta por la aplicación y el posible cruce de límites. Por ejemplo, un controlador que obtiene una factura mediante un ID no demuestra por sí solo un fallo de autorización. Hay que comprobar si el usuario controla el ID, si otra capa valida la propiedad y si la solicitud puede cruzar el límite entre organizaciones.

3. Candidate validation — validación de candidatos

Un verificador nuevo recibe cada hipótesis única e intenta refutarla. Comprueba si la entrada está bajo control del atacante, si la ruta es alcanzable, si existe una protección en otra parte y si las evidencias muestran un impacto de seguridad real. El agente que detecta el hallazgo no valida su propio resultado.

4. Structured output — resultados estructurados

El skill guarda los hallazgos en findings.json con veredictos distintos:

Un validador de esquema comprueba la estructura. Por sí solo no demuestra que la vulnerabilidad sea explotable; por eso la validación es una fase separada.

5. Independent record verification — verificación independiente de los registros

Agentes nuevos revisan las afirmaciones finales sobre el código fuente y sus evidencias. Si un registro se sustituye de manera sustancial, la nueva versión recibe otra comprobación independiente. Se revisa el informe como registro de seguridad, no solo se repite la investigación original.

6. Target-neutral reporting — informes neutrales respecto al objetivo

Los registros verificados y el ledger producen REPORT.md, FINDINGS-DETAIL.md y NEEDS-VALIDATION.md. El equipo puede ver qué se confirmó, qué sigue sin resolver y qué áreas se cubrieron, sin que la incertidumbre se presente como un hecho.

El skill público frente al sistema interno de Cloudflare

El artículo de lanzamiento de Cloudflare describe un Vulnerability Discovery Harness (VDH) y un Vulnerability Validation System (VVS). El VDH organiza la investigación del código fuente y genera hipótesis de vulnerabilidad. El VVS realiza el análisis posterior: elimina duplicados, evalúa la aplicabilidad en producción, prioriza y deriva trabajo a ingeniería. El sistema mayor también incorpora persistencia entre repositorios, contexto cruzado y ciclos de retroalimentación operativa.

Este contexto ayuda a interpretar los resultados de Cloudflare. El skill público puede estructurar una auditoría, pero el usuario todavía necesita un entorno de agente compatible, controles de ejecución seguros y una forma de evaluar la exposición específica del despliegue. No se debe asumir que todas las funciones del sistema interno forman parte del repositorio independiente.

¿Qué significan las cifras publicadas por Cloudflare?

Cloudflare publicó cifras de su sistema interno en junio de 2026. Son resultados operativos comunicados por la empresa, no una evaluación independiente del skill público.

La cifra de 128 corresponde al alcance inicial de la flota VDH. El conjunto combinado del VVS abarcaba 145 repositorios. Son poblaciones distintas y no deben mezclarse. También importa el cálculo: los 7.245 elementos accionables resultan de restar del conjunto combinado los duplicados y los elementos reciclados de bajo riesgo o asociados al repositorio equivocado.

«Accionable» no significa «explotable de forma confirmada en un sistema de producción expuesto a Internet». Los datos de Cloudflare describen investigación aislada y su propio contexto operativo; algunos registros procedían de instantáneas que pueden quedar obsoletas cuando cambia el código o la configuración. Las cifras muestran escala y triaje, no una tasa universal de detección ni un recuento de fallos explotables desde el exterior.

Cloudflare también reconoce que no puede calcular una tasa fiable de falsos negativos sin conocer todas las vulnerabilidades existentes. Indicó que una ejecución detectó aproximadamente la mitad de los problemas encontrados tras varias ejecuciones en sus experimentos. Es un resultado de esas pruebas, no una afirmación de que el skill detecte la mitad de las vulnerabilidades de cualquier proyecto.

Skill de auditoría, SAST y pentesting

El skill complementa otros métodos de AppSec; no los sustituye. SAST puede analizar código de forma repetible para detectar patrones y flujos de datos conocidos. Una auditoría con agentes añade una revisión explícita de arquitectura y límites de confianza, registros de cobertura y revisión adversarial. Cada método tiene modos de fallo distintos, y los analizadores estáticos modernos también pueden razonar entre funciones y componentes.

Una auditoría centrada en el código tampoco es un pentest en tiempo de ejecución. El análisis de código puede seguir una comprobación de autorización y reproducir localmente un comportamiento acotado. Un pentest autorizado puede probar un entorno desplegado con cuentas aprobadas y un alcance definido, y mostrar cómo influyen la configuración de ejecución, los proveedores de identidad, los gateways y la infraestructura. Ningún método por sí solo demuestra la seguridad completa.

No dirijas el skill a un objetivo en vivo ni interpretes el activador «pen-test» como permiso para probar un servicio desplegado. El flujo documentado es defensivo y empieza por el código fuente. Cualquier build, prueba, proceso, navegador, emulador, fuzzer o fixture controlado por el objetivo debe ejecutarse en un sandbox impuesto por el sistema operativo que desactive la red externa, use un entorno saneado y limitado por una allowlist, aplique límites de recursos y restrinja las escrituras a rutas temporales asignadas. Sin esos controles, el flujo indica que la hipótesis debe permanecer como needs_validation y que no se ejecute el código del objetivo. Evalúa únicamente código y entornos propios o expresamente autorizados.

Instalación segura

El README del proyecto documenta la instalación con Skills CLI:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

Para instalarlo a nivel de usuario, añade --global. Inicia un agente de programación compatible dentro de un repositorio autorizado o apúntalo a ese repositorio y solicita una auditoría. Los validadores del proyecto requieren Node.js; el agente debe admitir uso de herramientas y subagentes paralelos.

Instalar el skill no crea un sandbox del sistema operativo. Configura los controles del sistema antes de permitir la ejecución de código controlado por el repositorio. Respeta las condiciones de tratamiento de datos aprobadas por tu organización, usa identidades y datos de prueba, impide que las builds descarguen dependencias y no heredes credenciales. Antes de actuar, revisa el registro de cobertura, las evidencias de cada afirmación y todos los cambios propuestos.

Qué implica para los equipos de AppSec

La contribución más valiosa es la disciplina del proceso: registrar qué se examinó, separar hipótesis de hallazgos confirmados, cuestionar cada candidato de forma independiente y conservar la pregunta exacta que sigue sin respuesta cuando faltan pruebas. Esto puede facilitar la revisión de la investigación asistida por agentes. No garantiza cobertura completa, un comportamiento constante del modelo ni impacto en producción.

En un programa AppSec más amplio, los equipos aún deben correlacionar los hallazgos del código con el contexto de ejecución, la propiedad, la exposición y las pruebas de corrección. Para evaluar aplicaciones en ejecución dentro de un alcance autorizado, puedes explorar Plexicus AI Swarm Pentest como un enfoque independiente de pruebas en tiempo de ejecución. No forma parte del skill de análisis de código fuente de Cloudflare, y ambos métodos no son equivalentes. Evalúa cada enfoque por las evidencias que puede aportar para el alcance autorizado; la publicación de Cloudflare no demuestra capacidades de otros productos.

El criterio práctico es sencillo: evalúa un resultado de seguridad por la trazabilidad de las pruebas, el límite que demuestra, la incertidumbre que conserva y la posibilidad de reproducirlo y corregirlo, no por el número de hallazgos de un panel.

Preguntas frecuentes

¿El skill de Cloudflare es gratuito?

El repositorio usa la licencia MIT. El uso del modelo, el cómputo y el entorno del agente pueden tener costes.

¿El skill público es el sistema interno de Cloudflare?

No. El proyecto público sirve como punto de partida para un repositorio. El sistema interno añade orquestación de flota, validación y triaje posteriores, descritos en el blog de Cloudflare.

¿Corrige vulnerabilidades automáticamente?

El skill público se centra en auditoría, validación e informes. Cloudflare describe flujos de corrección separados en su sistema interno, con pruebas de regresión y revisión humana. No deben atribuirse al skill independiente.

¿La verificación independiente elimina los falsos positivos?

No. Sirve para cuestionar afirmaciones sin fundamento y dejar visible la incertidumbre. No garantiza clasificaciones perfectas ni que no se haya pasado por alto una vulnerabilidad.

¿Puedo usarlo contra un sitio web de producción?

No uses este flujo de auditoría del código para sondear servicios activos. La validación en ejecución requiere autorización explícita y un alcance seguro definido por separado; los requisitos de ejecución documentados se refieren a código local aislado.

Fuentes

• Cloudflare, Build your own vulnerability harness, 18 de junio de 2026.
• Cloudflare, repositorio y README de security-audit-skill.
• Cloudflare, instrucciones del Security Audit skill.