AWS usa agenti AI per il triage delle CVE del kernel EC2

Sedici CVE al giorno stanno cambiando il lavoro sul kernel di EC2. Per gestire il volume, il team AWS usa una catena in tre passi: filtro automatico, agente AI, revisione umana. L’obiettivo è capire in fretta cosa tocca i rami in produzione, seguendo il flusso di segnalazioni del progetto Linux¹.

Dylan Johnson e Justinien Bouron hanno descritto il metodo al Linux Plumbers Conference di Praga, a inizio mese. Hanno chiarito l’ambito: si parla del kernel che gira nell’infrastruttura EC2. Non di Amazon Linux. Non dei kernel nelle VM dei clienti¹.

La pressione nasce da un cambio di governance nel tracciamento delle vulnerabilità. Da febbraio 2024, il progetto Linux è diventato CVE Numbering Authority. Si è passati da circa due CVE a settimana prima del 2024 a circa sedici al giorno dopo. Al 15 agosto 2026, il progetto aveva pubblicato 848 CVE che riguardano il kernel. Johnson e Bouron portano questi numeri per mostrare la scala del problema¹.

Si parte dai record ufficiali. Le CVE del kernel arrivano in JSON con due campi chiave: versioni colpite e file sorgente interessati. Su questi campi corre un primo filtro automatico. Solo dopo entra in gioco un agente AI. Chiude la catena una revisione umana¹. Gli ingegneri non hanno dettagliato quali segnali specifici esamini l’agente. Non indicano, per esempio, se valuti gravità o priorità interne. Questo dettaglio non compare nelle fonti pubbliche dell’intervento¹.

Accanto al triage, gli autori propongono una scelta di manutenzione: spostarsi verso rami LTS più recenti. I rami vecchi, spiegano, accumulano correzioni che non vengono mai backportate. Restarci sopra aumenta il debito tecnico e complica l’assorbimento delle patch di sicurezza¹.

Nel contesto ufficiale del progetto kernel serve un’ulteriore cautela. La documentazione ricorda che il progetto non può sapere come un sistema usa il kernel. La decisione su quali CVE si applichino a un ambiente specifico spetta agli utenti. Per questo, anche con un agente AI in mezzo, la revisione finale resta umana e centrata sul perimetro dell’infrastruttura EC2¹.

Johnson e Bouron riassumono così una pratica costruita sul formato dei dati e sui confini operativi. Filtro sui campi JSON, agente AI dopo la scrematura, controllo umano prima di toccare i rami interni di EC2. Separazione chiara dai cicli di Amazon Linux e dalle VM dei clienti. E un orientamento pragmatico sugli LTS: meglio i rami recenti, perché ricevono davvero le correzioni¹.

Se il ritmo delle CVE resterà su questi livelli, la scelta di LTS più nuovi rischia di diventare un vincolo per chi mantiene kernel personalizzati. Vale per AWS e per ogni infrastruttura che vive di backport continui¹.