In questa nuova era informatica dominata dall’AI, una delle problematiche che riguarda da vicino progetti ampi come il Kernel Linux è quella del numero delle vulnerabilità critiche rilevate in tempi strettissimi da parte degli LLM. Sebbene questa, lo abbiamo già raccontato, sia diventata la nuova normalità, con situazioni limite di 432 CVE pubblicate in due giorni, la verità è che chi gestisce le distribuzioni Linux ha dovuto a sua volta rivedere ritmi e workflow.

È una cosa assolutamente inevitabile, essendo il Kernel Linux alla base di tutte le distribuzioni.

Già nell’agosto del 2024, Canonical aveva annunciato l’intenzione di utilizzare l’ultima release disponibile del Kernel Linux, a prescindere dal fatto che questa fosse una release candidate ed ora la distribuzione di casa Canonical fa un passo ulteriore in avanti.

Come annunciato nel blog ufficiale di Canonical, Ubuntu cambierà il ritmo con cui pubblica gli aggiornamenti del Kernel Linux, proprio per riuscire a distribuire più rapidamente le correzioni di sicurezza (CVE).

Oggi il modello è basato su un ciclo 4/2: normalmente viene preparato un aggiornamento del Kernel ogni quattro settimane, con un ulteriore aggiornamento intermedio a due settimane, dedicato soprattutto alle vulnerabilità più urgenti. Canonical vuole abbandonare questo schema e passare a un ciclo SRU (ossia Stable Release Update) di due settimane, ma con cicli sovrapposti.

Il punto importante è che “ciclo di due settimane” non significa che uscirà un Kernel ogni due settimane. I cicli saranno sfalsati: mentre un Kernel è nella seconda settimana di test e certificazione, il successivo sarà già nella prima settimana di preparazione. Di conseguenza, a regime Canonical pubblicherà un nuovo Kernel ogni settimana. La prima settimana sarà dedicata alla preparazione: integrazione delle patch, build e smoke test. I pacchetti finiranno quindi nel repository -proposed. La seconda settimana sarà invece dedicata ai test più approfonditi, alla certificazione dell’hardware, all’integrazione con Ubuntu e ai regression test. Al termine il kernel passerà agli utenti come aggiornamento stabile.

L’obiettivo di Canonical è quindi ridurre il tempo che intercorre tra la scoperta/pubblicazione di una vulnerabilità e la disponibilità della correzione, senza eliminare la fase di testing.

C’è poi un aspetto interessante per chi ha esigenze di sicurezza particolarmente stringenti: non sarà necessario aspettare la fine delle due settimane. I Kernel candidati vengono pubblicati settimanalmente in -proposed. Un’organizzazione può quindi prendere quel Kernel e fare autonomamente i propri acceptance test, assumendosi il trade-off tra velocità e il fatto che Canonical non abbia ancora completato tutta la certificazione. In altre parole, Canonical mantiene il proprio processo rigoroso, ma offre una via per anticipare ulteriormente l’adozione della correzione.

Infine, Canonical dice che non vuole lasciare necessariamente scoperto il periodo tra la pubblicazione di una CVE e l’arrivo del nuovo Kernel. Quando possibile fornirà workaround sicuri, mentre quando non sarà possibile, dichiarerà esplicitamente l’assenza di workaround e indicherà eventuali misure di hardening. L’obiettivo dichiarato è portare i sistemi in una condizione “difendibile” entro 24–48 ore dalla disclosure, anche se la patch definitiva del Kernel arriverà successivamente.

Un successivo annuncio sul canale discord del Kernel Team ha raccontato l’avvio della transizione, che partirà con due cicli consecutivi il 28 settembre e il 12 ottobre 2026, per poi arrivare ai cicli sovrapposti dal 26 ottobre 2026.

Insomma, la via per fronteggiare la pioggia dei CVE è accelerare.

Come a dire, chi non ha testa, ha gambe.