Cloudflare libera su auditor interno: lo importante es que rebate

Cloudflare publicó esta semana una skill que convierte a un agente de código en auditor de seguridad, y se ha convertido en el repositorio de crecimiento más rápido de la lista semanal de GitHub: unas 16,400 estrellas en siete días, 51.000 en total. La presentación de la propia empresa es de una modestia poco habitual: este es el punto de partida de un solo repositorio del que surgió su arnés interno de búsqueda de vulnerabilidades, publicado para que otros puedan construir el suyo.

Lo que merece la pena leer no es el catálogo de clases de ataque, aunque es amplio. Es la parte sobre cómo se rebaten los hallazgos.

Seis fases, una de ellas es pura contabilidad

El flujo de trabajo está estructurado, no es conversacional, y eso es lo primero que lo separa de «pídele a Claude que busque bugs».

La fase uno es reconocimiento: cartografiar la arquitectura, los límites de confianza, las superficies de entrada y, esto es lo inusual, dejarlo escrito en architecture.md y coverage-ledger.json. La fase dos asigna cazadores aislados a las unidades de ese registro, anota qué comprobó cada uno y luego ejecuta críticos de cobertura para encontrar lo que nadie miró. La fase tres entrega cada candidato único a un verificador nuevo cuyo trabajo es refutarlo. La fase cuatro escribe registros confirmed, needs_validation o rejected en findings.json y los valida contra un esquema JSON. La fase cinco hace que agentes nuevos verifiquen las afirmaciones finales sobre el código y cualquier sustitución material pasa por otro verificador independiente. La fase seis deriva los informes de los registros verificados.

Los dos validadores son scripts Node sin dependencias: validate-coverage-ledger.cjs se ejecuta tras crear el registro y después de cada actualización, y validate-findings.cjs en la fase cuatro y de nuevo tras cada sustitución de la fase cinco. Son los archivos menos interesantes del repositorio y la razón por la que todo lo demás se sostiene. Un agente que no puede producir un hallazgo válido según el esquema no puede afirmar que ha encontrado uno.

Los tres veredictos son el diseño real

Casi todas las herramientas de seguridad para agentes tienen dos salidas: una lista de bugs o nada. Esta tiene tres, y en la categoría intermedia está el pensamiento.

confirmed significa un rastro completo en el código fuente más un resultado acotado y observado. needs_validation significa un hecho sin resolver, exacto, y sin gravedad asignada. rejected significa un candidato refutado activamente, registrado en lugar de borrado.

El tercero es poco común y, creo, correcto. Un candidato refutado es evidencia sobre el código: le dice a la siguiente ejecución que no gaste tiempo ahí y le dice al revisor qué se consideró. Casi todas las herramientas tiran eso.

El principio de diseño que hay debajo está escrito sin rodeos en el README: confirmar solo fallos de frontera ya establecidos y, si una pista anclada en el código queda bloqueada, mantenerla como needs_validation con su hecho exacto sin resolver en lugar de ascenderla a hallazgo. Hay una regla relacionada: las carencias de defensa en profundidad no son vulnerabilidades. Si la capa A bloquea el ataque, la ausencia de la capa B es una nota de endurecimiento.

Quien haya leído un informe de vulnerabilidades generado por una máquina sabe exactamente por qué existen esas reglas. El modo de fallo de la revisión de seguridad con LLM no es perder bugs. Es ruido con confianza: patrones que parecen vulnerabilidades, reportados con gravedad alta, que le comen la semana a un equipo de triaje.

Validación adversarial, al pie de la letra

La frase más importante: el agente que comprueba un hallazgo nunca es el agente que lo encontró.

No es una instrucción de prompt, es una restricción de orquestación, y es la única forma en que este tipo de herramienta produce algo fiable. Un LLM al que se le pregunta si su propio hallazgo es correcto estará de acuerdo consigo mismo. Dale un contexto nuevo, otra instancia de agente y la tarea explícita de refutar la afirmación, y obtienes algo más parecido a una revisión de código.

La fase cinco lo extiende: agentes nuevos verifican las afirmaciones finales sobre el código y, si una afirmación se sustituye de forma material, otro verificador independiente revisa la sustitución. Hay dos niveles de separación entre el cazador y el registro que sobrevive.

El número honesto

Enterrado en los principios de diseño hay esto: en las pruebas de Cloudflare, una sola ejecución encontró aproximadamente la mitad de las vulnerabilidades que encontraron en total las ejecuciones repetidas.

