La mailing list che coordina la sicurezza del kernel Linux sta attraversando una fase complicata: non per mancanza di contributi, ma per l’effetto opposto. Linus Torvalds ha definito “quasi ingestibile” il flusso di segnalazioni generate da ricercatori che usano strumenti AI per individuare bug nel codice del kernel. Il problema, ha spiegato, non riguarda soltanto la quantità di report ricevuti, ma soprattutto la ripetizione continua delle stesse vulnerabilità, identificate da persone diverse attraverso tool simili o addestrati sugli stessi set di dati.
La dichiarazione di Torvalds arriva durante il ciclo di sviluppo di Linux 7.1, in una fase in cui il progetto mantiene già un ritmo elevato: migliaia di patch per release, centinaia di maintainer coinvolti e un codice sorgente che supera ormai le 40 milioni di righe.
Non è che l’intelligenza artificiale trovi bug inesistenti; anzi, Torvalds ha riconosciuto implicitamente che molti report risultano tecnicamente corretti. Il tema cruciale riguarda il costo operativo di gestione di un volume di segnalazioni diventato pesantissimo.
Il problema dei duplicati creati dagli strumenti AI
Torvalds ha descritto uno scenario ormai ricorrente: più ricercatori eseguono scanner AI o modelli LLM sugli stessi alberi sorgente del kernel Linux e producono segnalazioni praticamente identiche. Chi gestisce la mailing list LKML e le liste security correlate si ritrova quindi a smistare report già corretti settimane prima oppure vulnerabilità già discusse pubblicamente.
Diversi strumenti di analisi del codice di programmazione assistita dall’AI combinano tecniche statiche tradizionali con modelli linguistici addestrati su repository pubblici.
Alcuni strumenti integrano regole e schemi derivati da CodeQL, mentre altri utilizzano motori di symbolic execution, una tecnica che analizza i possibili percorsi di esecuzione del codice, oppure classificatori basati su modelli linguistici LLM per individuare condizioni potenzialmente pericolose, come use-after-free (accesso a memoria già liberata), dereferenziazione di puntatori NULL, integer overflow (superamento dei limiti numerici di una variabile), race condition e gestione incompleta dei percorsi di errore.
Molti di questi sistemi tendono però a convergere sugli stessi pattern: se un modello individua una particolare struttura vulnerabile in un driver o in un sottosistema del kernel Linux, altri tool costruiti sugli stessi dati di addestramento arrivano facilmente alla medesima conclusione. Il risultato è una moltiplicazione artificiale delle segnalazioni.
Secondo Torvalds, gli sviluppatori passano sempre più tempo a rispondere con messaggi del tipo “già corretto” oppure “discusso il mese scorso“. È un’attività che sottrae tempo alla revisione di problemi realmente nuovi.
Linux non rifiuta l’AI, ma pretende responsabilità umana
Il kernel Linux non ha scelto una linea anti-AI. Anzi, nelle ultime settimane il progetto ha formalizzato regole specifiche per l’uso di codice assistito da modelli generativi.
La community ha introdotto il tag Assisted-by, separandolo dal tradizionale Signed-off-by usato nel processo di integrazione del kernel. Il primo conferma l’uso di modelli generativi, il secondo rappresenta una dichiarazione legale legata al Developer Certificate of Origin: in sostanza, chi firma il contributo destinato al kernel Linux conferma di avere diritto a inviare quel codice.
Linux scarica esplicitamente la responsabilità sul contributore umano: se il codice prodotto tramite AI introduce regressioni, problemi di licenza o falle di sicurezza, la colpa resta di chi invia la patch. Torvalds, su questo punto, mantiene una posizione molto pragmatica: l’AI è uno strumento, non un’entità autonoma.
Gli strumenti AI stanno comunque migliorando la “caccia ai bug”
Sarebbe però un errore leggere le parole di Torvalds come una bocciatura completa dell’uso dell’intelligenza artificiale nella sicurezza software. Alcuni maintainer Linux utilizzano quotidianamente sistemi locali per l’analisi automatizzata del codice.
Greg Kroah-Hartman, uno dei principali responsabili del ramo stable del kernel, ha recentemente mostrato una piattaforma interna chiamata informalmente “clanker“, basata su modelli eseguiti localmente su hardware AMD Ryzen AI Max+: lo scopo è individuare anomalie nel codice senza dipendere da servizi cloud esterni.
Gli strumenti AI diventano davvero utili quando operano dentro workflow controllati: dataset curati, validazione umana forte, riduzione dei falsi positivi e integrazione con sistemi di regression testing come KUnit, KernelCI o fuzzing continuo. Il valore reale emerge quando l’AI riduce il lavoro umano anziché moltiplicarlo.
La saturazione dei maintainer è un problema reale
Dietro lo sfogo di Torvalds c’è anche un tema meno visibile ma molto discusso nella comunità open source: il burnout dei maintainer. Il kernel Linux dipende da un numero relativamente limitato di sviluppatori senior che revisionano patch, coordinano sottosistemi e prendono decisioni tecniche delicate.
L’aumento dei contributi duplicati generati con l’AI rischia di trasformare parte del lavoro in una continua attività di filtraggio. E il problema non colpisce solo Linux: progetti come cURL, Node.js e varie distribuzioni BSD hanno già segnalato ondate di patch generate automaticamente, spesso difficili da verificare.
Alcuni maintainer hanno iniziato a rifiutare contributi che siano privi di spiegazioni dettagliate o riscontri concreti. Non tanto per ostilità verso l’AI, quanto perché revisionare codice non realmente compreso dall’autore stesso della segnalazione aumenta esponenzialmente i rischi.
La vera sfida riguarda il rapporto segnale-rumore
L’AI rende accessibili tecniche avanzate anche a ricercatori meno esperti: così, parlando di sicurezza del kernel Linux, si affollano molteplici segnalazioni sugli stessi temi che fanno perdere tempo e distolgono dalle attività principali. Torvalds afferma che serve capire se la vulnerabilità sia nuova, riproducibile, sfruttabile e rilevante per il modello di sicurezza del kernel.
La discussione aperta da Torvalds probabilmente anticipa ciò che accadrà in molti altri progetti open source: a fronte di strumenti AI sempre più efficaci, diventa sempre più opportuno dotarsi di processi di validazione molto più severi per evitare che il rumore superi il valore tecnico e, ad esempio, nel caso della sicurezza, porti a far passare in secondo piano vulnerabilità che dovrebbero essere immediatamente attenzionate.