Cloudflare Security Audit Skill

En términos sencillos, Security Audit Skill es un framework de orquestación para auditorías de seguridad mediante IA.

Su flujo completo es:

Reconnaissance → Coverage-led Hunting → Candidate Validation → Structured Output → Independent Verification → Reporting

En otras palabras:

primero entender el código → después buscar vulnerabilidades según la cobertura → hacer que otro Agent cuestione los hallazgos → crear registros estructurados → realizar una verificación independiente → generar el informe final.

Esto es bastante diferente de un SAST tradicional. Las herramientas SAST son especialmente útiles para detectar patrones conocidos mediante reglas y análisis de flujo de datos, mientras que Security Audit Skill se acerca más a una investigación estructurada de seguridad realizada por un Coding Agent.

Pero tampoco es simplemente una «versión automatizada de un experto en seguridad». Lo que realmente cambia es la forma en que el Agent lleva a cabo una auditoría de seguridad.

¿Qué problema de la IA intenta resolver?

Un Coding Agent convencional tiene una limitación natural cuando realiza auditorías de seguridad:

encontrar algo sospechoso es fácil; demostrar que realmente es una vulnerabilidad es mucho más difícil.

Por ejemplo, si el Agent encuentra:

Entrada del usuario → consulta SQL

puede informar inmediatamente de una posible SQL Injection.

Sin embargo, el código real podría utilizar parámetros mediante un ORM, filtros previos, comprobaciones de permisos o una plantilla de consulta fija.

También puede ocurrir lo contrario: una vulnerabilidad real puede estar escondida entre varios módulos, tareas asíncronas o rutas de error, y un único Agent que intenta revisar todo el proyecto de principio a fin puede pasarla por alto.

Por eso, Security Audit Skill establece que una vulnerabilidad debe poder explicar quién es el atacante, cuál es la entrada, qué frontera de seguridad atraviesa, qué recurso se ve afectado y cuál es el resultado de seguridad real. La simple ausencia de una buena práctica no es suficiente para considerar que existe una vulnerabilidad.

Esta es probablemente su idea más importante:

una auditoría de seguridad no consiste en encontrar código sospechoso, sino en demostrar que una frontera de seguridad ha sido realmente superada.

¿Por qué el primer paso no es buscar vulnerabilidades, sino hacer Recon?

La fase de Reconnaissance comienza construyendo una visión de la arquitectura, las fronteras de confianza, las superficies de entrada y el alcance de la auditoría. Como resultado, genera archivos como architecture.md y coverage-ledger.json.

A primera vista puede parecer un proceso más lento, pero en realidad aborda uno de los problemas que más fácilmente se pasan por alto en una auditoría realizada por IA:

¿qué has comprobado exactamente?

coverage-ledger.json combina superficies de entrada, fronteras de confianza, subsistemas y categorías de ataque para crear unidades concretas de auditoría. También registra qué elementos ya han sido cubiertos, cuáles no son aplicables y cuáles han quedado bloqueados o pospuestos.

Por eso, el informe final no debería limitarse a decir:

«Hemos comprobado la autenticación, la base de datos y las API».

Debería poder responder a preguntas como:

«¿Qué puntos de entrada se han revisado? ¿Qué fronteras de seguridad se han comprobado? ¿Qué rutas no se han analizado? ¿Por qué?»

Es un cambio importante.

El Coverage Ledger no existe para que el informe parezca más profesional, sino para convertir la “cobertura” de una afirmación en lenguaje natural en una evidencia que pueda rastrearse.

¿Qué sentido tiene utilizar varios Agents para Hunting?

En la segunda fase no se pide a un único Agent que analice todo el proyecto de principio a fin. En su lugar, el Coverage Ledger se utiliza para distribuir el trabajo entre varios Hunters aislados, cada uno centrado en diferentes superficies de ataque.

El conocimiento de seguridad incluido actualmente en el Skill cubre áreas como Web Protocol/Auth, Client-side, AI/LLM, Supply Chain, Cloud/Deployment, RPC/Messaging, Resource Exhaustion y Data Isolation, además de Desktop/Mobile/Local IPC, Memory Safety/Binary y otros dominios.

Esto resulta más interesante que utilizar simplemente una checklist de OWASP.

Por ejemplo, un proyecto de AI/LLM puede necesitar revisar Prompt Injection, Memory, Tool Calling o MCP como fronteras de confianza específicas. Un proyecto nativo, en cambio, puede requerir prestar atención a FFI, Parser, Lifetime, ABI y seguridad de memoria.

Por tanto, el verdadero valor de los múltiples Agents no es:

«Diez IAs son más inteligentes que una».

Es dividir una base de código grande en varias tareas de auditoría con límites bien definidos, reduciendo la posibilidad de que un Agent pierda rutas importantes cuando el contexto del proyecto se vuelve demasiado grande.