Publicarlo es una decisión. Te dice que la herramienta es una máquina de cobertura, no un oráculo, y reencuadra el flujo de trabajo: no se ejecuta una vez antes de un lanzamiento, se ejecuta repetidamente y se deja que los registros se acumulen. El repositorio lo admite explícitamente: varias ejecuciones sobre el mismo repositorio son aditivas, usan registros y hallazgos previos para apuntar a los huecos, revalidan el código modificado y arrastran la evidencia del código actual sin tratar el trabajo obsoleto como cubierto.

La mitad también es una estimación razonable para auditores humanos en una primera pasada, lo que resulta tranquilizador o demoledor según cómo se mire la profesión.

El requisito que detendrá a la mayoría

El README enumera un requisito duro que casi todos los usuarios pasarán por alto y con el que acabarán chocando: un sandbox impuesto por el sistema operativo para compilaciones, pruebas, procesos, navegadores, emuladores, fuzzers y fixtures, con la red externa desactivada, un entorno saneado y con lista blanca, límites de recursos aplicados y escrituras restringidas a rutas temporales.

Sin esos controles, el flujo de trabajo mantiene la pista en needs_validation en vez de ejecutar el código objetivo. Es la decisión correcta —al fin y al cabo estás lanzando las sugerencias de un modelo de lenguaje contra una base de código—, pero significa que la herramienta se degrada a un ejercicio de análisis estático y razonamiento para quien no tenga infraestructura de contenedores.

También significa que no es una herramienta de portátil, pese a la línea de instalación con npx. La instalación es un solo comando:

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

Y el uso consiste en pedirlo:

security audit this codebase

El contraste es extraño: la invocación es una frase, los requisitos previos son una política de sandbox. En esa brecha se irá la mayor parte del esfuerzo de despliegue.

Cómo es la salida en realidad

Tres artefactos, derivados y no escritos: REPORT.md, FINDINGS-DETAIL.md y NEEDS-VALIDATION.md, más el findings.json subyacente y el registro de cobertura.

Esa separación es más útil de lo que suena. Un único informe de vulnerabilidades obliga a meter cada hallazgo en el mismo registro, y así acabas con una inyección SQL crítica junto a una cabecera CSP ausente. Separar los hallazgos confirmados, las preguntas abiertas y los resúmenes derivados hace que quien lee NEEDS-VALIDATION.md sepa que está viendo trabajo, no resultados.

El directorio de salida por defecto es ~/security-audit-skill/<repo-name>/run-<N>, y el flujo de trabajo solo escribe dentro del repositorio objetivo si lo apuntas explícitamente a un directorio ignorado por git. Detalle pequeño, instinto correcto: los artefactos de auditoría en un repositorio acaban confirmados por accidente, y una lista confirmada de vulnerabilidades sin parchear es un incidente en sí misma.

Cómo saber si funcionó

Ejecútalo dos veces. Es la prueba que el README sugiere sin enunciarla: como las ejecuciones son aditivas y una sola encuentra más o menos la mitad, la segunda ejecución sobre el mismo commit es una medición directa de la cobertura de la herramienta en tu código. Si la segunda no saca nada nuevo, o estás limpio o las clases de caza no encajan con tu stack.

Luego mira el registro de rechazos. Una ejecución que confirma cinco problemas y rechaza cuarenta candidatos está haciendo su trabajo. Una que confirma cuarenta y no rechaza ninguno ha dejado de verificar, y deberías leer esos cuarenta a mano antes de creerte uno solo.

Qué dice de la categoría

Tres cosas, brevemente.

Las skills de agentes se están convirtiendo en una forma de distribución. No es una biblioteca que importas, es una carpeta de markdown y dos scripts de validación que un modelo lee en tiempo de ejecución. El repositorio son una veintena de archivos de instrucciones más catálogos de clases de ataque separados por tipo de objetivo: seguridad de memoria y binarios, superficies de LLM y agentes, protocolo web y autenticación, lado cliente, cadena de suministro, nube y despliegue, RPC y mensajería, agotamiento de recursos, aislamiento de datos, escritorio e IPC local. Esa estructura es el producto.

La verificación se está convirtiendo en el diferenciador. Cualquier proveedor ya puede generar un hallazgo plausible. Casi ninguno puede decirte cuáles sobrevivieron a una pasada adversarial, escritos contra un esquema y con los refutados conservados.

Y la costumbre del número honesto se extiende. Un proveedor que publica «encontramos la mitad» es un proveedor cuya siguiente afirmación resulta más creíble.

El repositorio tiene licencia MIT, lo que significa que la pregunta interesante no es si funciona, sino si tu equipo puede permitirse el sandbox que necesita para funcionar bien.