La ventana para aplicar parches se ha cerrado. Así es como F5 está preparado para lo que viene.

Kunal AnandDirector de Producto | F5

Hay una línea de código en FFmpeg que los fuzzers automatizados han ejecutado aproximadamente cinco millones de veces. En esa línea había un error de hacía 16 años que había pasado inadvertido. Nada lo detectó. Entonces, Anthropic aplicó su nuevo modelo Claude Mythos Preview al código fuente, y el modelo leyó el código, razonó sobre lo que intentaba hacer y encontró el fallo. También descubrió miles de vulnerabilidades hasta entonces desconocidas en todos los principales sistemas operativos y navegadores. Una de ellas llevaba 27 años en OpenBSD. OpenAI y otras empresas están desarrollando capacidades equivalentes.

Este no es un momento protagonizado por un único proveedor.

Es el momento en que cambiaron las reglas de la seguridad del software.

Las matemáticas que importan

El Reloj de Día Cero de Sergej Epp, basado en 3515 pares de CVE y exploits procedentes de CISA KEV, VulnCheck KEV y XDB, resume la situación en cuatro cifras:

1. En 2018, la mediana de tiempo transcurrido entre la divulgación de una vulnerabilidad y la primera explotación observada fue de 771 días. Las organizaciones disponían de más de dos años para aplicar parches.
2. En 2023, ese plazo se había reducido a 6 días.
3. En 2024, era de 4 horas.
4. En 2025, muchas vulnerabilidades explotadas se utilizaron como arma antes de que se divulgaran públicamente.

Mientras tanto, una organización media sigue tardando 20 días en probar e implementar un parche. La mayoría solo puede corregir alrededor del 10 % de las nuevas vulnerabilidades al mes. No se puede cerrar esa brecha aplicando parches más rápido. Ni trimestralmente. Ni mensualmente. Ni siquiera, siendo realistas, semanalmente.

Las cuentas no salen.

Por qué la IA inclina la balanza a favor del ataque

Hay una razón más profunda por la que la IA acelera el ataque más rápido que la defensa, y todo responsable de seguridad debería comprenderla.

El ataque cuenta con el verificador más barato de la ciberseguridad. ¿Ha funcionado el exploit? La respuesta es binaria e inmediata: o has conseguido una shell o no. El aprendizaje automático se potencia con ese tipo de señal.

La defensa tiene el problema opuesto. ¿Es real esta alerta? ¿Es seguro este sistema? La respuesta es ambigua, lenta y costosa. Señal ruidosa, bucle roto. La IA funciona mejor en el bando que cuenta con un verificador fiable, por eso la explotación asistida por IA se ha industrializado más rápido que la defensa asistida por IA.

Esta es la realidad estructural que subyace a las cifras de Mythos. Anthropic no construyó un arma. Simplemente, un modelo de frontera de propósito general llegó a ser lo bastante bueno leyendo código como para inclinar aún más la asimetría de la verificación a favor de los atacantes.

Todos los laboratorios que desarrollan modelos de frontera cruzarán este umbral y, teniendo en cuenta el punto en el que se encuentran actualmente las curvas de capacidad, mi previsión —es una conjetura, pero también la hipótesis de planificación con la que trabajo— es que en un plazo de 12 meses existirán modelos de código abierto con capacidades de razonamiento sobre código equiparables a las de Mythos: modelos que cualquier persona con una GPU podrá ejecutar localmente y sin supervisión.

Qué tiene que cambiar

Ese es el calendario en torno al cual deberían organizarse todos los proveedores de software y todos los equipos de seguridad empresarial. Entonces, ¿qué tiene que cambiar?

Cómo probamos el código: El análisis estático y las pruebas de penetración periódicas se concibieron para un mundo en el que descubrir vulnerabilidades era un proceso lento y costoso. Ese mundo ya no existe. Las pruebas deben ser continuas, estar impulsadas por IA y basarse en el razonamiento. Los modelos deben rastrear rutas de ejecución, encadenar flujos y encontrar la cadena de explotación, no solo el fallo aislado. La detección de patrones es el requisito mínimo. El razonamiento es el listón que hay que alcanzar.

La forma en que desarrollamos código: La seguridad no puede seguir siendo un control al final del proceso. Debe integrarse en el propio acto de escribir código, con herramientas asistidas por IA que detecten las estructuras de riesgo antes de que se incorporen al repositorio.

La forma en que distribuimos el código: Los plazos de divulgación, la frecuencia de las actualizaciones y las prácticas de gestión de flotas se diseñaron para un ritmo más lento. Todo proveedor de software debe preguntarse con franqueza si sus procesos actuales pueden sobrevivir en un mundo en el que el exploit precede al aviso de seguridad.

Eso se aplica al código que aún no hemos lanzado. La otra cuestión, igual de difícil, es qué hacemos con el código que ya está en producción. Aquí es donde se produce el verdadero cambio. Y también donde F5 está preparada para liderar.

El entorno de ejecución es la respuesta

Cuando se cierra la ventana de aplicación de parches, la ruta del tráfico permanece. No se trata de una solución alternativa. En el nuevo planteamiento, es el control principal.

