Ubuntu cambia ritmo: un nuovo kernel ogni settimana perché le vulnerabilità crescono

Canonical modifica il processo con cui Ubuntu distribuisce gli aggiornamenti del kernel per ridurre il tempo che separa la divulgazione di una vulnerabilità dalla disponibilità della relativa correzione.

La decisione arriva mentre il numero di problemi di sicurezza individuati nel codice Linux continua a crescere e gli strumenti basati su Intelligenza Artificiale contribuiscono ad automatizzare la ricerca dei bug.

Il nuovo modello non elimina le verifiche necessarie prima della pubblicazione: interviene invece sulla loro organizzazione, sovrapponendo cicli differenti. La documentazione di Canonical descrive infatti gli SRU come una procedura dedicata agli aggiornamenti delle release già pubblicate, con test di regressione eseguiti anche sull’hardware certificato. La modifica riguarda quindi soprattutto la frequenza con cui le correzioni possono raggiungere gli utenti.

Come cambia il ciclo del kernel Ubuntu

Il modello precedente prevedeva un ciclo ordinario di quattro settimane e uno dedicato alla sicurezza di due.

Canonical passa ora a cicli SRU di due settimane, avviati a distanza di una settimana l’uno dall’altro. La sovrapposizione permette di pubblicare un nuovo kernel ogni settimana senza concentrare integrazione, compilazione e verifiche nello stesso intervallo.

Nella prima fase vengono integrate le correzioni, preparati i pacchetti e realizzate le build. Seguono controlli preliminari, mentre le versioni candidate vengono pubblicate nel repository -proposed. La fase successiva concentra invece certificazione dell’hardware, integrazione con Ubuntu e test di regressione. La documentazione ufficiale conferma che questi controlli servono a verificare il comportamento degli SRU sui sistemi certificati.

Il vantaggio del nuovo schema riguarda soprattutto la sovrapposizione dei lavori: mentre un kernel affronta i controlli finali, il ciclo seguente può già procedere con la preparazione delle proprie correzioni. Per gli amministratori che non possono attendere la pubblicazione stabile esiste inoltre la possibilità di utilizzare le release candidate presenti in -proposed e sottoporle ai propri test di accettazione. In questo caso una parte della validazione passa direttamente all’organizzazione che decide di adottarle.

Perché le vulnerabilità spingono Canonical ad accelerare

Canonical collega la modifica alla crescita dei problemi di sicurezza individuati nel kernel. I Large Language Models e gli agenti specializzati hanno reso la ricerca dei bug molto più automatizzata, aumentando il volume di problemi che i manutentori devono analizzare e correggere. La crescita non dipende però esclusivamente dall’AI: dal 2024 la comunità del kernel Linux opera anche come autorità per l’assegnazione degli identificativi CVE, includendo nella classificazione di sicurezza un numero più ampio di difetti che possono influire su un sistema in esecuzione.

Canonical vuole inoltre ridurre il periodo durante il quale un sistema resta esposto dopo la divulgazione pubblica di una vulnerabilità. Quando una patch definitiva richiede tempo, l’azienda intende fornire, dove possibile, workaround sicuri oppure indicazioni di hardening. L’obiettivo dichiarato è portare i sistemi in una condizione definita più sicura entro 24-48 ore dalla divulgazione, senza considerare queste misure sostitutive dell’aggiornamento definitivo.

Per gli amministratori Ubuntu, il cambiamento introduce soprattutto una nuova esigenza operativa: valutare più rapidamente compatibilità, regressioni e priorità degli aggiornamenti. Un ritmo più serrato può ridurre il tempo di esposizione, ma rende ancora più importante disporre di ambienti di test e procedure capaci di intercettare problemi prima che una nuova build raggiunga sistemi critici.