All’inizio di ottobre 2026, gli ingegneri di Amazon Web Services (AWS) hanno illustrato un flusso per classificare i CVE del kernel Linux mantenuto per l’infrastruttura EC2: uno script filtra le vulnerabilità pertinenti, un agente IA classifica quelle rimaste e gli ingegneri ne esaminano i risultati. Il kernel in questione è distinto da Amazon Linux e dai kernel eseguiti nelle macchine virtuali dei clienti. CVE, sigla di Common Vulnerabilities and Exposures, identifica una vulnerabilità di sicurezza registrata pubblicamente.
Come AWS filtra e classifica i CVE
Il primo passaggio confronta le versioni interessate e i file indicati nel CVE con la versione del kernel e i file compilati nell’immagine AWS. Questo filtro, basato su uno script e non sull’IA, elimina circa il 70% dei CVE nell’ambiente AWS; la quota dipende dalla configurazione e dall’ambiente.
L’agente analizza i casi rimanenti usando l’albero del kernel personalizzato da AWS, le configurazioni del kernel, un modello di minaccia e criteri di gravità. Per ogni CVE produce una riga con informazioni come sottosistema, tipo di vulnerabilità e vettore d’attacco. Il flusso presentato prosegue con la revisione degli ingegneri.
AWS ha riferito che il filtro automatico tratta un CVE in circa 3,4 secondi, contro alcuni minuti per il triage umano. È il tempo di classificazione dell’agente per singolo CVE: la revisione, l’eventuale correzione, i test e la distribuzione richiedono passaggi distinti. Di solito, secondo quanto riferito, due ingegneri esaminano la tabella; la revisione umana resta il collo di bottiglia.
Justinien Bouron ha stimato informalmente che il 5-10% delle decisioni dell’agente fosse problematico. La cifra riguarda le decisioni dell’agente, non una percentuale di vulnerabilità corrette o lasciate senza correzione.
L’aggiornamento del kernel coinvolge anche altri componenti
Nel passaggio da Linux 5.10 a 6.12, AWS ha suddiviso i problemi seguiti in quattro categorie. Le quote riguardano i problemi dell’aggiornamento, non i CVE o il tempo necessario per risolverli.
| Categoria dei problemi seguiti | Quota |
| Spazio kernel | 45% |
| Spazio utente | 43% |
| Configurazione del kernel | 7% |
| Firmware o hardware | 5% |
AWS ha inoltre riferito che il 15% delle correzioni nello spazio kernel è stato integrato nel kernel principale, a monte delle versioni derivate. I problemi emersi nell’aggiornamento hanno richiesto interventi anche su altre parti del sistema: un cambiamento nella gestione delle aree di memoria virtuale ha rallentato mmap() e munmap(), mentre una modifica dello scheduler ha alterato i tempi di fork(). In un altro caso, la dimensione massima predefinita delle richieste al sottosistema a blocchi ha causato timeout dell’I/O firmware, affrontati con impostazioni sysctl.
AWS ha riportato tempi di 24 mesi per l’aggiornamento da 4.19 a 5.10, 12 mesi da 5.10 a 6.12 e 6 mesi da 6.12 a 6.18. La presentazione attribuisce il miglioramento a strumenti migliori, test più ampi e all’esperienza del team. Il lavoro di qualificazione, quindi, non si esaurisce nel portare il codice del kernel a una versione più recente.
Che cosa indicano i numeri dei rami LTS
LTS significa long-term support, cioè supporto a lungo termine. Nella fotografia del 16 settembre 2026, AWS ha contato i CVE irrisolti nei diversi rami Linux LTS. La mediana misura i giorni tra l’integrazione di una correzione nel kernel principale e la sua pubblicazione in un ramo LTS.
| Ramo Linux LTS | CVE irrisolti al 16 settembre 2026 | Mediana fino al rilascio LTS (giorni) |
| 5.10 | 1.709 | 31,8 |
| 5.15 | 1.567 | 31,5 |
| 6.1 | 1.062 | 28,8 |
| 6.6 | 762 | 23,1 |
| 6.12 | 483 | 19,0 |
| 6.18 | 229 | 18,1 |
Nello stesso snapshot, i rami fuori supporto 4.19 e 5.4 avevano rispettivamente 3.725 e 3.481 CVE irrisolti. Questi conteggi descrivono i rami Linux nel loro complesso, non il numero di vulnerabilità presenti nel kernel EC2 di AWS. Anche i tempi mediani riguardano il rilascio nei rami LTS, non la distribuzione di un aggiornamento da parte di AWS.
Dopo il triage, AWS descrive quattro possibili risposte, da scegliere in base all’applicabilità e all’impatto del CVE: nessun intervento se la vulnerabilità non riguarda l’ambiente; attesa della prossima patch LTS quando l’impatto consente di aspettare; selezione e applicazione di una correzione specifica (cherry-pick) quando serve intervenire prima; oppure una soluzione alternativa (workaround) se non è possibile aggiornare il kernel. Nella propria classificazione relativa, AWS associa a queste opzioni velocità e rischio rispettivamente nulli, lento e medio, rapido e alto, rapidissimo e basso.