Lo más interesante: hacer que otro Agent intente refutar el hallazgo

La tercera fase, Candidate Validation, es probablemente la parte más interesante de todo el diseño.

La tarea del Agent que descubre problemas es:

Encontrar vulnerabilidades.

La del Agent encargado de validarlas es justo la contraria:

Demostrar que la vulnerabilidad no existe.

Cloudflare exige que el Agent de validación vuelva a leer toda la ruta de código relevante y compruebe si la entrada controlada por el atacante realmente puede llegar al objetivo, cuál es el impacto real, si existe alguna otra capa de seguridad que bloquee el ataque y si el comportamiento del Parser o del Runtime coincide con las hipótesis utilizadas.

En la práctica, esto utiliza una característica de la IA para contrarrestar otra.

Una IA puede interpretar fácilmente un «patrón peligroso» como una «vulnerabilidad», porque encontrar problemas forma parte de su objetivo.

Pero si utilizas un Agent diferente y le dices:

tu trabajo no es demostrar que existe una vulnerabilidad, sino intentar destruir este posible falso positivo,

la dirección del razonamiento cambia.

Por supuesto, esto no significa que dos IAs equivalgan a dos expertos humanos independientes en seguridad. Pueden compartir los mismos sesgos del modelo, lagunas de conocimiento e incluso hipótesis incorrectas.

Aun así, frente a un escenario en el que el mismo descubridor decide por sí solo que su hallazgo es válido, este enfoque de validación adversarial introduce al menos una barrera adicional de revisión independiente.

¿Por qué Structured Output es más importante que un simple informe?

Security Audit Skill no termina cuando el Agent escribe un documento titulado «Informe de auditoría de seguridad».

Los resultados deben registrarse en findings.json, y su estructura se comprueba mediante report-schema.json y scripts de validación.

El sistema distingue explícitamente entre:

• confirmed
• needs_validation
• rejected

Especialmente importante es needs_validation.

Significa que:

el Agent ha encontrado una hipótesis de seguridad respaldada por el código, pero falta un hecho importante para confirmarla, por lo que no puede presentarla como una vulnerabilidad ya demostrada.

Esto resulta mucho más útil que obligar a la IA a asignar una gravedad «High» sin tener pruebas suficientes.

Además, findings.json vuelve a ser revisado posteriormente por otro Agent. Este comprueba si las rutas de archivos, números de línea, puntos de entrada del ataque, formatos de entrada, condiciones de autenticación y recomendaciones de corrección realmente corresponden al código fuente.

En la práctica, el proceso termina siendo:

descubrir → refutar → estructurar → volver a verificar.

Es claramente diferente de una revisión puntual realizada por un Coding Agent convencional.

¿Realmente encuentra más vulnerabilidades?

Aquí hay que ser prudente.

Cloudflare ha publicado un dato especialmente interesante: las ejecuciones múltiples son acumulativas y, en sus pruebas, una única ejecución encontraba aproximadamente la mitad de las vulnerabilidades que finalmente aparecían después de varias ejecuciones.

Esto revela algo importante:

incluso utilizando una orquestación compleja de Agents, una única auditoría mediante IA no debe interpretarse como una comprobación completa.

En un artículo de Cloudflare sobre su Vulnerability Harness también se destaca que encontrar candidatos a vulnerabilidades mediante IA es cada vez más barato, mientras que convertir esos candidatos en correcciones de código fiables y verificables sigue siendo la parte difícil. El propio Harness continúa evolucionando y no se presenta como una solución ya perfecta.

Por tanto, la información pública de Security Audit Skill permite afirmar que utiliza un método de auditoría más estructurado y mecanismos de validación más estrictos, pero no permite deducir una tasa fija de descubrimiento, recall o capacidad para sustituir a un investigador de seguridad.

Es importante mantener separados estos conceptos:

capacidad de descubrimiento ≠ cobertura ≠ capacidad de validación ≠ baja tasa de falsos positivos ≠ capacidad profesional de investigación de seguridad.

El Sandbox es otro aspecto importante que puede pasar desapercibido

Security Audit Skill impone requisitos bastante estrictos al entorno de ejecución.

Si es necesario ejecutar código objetivo, pruebas, navegadores, Fuzzers o Emulators, debe utilizarse un Sandbox a nivel de sistema operativo que limite la red, las variables de entorno, los recursos y los directorios en los que se puede escribir.

Si estos controles no pueden garantizarse, el Agent no debería ejecutar directamente el código objetivo simplemente para «comprobarlo». En ese caso, el resultado debe permanecer como needs_validation.

La lógica detrás de esto es especialmente importante:

el propio Agent que realiza una auditoría de seguridad también es un programa automatizado con privilegios, por lo que debe tratarse como una posible superficie de ataque.

