Canonical passe les noyaux Ubuntu en publication hebdomadaire pour accélérer les correctifs CVE
Canonical remplace ses cycles de quatre et deux semaines par un cycle unique de deux semaines, en cascade, qui livre un noyau Ubuntu chaque semaine. Pour un parc Ubuntu, cela raccourcit le délai entre une CVE noyau et son correctif — à condition d’adapter ses fenêtres de maintenance.
23 septembre 2026. Canonical officialise un changement de cadence pour ses noyaux Ubuntu : les cycles de Stable Release Update (SRU) passent d’un mélange de quatre semaines (régulier) et deux semaines (sécurité) à un cycle unique de deux semaines, en cascade. 24 septembre 2026. Linuxiac détaille la mécanique : chaque cycle démarre une semaine après le précédent, si bien qu’un noyau sort, en pratique, chaque semaine. 2026. La cause est chiffrable : le volume de CVE noyau a explosé sous l’effet de la découverte automatisée par l’IA et du nouveau statut du projet Linux comme autorité de numérotation CVE. Pourquoi c’est important : pour la première fois, la cadence de publication suit la cadence de découverte des failles, et cela redéfinit le rythme de patch d’un parc Ubuntu.
Un cycle unique, deux semaines, publié chaque semaine
La nouveauté tient dans l’architecture du cycle, pas dans un abandon des tests. Canonical ne réduit pas la validation à sept jours : il superpose des cycles de deux semaines. Pendant qu’un noyau termine sa phase de certification, le suivant est déjà en préparation.
- Semaine 1 — préparation. Intégration des correctifs, sélection des patchs par noyau, builds et tests de fumée. À la fin de cette étape, les paquets sont publiés dans le dépôt -proposed.
- Semaine 2 — certification. Tests de certification, intégration à la distribution et tests de régression. À la fin de cette étape, le noyau est livré aux utilisateurs.
Le résultat est un rythme hebdomadaire sans raccourcir le cycle de validation complet. C’est un changement de pipeline, pas un changement de qualité.
Pourquoi maintenant : la mécanique de l’explosion des CVE
La raison du basculement n’est pas un choix éditorial, c’est une contrainte subie. Le cycle précédent — quatre semaines pour les mises à jour régulières, deux semaines pour la sécurité — était un compromis historique entre stabilité et réactivité : il supposait que les failles graves arrivaient à un rythme absorbable par un canal court dédié. L’explosion récente a rendu ce compromis intenable, et Canonical identifie deux moteurs.
- La découverte assistée par l’IA. Les grands modèles de langage et les agents spécialisés ont transformé la recherche de bugs, d’une activité manuelle et lente, en un moteur fortement automatisé.
- Le noyau devenu CNA. Le projet Linux est désormais sa propre CVE Numbering Authority et a attribué des identifiants CVE à des milliers de bugs, en partant du principe qu’au niveau du noyau presque tout bug pouvant affecter un système en cours d’exécution est potentiellement une vulnérabilité.
La conséquence est une montagne d’alertes et un arriéré qui force les défenseurs à accélérer la correction. Le graphique publié par Canonical montre une courbe de CVE quasi verticale — la cadence de quatre semaines n’absorbait plus le flux.
Le dépôt -proposed devient un canal d’acceptation anticipée
Le changement a une implication opérationnelle immédiate pour les équipes qui veulent corriger plus vite que le cycle officiel. Les paquets publiés dans -proposed le sont dès la fin de la première semaine, soit environ une semaine avant la certification complète.
C’est un levier à double tranchant. D’un côté, un administrateur peut commencer ses propres tests d’acceptation — sur son matériel, avec ses charges — une semaine avant la sortie stable, et réduire son exposition de sept jours. De l’autre, un noyau -proposed n’a pas terminé la certification Canonical : l’adopter revient à assumer une partie du risque de régression que l’éditeur n’a pas encore éliminé.
La recommandation implicite est claire : le canal -proposed est fait pour les environnements où la rapidité de remédiation pèse plus lourd que la garantie de certification complète — pas pour les parcs homogènes qui préfèrent la stabilité.
Un engagement à 24-48 heures, avant même le correctif
Le second volet de l’annonce concerne la fenêtre pendant laquelle aucun correctif n’est encore disponible. Canonical s’engage à fournir, quand c’est possible, des contournements sûrs dans les 24 à 48 heures suivant la divulgation publique d’une vulnérabilité. Quand aucun contournement n’existe, l’éditeur publiera à la place des recommandations de durcissement.
Cet engagement ne remplace pas le correctif : il achète le temps nécessaire pour le préparer proprement. C’est la réponse au problème classique du « trou dans la fenêtre » — la période entre la divulgation et la sortie du patch, pendant laquelle un système reste exposé. Pour un RSSI, c’est aussi un critère de pilotage : au-delà de 48 heures sans correctif ni contournement, le risque résiduel doit être traité par d’autres moyens, comme l’isolation réseau ou la désactivation d’une fonctionnalité.
Livepatch, redémarrages et le vrai coût du rythme hebdomadaire
Plus de correctifs ne signifie pas seulement plus de sécurité : cela signifie aussi plus de redémarrages. Chaque noyau corrigé doit, tôt ou tard, être chargé. Canonical propose Livepatch, qui applique les correctifs de sécurité à chaud sans redémarrer, pour les machines où une interruption est coûteuse. Mais Livepatch ne couvre que les failles de sécurité corrigeables à chaud — pas les régressions ni les changements de fonctionnalité.
L’arithmétique est simple. Un parc de 1 000 machines qui redémarre une fois par semaine, même en fenêtre de maintenance, multiplie les risques liés au redémarrage lui-même : services qui ne reviennent pas, dépendances d’ordre de démarrage, disques pleins. Le gain de sécurité du rythme hebdomadaire doit donc être mis en balance avec ce coût opérationnel, et la réponse n’est pas la même pour un serveur de production critique et pour une flotte de conteneurs éphémères.
Ce que ça change pour un parc Ubuntu
La traduction en plan d’action est directe.
- Recalibrez vos fenêtres de maintenance. Un rythme hebdomadaire signifie des redémarrages de noyau plus fréquents — à orchestrer avec livepatch quand un redémarrage immédiat n’est pas possible.
- Choisissez explicitement votre canal. La majorité des parcs reste sur le canal stable ; les environnements sensibles au délai testent -proposed sur un sous-ensemble avant de généraliser.
- Suivez les CVE noyau comme un flux, pas comme des événements. Avec le volume actuel, un correctif par semaine devient le rythme de base, et la question n’est plus « quand patcher » mais « dans quel ordre » — en commençant par les failles exploitables à distance ou localement sans privilège.
Verdict
Si vous gérez un parc Ubuntu exposé, considérez le passage au rythme hebdomadaire comme une amélioration nette du délai de correction — mais mesurez-en le coût en redémarrages et en tests avant de l’adopter les yeux fermés. Si votre exposition est forte et votre matériel hétérogène, utilisez -proposed sur un échantillon pour gagner une semaine sur les CVE critiques, en gardant le canal stable pour la production. Si vous êtes sous contrat de support, vérifiez comment l’engagement des 24 à 48 heures s’articule avec votre SLA : c’est là que se joue la valeur réelle de la nouvelle cadence.