Cloudflare y OpenAI combinan modelos Daybreak con datos de tráfico real para priorizar y parchear vulnerabilidades

Cloudflare ha anunciado el acceso anticipado, solo por invitación, a "Vulnerability Discovery and Remediation" (VDR), un nuevo servicio integrado en Cloudflare Managed Defense que combina modelos de OpenAI con la visibilidad de red de Cloudflare para detectar y proponer arreglos de vulnerabilidades en el código que el cliente autorice a inspeccionar. El sistema se apoya en los modelos OpenAI Daybreak, incluido GPT-5.6 Cyber, a través de lo que la compañía llama la OpenAI Daybreak Defense Network, y los usa en tareas de reconocimiento, búsqueda ("hunting") y validación de hallazgos.

El problema de partida que plantea Cloudflare es conocido por cualquier equipo de seguridad: un escáner puede señalar miles de vulnerabilidades de golpe (el propio artículo pone como ejemplo un escenario de 4.000 hallazgos nuevos, 78 de ellos críticos) sin indicar cuáles importan de verdad. Los modelos de lenguaje han acelerado la capacidad de encontrar debilidades en una base de código en cuestión de minutos, lo que dispara el volumen de alertas, pero no resuelve el problema real: decidir qué arreglar primero con evidencia, y hacerlo rápido, porque los atacantes también usan IA para acelerar el descubrimiento y la explotación de fallos. Un hallazgo aislado de un escáner no dice si ese código está desplegado en producción, si alguien realmente está accediendo a esa ruta, qué actividad de seguridad la rodea o qué protecciones ya existen.

Aquí es donde Cloudflare dice aportar valor diferencial: al operar una red global, puede ver qué rutas están activas, cuánto tráfico reciben y qué eventos de seguridad se han registrado a su alrededor. Si el cliente además tiene activado el Web Application Firewall (WAF), Cloudflare también sabe qué reglas ya están aplicadas y bloqueando ataques en ese momento. Esa capa de contexto convierte un hallazgo genérico ("hay una vulnerabilidad en este handler") en una prioridad concreta y accionable: por ejemplo, una vulnerabilidad en código que está en producción, en una ruta con mucho tráfico, con actividad de ataque reciente y sin protección existente. A partir de ahí, el sistema puede proponer tanto mitigaciones personalizadas en el WAF como parches de código adaptados a los sistemas del cliente.

El artículo explica que esta capacidad se apoya en un trabajo previo de la propia Cloudflare, descrito en un post anterior titulado "Build your own vulnerability harness", donde detallaban un pipeline agnóstico de modelo que usan internamente para escanear su propia infraestructura, validar cada hallazgo de forma adversarial y convertir la salida cruda de los modelos en arreglos en los que los ingenieros puedan confiar. Ese sistema interno de detección es uno de los pilares de VDR; el nuevo servicio lleva ese mismo proceso de descubrimiento al código que el cliente autoriza a inspeccionar, y lo conecta con el tráfico de producción, los eventos de seguridad y los controles de red (edge) capaces de actuar sobre esos hallazgos.

En cuanto al funcionamiento técnico, el proceso arranca con una instantánea de tráfico y seguridad tomada de Web Assets y del WAF, que muestra qué rutas están activas, cuánto tráfico reciben y si hay eventos de seguridad recientes asociados; estos dos componentes (Web Assets y WAF) actúan como el primer y segundo pilar del servicio. Las rutas con mucho volumen de peticiones se tratan como "hot paths" o rutas calientes, y el código desplegado en ellas recibe un perfilado de seguridad más estricto. A continuación entra en juego el análisis de vulnerabilidades sobre el código fuente. Para Workers, el sistema recupera la versión más reciente del código y sus rutas configuradas, y cruza esa información con Web Assets y con los metadatos de peticiones de Workers Observability, de modo que el código bajo revisión queda ligado exactamente a los endpoints que sirve en producción.

El propio "harness" (arnés o andamiaje de vulnerabilidades) se pone en marcha con un agente de reconocimiento que mapea las rutas de petición a las partes del código que las gestionan. Ese mapa se usa para enviar agentes "hunter" (cazadores) a secciones concretas del código autorizado por el cliente, donde buscan vulnerabilidades apoyándose en el contexto de red recopilado; ese contexto ayuda a que los agentes presten más atención al código que está detrás de una ruta activa o recientemente atacada, pero en ningún caso sustituye la necesidad de que cada hallazgo esté respaldado por evidencia en el propio código fuente. Después, una fase de validación revisa las mitigaciones propuestas y asigna a cada vulnerabilidad una calificación de riesgo inicial basada en el código; esa calificación puede subir si la evidencia de red muestra, por ejemplo, que el endpoint afectado tiene mucho tráfico o signos de sondeo activo por parte de atacantes.