No tendría sentido que, para verificar una vulnerabilidad, el Agent terminara ejecutando un comportamiento malicioso del código auditado en el ordenador del desarrollador, en producción o dentro de una red real.

Este es precisamente uno de los problemas que rara vez aparecen en un simple Prompt del tipo «IA, encuentra las vulnerabilidades de mi proyecto».

Sus limitaciones actuales también son evidentes

En primer lugar, este flujo necesita un Coding Agent compatible con llamadas a herramientas y Sub-Agents paralelos. También depende de un validador basado en Node.js y de un Sandbox adecuado.

En segundo lugar, utilizar múltiples fases y Agents implica un mayor consumo de Tokens y recursos de computación. En proyectos grandes, dividir el código según un Coverage Ledger detallado y después ejecutar varias rondas de Hunting, Validation y Verification puede resultar costoso.

En tercer lugar, múltiples Agents no significan necesariamente independencia real.

Si todos utilizan el mismo modelo, pueden compartir exactamente la misma interpretación incorrecta.

En cuarto lugar, el código fuente no puede responder a todas las preguntas de seguridad. Las reglas de Cloudflare indican que si la validez de una vulnerabilidad depende de información externa al repositorio, como proxies, despliegue, políticas de identidad o configuración cloud, el Agent no debe inventar una respuesta. Debe marcar el resultado como needs_validation.

Esto es al mismo tiempo una limitación y una característica positiva:

es preferible reconocer que «no se sabe» antes que permitir que la IA fabrique una vulnerabilidad como si fuera un hecho confirmado.

¿Para quién es Security Audit Skill?

Está especialmente pensado para desarrolladores y equipos que ya utilizan Coding Agents como Claude Code o Codex y quieren incorporar IA a sus procesos de revisión de seguridad.

Puede tener sentido especialmente en:

• Proyectos SaaS y Web
• Aplicaciones AI/LLM
• Proyectos Open Source
• Flujos DevSecOps
• Equipos que necesitan repetir auditorías de seguridad del código
• Profesionales interesados en investigar el uso de AI Security Agents

También puede utilizarse en proyectos personales, pero no tiene mucho sentido ejecutar una auditoría completa de seis fases cada vez que cambias un par de Buttons.

El escenario donde resulta especialmente interesante es aquel en el que el proyecto es complejo, existen muchas fronteras de permisos, el código cambia continuamente y los problemas de seguridad necesitan dejar evidencias que puedan rastrearse.

Valoración final

El principal valor de Cloudflare Security Audit Skill no consiste en convertir la IA en un escáner de vulnerabilidades más inteligente, sino en transformar el proceso de “dejar que la IA mire el código y busque vulnerabilidades” en una orquestación de Agents mucho más cercana a una auditoría de seguridad real.

Primero exige establecer el alcance y la cobertura; después busca vulnerabilidades candidatas; separa al descubridor del validador; mantiene los resultados inciertos como needs_validation; exige evidencias en el código fuente y finalmente hace que otro Agent revise de nuevo esas evidencias.

Este enfoque aborda algunos de los problemas más complicados de la auditoría de seguridad mediante IA:

falsos positivos, vulnerabilidades omitidas, falta de evidencias, cobertura imposible de demostrar e inconsistencias entre el informe y el código fuente.

Sin embargo, todavía no debería entenderse como un equipo de seguridad automatizado. La información pública disponible no demuestra una tasa de recall suficientemente estable como para hacer esa afirmación, ni demuestra que utilizar múltiples Agents elimine los puntos ciegos compartidos por los modelos. La propia Cloudflare también destaca la importancia de realizar múltiples ejecuciones.

Valoración general: 4,6/5,0

La puntuación se basa principalmente en el diseño del proceso de auditoría, el registro de cobertura, la validación adversarial, las evidencias estructuradas y los límites de seguridad del entorno de ejecución. Las principales limitaciones son el coste de ejecución, los requisitos del entorno, el riesgo inherente de que la IA pase por alto vulnerabilidades y la necesidad de profesionales para analizar el entorno de despliegue y los problemas de seguridad más complejos.

Si una auditoría realizada por un Coding Agent convencional se resume en:

«Comprueba si hay vulnerabilidades».

Security Audit Skill se acerca más a:

«Demuestra qué has revisado → encuentra posibles problemas → intenta refutarlos → demuestra cuáles sobreviven → haz que otro Agent vuelva a comprobar las evidencias → genera finalmente el informe».

Este enfoque puede representar una dirección relevante para la evolución de las auditorías de seguridad con IA.

No se trata simplemente de conseguir que el modelo sea más inteligente, sino de hacer que, cuando se equivoque, resulte más difícil convertir directamente ese error en una conclusión de seguridad.