Cloudflare vincula fallos hallados por IA al tráfico real. Hallar un fallo y saber si importa no es lo mismo

La IA ha abaratado el descubrimiento de vulnerabilidades. La emergencia de PHP de esta semana mostró una consecuencia: modelos de frontera encontraron fallos críticos en código auditado durante años. La consecuencia más silenciosa es el atasco. Cada escáner, cada agente de código y cada modelo de seguridad produce ahora más hallazgos de los que cualquier equipo puede leer, y la pregunta que decide el riesgo ya no es “¿es esto un fallo?”, sino “¿importa este fallo aquí, hoy?”.

La respuesta de Cloudflare, descrita en un caso de cliente que OpenAI publicó el 21 de octubre, es dejar de juzgar los hallazgos solo por el código.

Evidencia del código más evidencia de producción

Cloudflare, que según sus propios datos intermedia aproximadamente una quinta parte del tráfico web, ofrece en acceso anticipado un servicio de descubrimiento y corrección de vulnerabilidades construido con los modelos Daybreak de OpenAI. El enfoque conecta una vulnerabilidad del código fuente con lo que ocurre en producción mediante tres preguntas:

• ¿Está activa la ruta afectada? Un fallo en un endpoint al que nadie llama tiene otra prioridad que uno en el flujo de inicio de sesión.
• ¿Recibe tráfico sospechoso? Los intentos de explotación en peticiones reales convierten un hallazgo teórico en un incidente en curso.
• ¿Lo protegen ya los controles existentes? Un hallazgo detrás de una regla de firewall que funciona es menos urgente que uno sin nada delante.

A partir de esas señales, el servicio ofrece a los clientes evidencias para priorizar, protecciones perimetrales propuestas, como reglas de firewall de aplicaciones web, y correcciones de código propuestas. En palabras de OpenAI, los clientes “conservan el control sobre qué cambios aplicar”. Nada en la descripción muestra al sistema parcheando por su cuenta las aplicaciones de los clientes.

Por qué la exposición es el dato que faltaba

La mayoría de los programas de vulnerabilidades ordena los hallazgos según puntuaciones de gravedad calculadas a partir del propio fallo. Ese orden ignora los hechos que deciden el riesgo real: si el código vulnerable está desplegado, si es alcanzable y si está siendo atacado. Los equipos de seguridad cubren ese hueco a mano, justo el trabajo que no escala cuando la IA multiplica los hallazgos.

Es el mismo patrón que vimos en Block, donde los agentes de seguridad conservan la evidencia en bruto de cada investigación, y en la decisión de GitHub de medir si los desarrolladores corrigen los hallazgos, no cuántos se encuentran. El modelo es útil en los tres casos. Lo que lo hace fiable es la evidencia de la que está obligado a partir: registros de tráfico, estado del firewall, registros de despliegue. Son hechos que el modelo no generó y que no puede rebatir con argumentos.

También encaja con lo que hemos defendido sobre la capacidad de verificación como nuevo cuello de botella. Cuando generar es barato, el recurso escaso es decidir qué merece la atención de una persona. La evidencia de producción es un verificador barato para esa decisión.

Las cifras de productividad, leídas con cuidado

El mismo texto señala que todos los desarrolladores de Cloudflare, alrededor de un tercio de la empresa, usan Codex, y que un equipo de cuatro personas reconstruyó en tres días un producto aplazado con 1.100 dólares en tokens. Mark Anderson, presidente de ingresos de Cloudflare, calcula que de otro modo habría llevado meses y “quizá 10 veces más desarrolladores”.

Son cifras aportadas por el cliente sobre un único proyecto, y los 1.100 dólares cubren tokens, no el tiempo de los ingenieros, la revisión ni las pruebas. Son una señal útil de que los equipos capaces publican ya mucho más código. Leídas junto a la parte de seguridad de la historia, explican además por qué priorizar por exposición se ha vuelto urgente: más código, escrito más rápido, significa más hallazgos, más rápido.

Qué copiar

1. Cruce los hallazgos con datos de ejecución antes de ordenarlos. La actividad de las rutas, las señales de tráfico y la cobertura de controles forman parte de la priorización, no de un panel aparte.
2. Separe dos resultados: la mitigación y la corrección. Una regla de firewall gana tiempo; un cambio de código elimina el fallo. Ambos necesitan aprobación, y tienen responsables distintos.
3. Exija evidencia en cada acción propuesta, enlazada a los registros de los que procede, para que quien revisa pueda comprobar en lugar de confiar.
4. Mida el tiempo hasta la decisión, no solo el tiempo hasta el parche. Si los hallazgos esperan días a que alguien juzgue su relevancia, ese es el cuello de botella que hay que resolver.

OpenAI también publicó ese mismo día una propuesta de política que llama a este periodo “la ventana del defensor” y pide mejores notificaciones de incidentes y evaluaciones independientes. Es una propuesta, no una ley. La versión operativa de la misma idea es más sencilla: los defensores aprovechan la ventana cuando sus hallazgos llegan con la evidencia necesaria para actuar.