Nota del editor (14 de octubre de 2026): F5 ahora denomina «versiones críticas» a las anteriormente conocidas como «versiones reforzadas». Este cambio terminológico refleja la relevancia de estas versiones y la importancia de implementar la versión más reciente lo antes posible.
En julio, escribí sobre nuestro cambio a versiones reforzadas mensuales y notificaciones de seguridad mensuales. En aquel momento dije que esa frecuencia era la adecuada para la situación en la que nos encontrábamos y que la misma disciplina que nos llevó a abandonar la periodicidad trimestral nos haría cambiar de nuevo cuando el panorama así lo exigiera.
Tras un ciclo de lanzamientos, hemos aprendido mucho. Hemos aprendido de los clientes, de los socios y de observar cómo funciona una cadencia mensual en los entornos de producción. Parte de lo aprendido nos está llevando a cambiar nuestro enfoque.
A partir de HR2, el 2 de septiembre, las versiones reforzadas se publicarán cada seis semanas en lugar de mensualmente. Además, vamos a pausar las notificaciones de seguridad periódicas que teníamos previsto publicar junto con ellas.
Quiero explicar cómo hemos llegado hasta aquí, porque el razonamiento es más importante que las fechas.
Lo que nos dijeron los clientes
Lanzamos HR1 el 15 de julio y después hicimos lo que dijimos que haríamos: escuchar.
Lo que escuchamos fue unánime y, en realidad, no tenía tanto que ver con F5. Las organizaciones que utilizan nuestros productos en sus procesos más críticos nos dijeron que una cadencia mensual no les daba suficiente margen para probar, preparar y desplegar, no necesariamente porque nuestras versiones fueran difíciles de asimilar por sí solas, sino porque llegaban al mismo tiempo que las de todos los demás. Todos los proveedores importantes están respondiendo al mismo cambio, y la carga acumulada recae sobre el mismo equipo, con recursos limitados, dentro de cada empresa.
Seis semanas suponen reconocer que una corrección que nadie puede implementar no es realmente una corrección. La velocidad a la que los clientes pueden asimilar un cambio forma ya parte de la propia ecuación de seguridad, y un ritmo que supera esa capacidad de asimilación genera exposición en lugar de reducirla.
“Las organizaciones sitúan F5 entre sus usuarios y sus aplicaciones, entre sus agentes y sus API. Esa posición explica por qué detectamos y corregimos problemas al ritmo al que lo hacemos, por qué realizamos las pruebas como lo hacemos y por qué tomamos la decisión que tomamos respecto a la divulgación.”
La otra conclusión que extrajimos apunta en la dirección opuesta. Los clientes que han invertido en la gestión y automatización de flotas están logrando mejoras significativas en la rapidez con la que pueden realizar las actualizaciones. Un cliente global con una gran flota de F5 BIG-IP redujo el tiempo de actualización de más de seis meses a aproximadamente dos semanas.
Por qué estamos pausando las notificaciones de seguridad
El segundo cambio es más difícil, y quiero explicar claramente los motivos.
Cuando anunciamos las notificaciones mensuales de seguridad, partíamos de la premisa de que un plazo de aproximadamente 30 días entre la versión reforzada y la divulgación daría a los clientes un margen razonable para actualizar antes de que los detalles se hicieran públicos. Esa premisa reflejaba lo que, en aquel momento, considerábamos más acertado.
Ya no es así. Las conversaciones mantenidas durante las últimas semanas con clientes y otros actores del sector nos han llevado a revisar nuestra valoración sobre cuánta información se necesita realmente para desarrollar un exploit funcional. Los modelos de vanguardia siguen mejorando su capacidad para inferir, a partir de indicios limitados —un diff, una descripción parcial, un intervalo de versiones—, una cadena de ataque operativa. El margen que creíamos estar dando a los defensores es también, en la práctica, un margen para los atacantes, y cada vez es menor.
Por tanto, vamos a suspender las notificaciones periódicas mientras determinamos conjuntamente cómo debe ser una divulgación responsable en este entorno. Habrá excepciones. Cuando una vulnerabilidad esté siendo explotada activamente, cuando nos coordinemos con investigadores u organismos gubernamentales, o cuando así lo exijan obligaciones normativas o contractuales, gestionaremos la divulgación de otra manera. Esta no es una postura permanente respecto a la transparencia. Es una decisión tomada bajo la premisa de que proteger a los clientes es lo primero, y seguiremos evaluándola.
Reconozco que esto resulta incómodo. También lo es para mí, como antiguo CISO. Las normas de divulgación existen por buenas razones, y la comunidad de la seguridad las ha desarrollado a lo largo de décadas de experiencias difíciles. Sin embargo, esas normas se concibieron para un mundo en el que el intervalo entre «detalles publicados» y «exploit disponible» se medía en semanas. Ese intervalo ha desaparecido, y todas las organizaciones que publican información sobre vulnerabilidades tendrán que afrontar lo que esto implica.
La cuestión más difícil: priorización sin gravedad
Esta es la cuestión que, en mi opinión, el sector aún no ha afrontado plenamente.
La mayoría de los programas de gestión de vulnerabilidades se basan en la gravedad. Las vulnerabilidades críticas se parchean en 24 horas; las de gravedad alta, en tres días; las de gravedad media, en un sprint; y las de gravedad baja, cuando hay tiempo. Este modelo presupone dos cosas: que las clasificaciones de gravedad permiten predecir el riesgo de forma significativa y que se dispone de dichas clasificaciones.
Ambas premisas están perdiendo validez.
La primera se está debilitando porque los atacantes que utilizan modelos de vanguardia no necesitan una vulnerabilidad crítica. Encadenan varias vulnerabilidades. Tres problemas de gravedad baja que, por separado, podrían quedar relegados al final de una cola de priorización se convierten en una vía efectiva para comprometer un sistema cuando un modelo puede razonar sobre los tres simultáneamente. Al analizar nuestro propio código, estamos encontrando este tipo de problemas: vulnerabilidades de menor gravedad que podrían encadenarse. Eliminarlas sistemáticamente es lo que refuerza la seguridad del software. Priorizarlas individualmente según su gravedad es lo que hace que permanezcan sin resolver.
El segundo supuesto se está debilitando porque los proveedores —nosotros incluidos— vamos a publicar menos detalles y lo haremos más tarde. Los equipos de seguridad van a sentir que pierden el control, y entiendo por qué.
Entonces, ¿qué se puede hacer en su lugar?
Priorice según la exposición, no según la puntuación. La accesibilidad, la exposición a Internet, el radio de impacto y la importancia para el negocio son criterios más sólidos que una puntuación CVSS que quizá no llegue a recibir. Un activo expuesto y sin parchear supone un riesgo, independientemente de lo que indique el aviso de seguridad.
Mantenerse al día como principio. Las organizaciones que prosperarán en este entorno serán aquellas que consideren «ejecutar la última versión reforzada» un compromiso operativo permanente, en lugar de una medida puntual motivada por una clasificación de gravedad. Se trata de un cambio tanto cultural como técnico, y para mantenerlo se necesita el respaldo de la dirección.
Invierta ahora en capacidad de adaptación. La automatización, la visibilidad de la flota, las ventanas de mantenimiento periódicas y los procedimientos de reversión probados son lo que permite asumir un ritmo más rápido. Estas inversiones pueden parecer opcionales ahora, pero dentro de un año dejarán de serlo.
Dé por hecho que habrá un intervalo de exposición y protéjalo. Ninguna organización aplica los parches al instante. La protección en tiempo de ejecución —detección basada en el comportamiento, aplicación de parches virtuales y controles que no dependen de conocer la vulnerabilidad concreta— puede ayudar a cubrir el intervalo entre la disponibilidad de una corrección y su implementación. Ese intervalo no va a desaparecer. Planifique teniendo en cuenta su existencia, en lugar de intentar evitarlo.
Sobre cambiar de opinión
En julio tomamos una decisión basándonos en la mejor información de la que disponíamos. La pusimos en práctica, aprendimos de nuestros clientes y socios e hicimos los ajustes necesarios. La alternativa —mantener nuestra postura simplemente porque la habíamos anunciado— habría sido peor para nuestros clientes y socios.
En julio dije que seguiríamos adaptándonos a medida que evolucionaran el panorama y vuestras necesidades. Así es como se materializa ese compromiso en la práctica. La postura honesta de cualquier proveedor en estos momentos es reconocer que las prácticas establecidas se están reevaluando en tiempo real en todo el sector, y que quien afirme tener esto completamente resuelto no está prestando atención.
Lo que no cambia es el nivel de exigencia que nos imponemos. Las organizaciones sitúan a F5 entre sus usuarios y sus aplicaciones, y entre sus agentes y sus API. Esa posición explica por qué detectamos y corregimos problemas al ritmo al que lo hacemos, por qué realizamos las pruebas como lo hacemos y por qué tomamos la decisión que tomamos sobre la divulgación de información. Gracias por los comentarios que han contribuido a dar forma a este enfoque. Seguid enviándonoslos y manteneos al día.
Sobre el autor
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 AnandArtículos relacionados del blog
El imperativo empresarial de la IA en un mundo de nube híbrida y multinube
Cómo la IA redefine los patrones de tráfico, el riesgo de las API y el cumplimiento normativo, y por qué el paquete Distributed Cloud Services Enterprise ofrece la profundidad necesaria en entornos híbridos multicloud.
STIG de F5 NGINX: un plan de seguridad para el sector público y los entornos regulados
Descubra cómo las STIG de F5 NGINX proporcionan un modelo de seguridad para el Departamento de Defensa de EE. UU. y los entornos regulados, ayudándole a cumplir la normativa mientras crea una infraestructura sólida de confianza cero con mayor visibilidad y resiliencia.
Cómo el marco AEGIS de Forrester valida un enfoque centrado en la inferencia
El auge de la IA agéntica está transformando el panorama de la seguridad empresarial. Estos agentes de IA autodirigidos funcionan de forma autónoma, toman decisiones en tiempo real y pueden interactuar entre distintos sistemas de maneras para las que las arquitecturas tradicionales de ciberseguridad no fueron diseñadas. Aunque esto abre nuevas posibilidades, también introduce riesgos sistémicos: fallos en cascada, secuestro de objetivos y superficies de ataque hasta ahora invisibles. El reciente […] de Forrester
La nueva superficie de riesgo de la IA: invisible, autónoma y ya está dentro
James White, vicepresidente de Ingeniería de F5 A mediados de 2025, es un buen momento para hacer balance de la adopción de la IA en las empresas y del estado de la seguridad de la IA. El uso de la IA generativa ya es habitual en las empresas En general, las empresas cuentan al menos con unos conocimientos básicos sobre la IA generativa. Entienden qué es y dónde puede […]
Protegiendo el futuro: cómo CalypsoAI se alinea con el Top 10 de OWASP para los LLM
Cuando OWASP publicó su Top 10 de 2025 para grandes modelos de lenguaje (LLM), proporcionó al sector un referente de seguridad muy necesario. Pero los referentes no sirven de nada si no se actúa. CalypsoAI aborda el 80 % del Top 10 de OWASP, dando prioridad a los riesgos reales más urgentes. La plataforma combina protección en tiempo real durante la ejecución y pruebas adversariales exhaustivas, ofreciendo una cobertura inigualable frente a las […]
Implementación de LLM en la empresa: mediante una API local
Por sí solos, sin medidas de protección ni protocolos adicionales de seguridad para la IA, el despliegue de modelos de IA generativa —en particular, modelos de lenguaje de gran tamaño (LLM)— en toda la empresa supone una oportunidad de alto riesgo y grandes beneficios para cualquier organización. Sin embargo, determinar exactamente cómo debe dar su organización este gran paso hacia el ámbito de la IA generativa requiere una planificación minuciosa. Quizá […]