La protección en tiempo de ejecución invierte la asimetría de la verificación. En lugar de preguntarse si existe un fallo hipotético en algún punto del código base, el entorno de ejecución observa lo que hace una aplicación e interviene cuando su comportamiento se desvía de lo previsto. La señal es concreta. La respuesta es clara. Un atacante puede encontrar mil vulnerabilidades de día cero en el código, pero si el exploit no puede atravesar la ruta de datos, el fallo no se convierte en una brecha de seguridad.

F5 lleva 30 años presente en la ruta de datos. F5 BIG-IP, F5 NGINX y F5 Distributed Cloud Services —la F5 Application Delivery and Security Platform— se crearon precisamente para esta capa. La decisión arquitectónica que tomamos —defender la aplicación allí por donde fluye el tráfico— es la que más importa en una era en la que el código no puede parchearse con la suficiente rapidez. Todo lo que estamos haciendo ahora en materia de gestión del tráfico de IA y seguridad en tiempo de ejecución extiende esa misma decisión a las cargas de trabajo que los clientes están creando hoy.

Qué estamos haciendo con nuestro propio código

También estamos trabajando en el otro lado de la ecuación. Como parte de nuestra práctica operativa, ejecutamos modelos de IA de vanguardia sobre nuestro propio código base.

Los modelos leen directamente el código fuente, rastrean flujos de riesgo entre módulos y lenguajes y analizan detalles reales de la implementación. Una segunda fase de verificación separa las señales relevantes del ruido. Los hallazgos se clasifican mediante correspondencias con CWE, niveles de gravedad, referencias a archivos y líneas, y contexto sobre su explotabilidad, y se incorporan directamente a un proceso de corrección priorizado.

El objetivo no es encontrar fallos aislados, sino descubrir cadenas de explotación, priorizar lo importante y convertir los hallazgos en código reforzado. Cada ciclo amplía una base de conocimientos que hace que el siguiente sea más rápido y preciso. A medida que los modelos de vanguardia mejoran, también lo hace el uso que hacemos de ellos. Nuestro código siempre se someterá a pruebas con las mejores herramientas y modelos disponibles, porque eso es precisamente lo que utilizarán los adversarios.

El coste y quién lo paga

Quiero explicar con claridad qué significa esto para los clientes.

Que se divulguen más vulnerabilidades no es señal de que el software sea menos seguro, sino de que los procesos son más sólidos. Cada fallo que encontramos y corregimos antes de que lo haga un atacante supone una exposición menos en producción. Pero cada corrección también implica un parche que alguien debe implementar. Quienes utilizan BIG-IP en producción recibirán más parches, y los ciclos de actualización que antes eran trimestrales ya no pueden seguir siéndolo. Estamos invirtiendo en F5 Insight y en la gestión de flotas para agilizar todo el ciclo: nosotros detectamos el fallo, lo corregimos y lo validamos, y usted implementa la solución. Y cuando la implementación requiere tiempo, la ruta del tráfico mantiene protegida la aplicación mientras se actualiza el código.

Esa última cláusula condensa todo el argumento:

1. Encontrar vulnerabilidades más rápido de lo que los atacantes pueden explotarlas.
2. Corrige las vulnerabilidades antes de que los exploits puedan convertirse en armas.
3. Protege durante la ejecución mientras se actualiza el código.

Las tres disciplinas solo funcionan juntas. Ninguna de ellas funciona por sí sola.

La nueva normalidad

Así es como funcionará la seguridad del software de ahora en adelante. No se trata de una campaña ni de una reacción al lanzamiento de un único modelo. El plazo para aplicar parches se ha cerrado y no volverá a abrirse.

Algunas empresas lo verán como un momento que hay que capear. Solo prosperarán aquellas que lo acepten como la nueva normalidad y se adapten continuamente a ella, tanto en la capa de código como en la de tráfico.

F5 se está preparando para esta nueva normalidad. Nuestros clientes también. Juntos llevaremos a cabo esta importante labor.

Sobre el autor

Kunal AnandDirector de Producto | F5

Kunal Anand dirige la organización de productos de F5 como director de Producto. Es responsable de la visión, la estrategia y la ejecución de los productos, y garantiza el desarrollo de soluciones innovadoras que resuelven retos críticos y ofrecen experiencias excepcionales a los clientes. En su anterior cargo como director de Tecnología e IA, Kunal definió la estrategia y la visión tecnológica y de inteligencia artificial de la empresa. Antes de incorporarse a F5, Kunal desempeñó simultáneamente los cargos de director de Tecnología y director de Seguridad de la Información en Imperva. Su trayectoria en Imperva comenzó en 2018 con la adquisición de Prevoty, una startup de seguridad de aplicaciones que cofundó en 2013. Antes de incorporarse a Prevoty, fue director de Tecnología en BBC Worldwide. Kunal cuenta con una amplia trayectoria en innovación y conocimientos técnicos, y ha ocupado puestos de liderazgo al frente de equipos de seguridad, datos, tecnología e ingeniería en Gravity, MySpace y el Laboratorio de Propulsión a Chorro de la NASA. Kunal cuenta con más de 15 años de experiencia en inteligencia artificial y aprendizaje automático, que abarca desde el entrenamiento de modelos y el uso de algoritmos basados en IA para mejorar productos hasta el diseño y la implementación de arquitecturas de IA. Kunal es graduado en Ciencias de la Computación por Babson College.

Más artículos de Kunal Anand