Haz una auditoría de seguridad con IA de tu código: la skill de Cloudflare

Cada vez más código se escribe con un asistente de IA. Eso es productivo, y crea un problema silencioso: el mismo modelo que escribió una función suele ser el que se encarga de juzgar si es segura. Cloudflare acaba de publicar como código abierto una forma de romper ese bucle, y la práctica que hay detrás merece adoptarse uses o no sus herramientas.

Qué ha publicado Cloudflare

Cloudflare ha publicado cloudflare/security-audit-skill, una skill pública de auditoría de seguridad con licencia MIT, neutral respecto al agente e independiente de cualquier arnés concreto. Las skills tienen doble filo: Claude Red, un paquete de 78 skills de seguridad ofensiva en GitHub, es la versión del lado del atacante, y la razón por la que los paquetes de skills necesitan un responsable y un inventario. Es la semilla, para un único repositorio, del arnés de descubrimiento de vulnerabilidades que Cloudflare describe en Build your own vulnerability harness. Lee ese artículo para ver el diseño completo; este resume las partes sobre las que puede actuar un responsable de seguridad.

Las seis fases

• 1. Reconocimiento. Cartografía la arquitectura, los límites de confianza y las superficies de entrada en architecture.md y en un coverage-ledger.json, para que la auditoría sepa qué existe antes de empezar a buscar.
• 2. Búsqueda guiada por la cobertura. Agentes cazadores aislados trabajan una clase de ataque cada vez, mientras críticos de cobertura buscan huecos en lo que se ha examinado.
• 3. Validación de candidatos. Un agente verificador nuevo e independiente intenta refutar cada candidato. Sobrevivir a una segunda mirada hostil es lo que le gana a un hallazgo su sitio.
• 4. Salida estructurada. Los resultados se convierten en registros confirmed, needs_validation o rejected en findings.json, validados contra un esquema.
• 5. Verificación independiente de los registros. Los propios registros se comprueban de forma independiente.
• 6. Informe. Un REPORT.md neutral respecto al objetivo resume el resultado.

La disciplina que lo hace útil

La idea más reutilizable no es el pipeline, sino el listón de lo que cuenta como hallazgo. Un hallazgo tiene que nombrar cuatro cosas: un límite de confianza real, un principal de menor confianza, el control que se ha cruzado y un resultado observado concreto. Si no puedes completar las cuatro, no tienes una vulnerabilidad.

Esa regla separa dos cosas que los equipos confunden constantemente. Una «buena práctica ausente sin ninguna violación alcanzable de un límite» es endurecimiento, que merece hacerse pero pertenece a otra cola. Solo los hallazgos confirmados reciben una gravedad. El estado needs_validation se reserva para una hipótesis concreta y basada en el código que está bloqueada por un dato que no está en el código, como la configuración real de producción. No es un cajón de sastre para sospechas vagas.

Si alguna vez has hecho el triaje de un informe de escáner con cientos de filas y ningún camino alcanzable, ya sabes por qué importa. Es el mismo motivo por el que un buen programa de métricas de seguridad cuenta la exposición validada y explotable y no el volumen bruto de alertas.

Por qué ayuda una segunda pasada con un modelo independiente

Este es el argumento a favor de la independencia. Es nuestro razonamiento sobre por qué funciona el patrón, no el resultado de un benchmark, y deberías probarlo con tu propio código.

Un modelo que construyó una funcionalidad arrastra los supuestos que hizo al construirla. Si le pides que revise su propio trabajo en la misma sesión, tiende a confirmar esos supuestos: la entrada «obviamente» se validó antes, quien llama «nunca» pasaría ese valor. Un modelo distinto, en un arnés distinto, con un contexto limpio y un checklist riguroso, no comparte esos supuestos. No tiene ningún coste hundido en el diseño y es más probable que haga la pregunta incómoda.

La misma lógica explica el verificador de la fase 3. Un agente aparte cuya única tarea es refutar un candidato se comporta como un revisor de código que no escribió el cambio. Y como el valor viene del proceso (checklists, aislamiento, seguimiento de la cobertura, registros estructurados) y no de la capacidad bruta del modelo, un modelo más barato que sigue un checklist riguroso aún puede aportar una segunda perspectiva que le faltaba a quien lo construyó. Eso es lo que lo convierte en un control barato y repetible en lugar de un encargo puntual de consultoría.

Qué clases de ataque cubre

La skill abarca una amplia gama de clases:

• Web y autenticación
• Problemas de IA y LLM: inyección de prompts, abuso de herramientas y agentes, manejo inseguro de la salida
• Lado del cliente
• Cadena de suministro y publicación
• Nube y despliegue
• RPC, mensajería y webhooks
• Agotamiento de recursos
• Aislamiento y ciclo de vida de los datos
• Seguridad de memoria y binarios
• Escritorio, móvil e IPC

La cobertura de IA y LLM es la que a la mayoría de los equipos les falta hoy. Si publicas agentes que llaman a herramientas, nuestro MCP linter es una comprobación complementaria rápida del lado de las definiciones de herramientas, y los laboratorios permiten a tu equipo practicar los patrones de ataque de forma segura.

Cómo ponerlo en práctica

• Empieza con un repositorio y una rama. Elige un servicio que gestione autenticación, entradas no fiables o dinero. Ejecuta la skill desde un checkout limpio, con un modelo y un arnés distintos de los que ayudaron a escribir el código.
• Conserva los registros. El registro de cobertura y findings.json son tu pista de auditoría. Vuelve a ejecutarla tras cambios importantes y compara los resultados.
• Haz el triaje con la prueba de las cuatro partes. Todo lo que carezca de límite, principal, control y resultado observado va a la cola de endurecimiento, no a la de vulnerabilidades.
• Trata needs_validation como una tarea pendiente. Asigna a alguien que establezca el dato que falta, ya sea un ajuste de despliegue, una garantía de un componente anterior o un detalle del entorno.
• Combínalo con lo básico. Una auditoría con IA no sustituye al escaneo de secretos, la revisión de dependencias ni la revisión humana de los cambios de alto riesgo. Ejecuta un escaneo de secretos a la vez y explora el resto de las herramientas de PlayCISO para otras comprobaciones rápidas.
• Trata el resultado con cuidado. Los informes de auditoría describen tus debilidades en lenguaje claro. Guárdalos con los controles de acceso que darías a un informe de pentest, y ten cuidado con qué código fuente envías a cualquier proveedor de modelos externo.

Límites que conviene tener presentes

Las auditorías impulsadas por IA producen pistas, no garantías. Un informe limpio no demuestra que no haya vulnerabilidades, y los modelos pueden pasar por alto problemas o juzgar mal si algo es alcanzable. Las fases de verificación reducen los falsos positivos, pero una persona que entienda tu modelo de amenazas debe seguir revisando todo lo que vaya a determinar una calificación de gravedad, una divulgación o una decisión de publicación. Piénsalo como otro revisor independiente del equipo, uno que nunca se cansa y que cuesta muy poco volver a ejecutar.

La conclusión para los responsables de seguridad

A medida que la IA escribe más de tu código, la pregunta que hay que hacer en cada revisión de ingeniería es sencilla: ¿quién lo comprobó, y era independiente de lo que lo construyó? Un flujo de trabajo de código abierto, con licencia MIT y neutral respecto al arnés reduce casi a cero el coste de responder «sí». Pruébalo con un repositorio esta semana y júzgalo por lo que encuentre que tus desarrolladores y tus herramientas actuales no encontraron.