El resultado final es una lista priorizada de hallazgos, cada uno con un parche de código recomendado y, cuando la evidencia lo respalda, una regla personalizada de WAF que puede reducir la exposición mientras se revisa el arreglo de fondo. Si el cliente ha autorizado a VDR a defender su zona, Cloudflare despliega esas reglas de forma conservadora, acotadas al método, la ruta y otros detalles de la petición necesarios para alcanzar el código vulnerable; de hecho, el artículo subraya que si un patrón de ruta contiene solo variables y comodines, el sistema no llega a sugerir ninguna regla, prefiriendo pasar por alto una posible conexión antes que afirmar una que la evidencia no sostiene. Como ejemplo concreto, el post muestra un caso de bypass de anulación de método HTTP ("HTTP method override bypass"), donde el sistema mapea el hallazgo de código a la ruta de producción, usa la actividad de tráfico y seguridad para priorizarlo y acota una regla de WAF en torno a las peticiones que pueden alcanzar el código vulnerable.

Un apartado importante del artículo se dedica a explicar dónde se ejecuta realmente el modelo y qué salvaguardas existen. Cuando se autoriza una investigación, el harness corre en la infraestructura de Cloudflare, y los prompts se envían desde Workers, a través de Cloudflare AI Gateway, hacia los modelos OpenAI Daybreak alojados en los servidores de OpenAI; GPT-5.6 Cyber se usa durante el reconocimiento, la caza y la validación, y sus respuestas vuelven al harness para que el flujo de trabajo continúe en Cloudflare. Es decir, no hay inferencia de modelo en el edge de Cloudflare, y el modelo no tiene capacidad de aplicar por sí mismo ningún parche o regla que proponga. Cada investigación se mantiene acotada al código y la evidencia que el cliente autoriza, y antes de que ese contexto llegue al modelo se eliminan los datos que la investigación no necesita y se aplican los controles de redacción configurados para cada compromiso.

Otro detalle relevante desde el punto de vista de seguridad del propio sistema: el harness trata el código fuente, los logs y los metadatos de peticiones como evidencia a inspeccionar, nunca como instrucciones a seguir, una precaución que apunta directamente a mitigar ataques de inyección de prompts a través de contenido malicioso incrustado en el código o el tráfico analizado. El acceso a herramientas sigue el mismo principio de contención: cada llamada queda registrada y se comprueba contra la política de acceso de la investigación antes de ejecutarse, y cada propuesta de parche o regla debe superar comprobaciones implementadas fuera del modelo. Si alguna de esas comprobaciones falla, el flujo se detiene antes de que la propuesta llegue a la revisión del cliente. En el caso de las sugerencias de defensa en el edge, esto implica validar la sintaxis de la regla y probarla contra fixtures sintéticos que representan las peticiones esperadas, no contra tráfico real de clientes; si una comprobación falla o el resultado resulta ambiguo, la salida se retiene y se redirige para diagnóstico. Superar esas comprobaciones tampoco cambia nada por sí solo en el entorno del cliente: solo después de que el equipo de Cloudflare valida la salida se prepara el parche de código y la regla de WAF para su revisión.

En todo el proceso, Cloudflare insiste en que el cliente mantiene el control: aunque el sistema puede proponer parches de código y otras mitigaciones, es el cliente quien decide si se implementan. Cada compromiso de acceso anticipado empieza con una sola aplicación cuyo código el cliente autoriza a investigar, y para conectar los hallazgos con producción, VDR usa acceso de solo lectura autorizado al inventario de operaciones de Web Assets, los controles relevantes del WAF y, cuando está disponible, el Logpush de eventos de traza de Workers. El proceso se describe como semiautomatizado: el cliente revisa cada resultado antes de decidir si lo prueba o lo despliega.

Por ahora, el servicio está disponible solo para clientes seleccionados durante la fase de acceso anticipado, a través del equipo de Managed Defense de Cloudflare, y quienes estén interesados deben contactar con su equipo de cuenta en Cloudflare. El anuncio se enmarca en una tendencia más amplia en la industria de la ciberseguridad: usar modelos de IA no solo para generar código o detectar patrones superficiales, sino para razonar sobre bases de código completas combinando evidencia de múltiples fuentes (tráfico real, reglas de firewall existentes, telemetría de eventos) y así reducir el ruido de los hallazgos automáticos, priorizando lo que de verdad representa riesgo en producción, todo ello manteniendo al humano como responsable final de decidir qué se despliega.