Canonical va a cambiar el ciclo de publicación de actualizaciones del kernel de Ubuntu para responder al aumento de vulnerabilidades identificadas en el núcleo de Linux. La compañía ha anunciado que unificará sus ciclos actuales de cuatro semanas para actualizaciones ordinarias y dos semanas para correcciones de seguridad en un ciclo SRU de dos semanas, con publicaciones de nuevos kernels cada semana gracias al solapamiento de varios ciclos.
Las claves de las actualizaciones del kernel de Ubuntu en 20 segundos
- Canonical unifica los ciclos del kernel en periodos de dos semanas.
- Los ciclos se solapan, por lo que habrá una nueva publicación de kernel cada semana.
- La primera semana se dedica a preparar paquetes y realizar comprobaciones iniciales.
- La segunda concentra certificación, integración y pruebas de regresión.
- Las versiones en
-proposedpermiten empezar antes las pruebas, mientras Canonical plantea mitigaciones en 24-48 horas cuando sea posible.
El cambio responde, según Canonical, al aumento del volumen de vulnerabilidades registradas en el kernel de Linux. La compañía atribuye parte de este crecimiento a la utilización de modelos de lenguaje de gran tamaño (LLM) y agentes de inteligencia artificial para automatizar la búsqueda de errores. También señala otro factor: la comunidad del kernel pasó a actuar como autoridad de numeración de CVE (CNA), asignando identificadores a miles de fallos que anteriormente podían clasificarse simplemente como errores de software.
La consecuencia para Canonical es un volumen mayor de vulnerabilidades que deben analizarse, corregirse, probarse y distribuirse. En lugar de responder reduciendo las comprobaciones previas a cada lanzamiento, la compañía ha decidido mantener su proceso de validación y solapar los ciclos de desarrollo.
Ubuntu tendrá una nueva publicación del kernel cada semana
El nuevo sistema no significa que cada kernel vaya a pasar de desarrollarse durante cuatro semanas a publicarse sin apenas pruebas. Canonical mantiene un ciclo individual de dos semanas, dividido en distintas etapas.
Durante la primera semana se realiza la preparación del kernel. El equipo selecciona las actualizaciones y parches que deben incorporarse, construye los paquetes y ejecuta comprobaciones iniciales para confirmar que el kernel arranca y funciona sin problemas evidentes. Al terminar esta fase, las versiones pasan al repositorio -proposed.
La segunda semana se dedica a las pruebas más extensas. Canonical incluye aquí la certificación de Ubuntu, la integración con la distribución y las pruebas de regresión. La compañía utiliza su programa Ubuntu Certified para comprobar los kernels sobre distintos tipos de hardware antes de su publicación general.
La clave está en que los ciclos no empiezan y terminan de forma aislada. El siguiente ciclo arranca cuando el anterior todavía está en marcha. Así, mientras un kernel se encuentra en la fase de certificación, otro ya está entrando en preparación.
El resultado práctico será una publicación de kernel cada semana, aunque cada versión individual haya pasado por un ciclo de dos semanas. Es una diferencia importante respecto a interpretar el anuncio como una simple reducción a la mitad del tiempo de pruebas.
Para administradores de servidores, centros de datos y otras instalaciones que mantienen Ubuntu durante largos periodos, el cambio busca reducir el tiempo entre la disponibilidad de una corrección y su distribución estable sin eliminar las comprobaciones que Canonical considera necesarias antes de recomendarla de forma general.
Canonical mantiene una vía más rápida para las vulnerabilidades
La compañía también reconoce que un ciclo de dos semanas puede resultar demasiado largo en determinadas situaciones. Por eso mantiene el repositorio -proposed, donde se publican candidatos a kernel antes de comenzar las pruebas de certificación.
Los administradores que necesiten reaccionar antes pueden utilizar esas versiones y realizar sus propias pruebas de aceptación. Canonical actualiza este repositorio semanalmente como consecuencia del solapamiento de los ciclos. La contrapartida es que quien utilice este camino renuncia a esperar la certificación completa de Canonical.
Esto permite distinguir entre dos necesidades diferentes. Una organización puede priorizar la estabilidad y esperar al final del proceso de certificación, mientras que otra puede considerar que la rapidez de una corrección tiene mayor importancia y asumir el trabajo adicional de validarla en su propia infraestructura.
El cambio también contempla situaciones en las que todavía no existe un parche listo. Canonical afirma que intentará proporcionar soluciones temporales seguras cuando sea posible, con el objetivo de que los sistemas puedan alcanzar un estado más defendible entre 24 y 48 horas después de la divulgación pública de una vulnerabilidad. Cuando no exista una mitigación segura, la compañía señala que lo comunicará y recomendará medidas generales de endurecimiento.
Canonical subraya que estas mitigaciones no sustituyen al parche definitivo. Su función es reducir la exposición durante el periodo necesario para preparar, probar y distribuir la corrección.
La IA acelera el descubrimiento y también presiona a los defensores
La relación con la inteligencia artificial es uno de los aspectos más interesantes del cambio. Canonical sostiene que los LLM y los agentes especializados han convertido la búsqueda de errores de código en un proceso mucho más automatizado. Eso puede aumentar la capacidad para encontrar vulnerabilidades, pero también incrementa el trabajo que deben realizar los equipos responsables de corregirlas.
La propia Canonical ha desarrollado herramientas basadas en IA para encontrar fallos en el kernel. La compañía explica que su herramienta Redhound ya ha descubierto tres vulnerabilidades críticas de lógica, un ejemplo de cómo la IA puede utilizarse para localizar problemas que no siempre aparecen mediante comprobaciones tradicionales.
El cambio de proceso de Ubuntu encaja así en una dinámica más amplia: si las herramientas automatizadas consiguen identificar más problemas y hacerlo con mayor rapidez, el sistema de mantenimiento tiene que procesar esas alertas sin convertir la velocidad en una fuente adicional de errores.
Por eso Canonical no ha optado simplemente por publicar cualquier corrección en cuanto está disponible. El nuevo modelo intenta mantener una fase de certificación extensa y, al mismo tiempo, ofrecer caminos diferentes para quienes necesiten una respuesta más rápida.
Para los usuarios de escritorio, el cambio puede traducirse en una mayor frecuencia de actualizaciones del kernel. En servidores y entornos empresariales, la diferencia será más relevante para quienes gestionan grandes cantidades de máquinas y necesitan equilibrar seguridad, estabilidad y ventanas de mantenimiento.
La decisión también muestra cómo la inteligencia artificial está modificando el ciclo completo de la seguridad del software. La IA no solo puede ayudar a encontrar vulnerabilidades: al aumentar la velocidad de descubrimiento, obliga a quienes mantienen sistemas operativos a revisar cómo clasifican, corrigen, prueban y distribuyen esas vulnerabilidades.
Canonical todavía mantiene el proceso de certificación como parte central de su estrategia. El nuevo ciclo de dos semanas, combinado con publicaciones semanales y mitigaciones temporales cuando sea posible, busca reducir el tiempo de exposición sin convertir las actualizaciones rápidas en lanzamientos sin validación suficiente.
Preguntas frecuentes
¿Cada cuánto tiempo publicará Canonical nuevas actualizaciones del kernel?
Con el nuevo sistema, los ciclos individuales tendrán una duración de dos semanas, pero estarán solapados. Por eso Canonical prevé publicar nuevas versiones del kernel cada semana.
¿Qué es el repositorio -proposed de Ubuntu?
Es el repositorio donde se publican candidatos a kernel antes de completar la certificación. Permite a organizaciones que necesitan actuar antes comenzar sus propias pruebas de aceptación.
¿Canonical corregirá vulnerabilidades críticas en 24 horas?
No necesariamente. Canonical afirma que intentará proporcionar mitigaciones seguras en un plazo de 24 a 48 horas cuando sea posible. Esas medidas son temporales y no sustituyen al parche definitivo.
¿Por qué la inteligencia artificial está aumentando la presión sobre las actualizaciones?
Según Canonical, los LLM y agentes especializados permiten automatizar y acelerar la búsqueda de errores, lo que contribuye al aumento del volumen de vulnerabilidades identificadas. La comunidad del kernel también ha ampliado la asignación de CVE a distintos tipos de fallos.
