El skill de auditoría de seguridad de Cloudflare se dispara en GitHub

Cloudflare tiene en GitHub un repositorio, security-audit-skill, que en la última semana ha sumado unas 15.400 estrellas, según el recuento de un desarrollador que lo ha desmenuzado. El proyecto no es nuevo: está publicado desde junio. Lo que ha cambiado es el interés. Lo que hace es convertir un agente de código como Claude Code o Codex en un auditor de seguridad que trabaja por fases y se lanza con un prompt de una línea, después de instalarlo con npx.

La cifra de estrellas es de quien lo ha analizado, no de Cloudflare.

Cómo está montado

Reconocimiento. El agente mapea la arquitectura del objetivo, los límites de confianza y las superficies de entrada, y deja dos artefactos en disco: architecture.md y coverage-ledger.json. Ese ledger es la referencia de lo que se ha explorado y de lo que no.

Caza por cobertura. A partir de esas unidades reparte agentes "hunter" aislados, cada uno con su trozo de código. Cada cual registra lo que comprueba, y unos "coverage critics" buscan los huecos que dejan. No es fuzzing a ciegas: la exploración va dirigida por lo que falta.

Validación de candidatos. Cada hallazgo potencial pasa a un verificador independiente y recién creado cuyo trabajo no es confirmarlo, sino intentar refutarlo. Es la pieza que más falsos positivos evita, porque solo avanza lo que sobrevive al intento de derribo.

Salida estructurada. Los resultados van a findings.json separados en confirmados, needs_validation y rechazados, y se validan contra un report-schema.json. Un needs_validation señala un hecho sin resolver que necesita ojo humano, sin asignarle una severidad antes de tiempo. Ese JSON es lo que permite engancharlo a un dashboard o a un pipeline de CI.

Verificación de registros. Agentes nuevos vuelven sobre las afirmaciones finales. Si durante esa revisión se sustituye material, se despacha otro verificador encima.

El material consultado detalla cinco fases; del sexto paso del proceso no hay descripción.

Lo que no dice

No hay datos de licencia, versión ni de compatibilidad con otros agentes que los citados. Tampoco hay una tasa de falsos positivos medida ni resultados de auditorías sobre un código concreto contra el que comparar. El repositorio envejecerá o no según eso, no según las estrellas de una semana.

Merece la pena probarlo, eso sí. El patrón que propone (fases separadas, un verificador que intenta refutar en lugar de confirmar, salida en JSON con esquema) se puede replicar a mano en cualquier equipo sin depender de este skill en concreto. Si el proyecto mantiene el ritmo, lo razonable es meterlo primero sobre un módulo acotado y ver qué encuentra y qué se inventa antes de darle acceso al repositorio entero.