Intelligenza artificialeSicurezza Informatica

1.313 CVE in un colpo solo: l’AI sta mandando in crisi il modello della sicurezza Linux?

6 ottobre 2026

La pubblicazione da parte di Debian di un aggiornamento del kernel Linux con un elenco di vulnerabilità lungo quasi quanto un piccolo libro ha riacceso una discussione che va ben oltre Linux. Il problema non è soltanto che oggi vengono trovati più bug. È che l’intelligenza artificiale sta rendendo la ricerca delle vulnerabilità così economica e scalabile da mettere in discussione il modo stesso in cui il settore della sicurezza informatica le cataloga, le valuta e le corregge.

Il bollettino che ha acceso la discussione

Il caso che ha fatto esplodere il dibattito è il bollettino Debian DSA-6528-1, pubblicato il 29 settembre 2026 per il kernel di Debian 13 “trixie”. Il testo è laconico: diverse vulnerabilità che possono portare a escalation dei privilegi, denial of service o fughe di informazioni, e la raccomandazione di aggiornare il kernel.

Jan Schaumann, ricercatore di sicurezza e Chief Information Security Architect di Akamai, ha però contato gli identificativi elencati nell’avviso: 1.313 CVE. In un messaggio sulla mailing list oss-security ha sostenuto che un bollettino del genere non serve più a nulla di concreto, e che per chi difende sistemi complessi sta diventando poco realistico continuare a esaminare e valutare ogni vulnerabilità singolarmente.

Il numero, però, va interpretato con cautela. Il kernel Linux adotta deliberatamente una politica molto prudente nell’assegnazione delle CVE. Poiché il kernel opera al livello più privilegiato del sistema, un errore apparentemente innocuo può, in determinate condizioni, trasformarsi in un problema di sicurezza. Per questo la documentazione del kernel dichiara apertamente che il team assegna una CVE praticamente a ogni correzione di bug che individua, anche quando la reale sfruttabilità è limitata a configurazioni molto particolari. È uno dei temi più discussi nel lungo thread apparso su Hacker News: contare le CVE non equivale automaticamente a misurare quanto un sistema sia insicuro.

Torvalds: il problema non è l’AI, è come arrivano i risultati

Una delle voci più importanti è quella di Linus Torvalds, creatore di Linux e responsabile principale dello sviluppo del kernel. Già a maggio 2026, nell’annuncio di una release candidate, Torvalds aveva scritto che il flusso di vulnerabilità trovate con strumenti di intelligenza artificiale aveva reso la mailing list privata dedicata alla sicurezza del kernel “quasi del tutto ingestibile”. Il punto, per lui, non era che l’AI trovasse bug. Era il modo in cui quei risultati arrivavano ai maintainer: persone diverse usavano gli stessi strumenti, trovavano gli stessi problemi e inviavano segnalazioni duplicate, senza aggiungere nulla, né un’analisi né una patch. Il suo invito era esplicito: se vuoi dare un contributo, leggi la documentazione, scrivi anche la correzione e metti del valore vero sopra quello che ha fatto l’AI.

La posizione di Torvalds è quindi molto meno ostile all’intelligenza artificiale di quanto si potrebbe pensare. A luglio ha chiarito che Linux “non è uno di quei progetti anti-AI” e che non intende impedire a nessuno di usare gli LLM. La responsabilità, però, resta umana, ed è la linea che le regole del kernel hanno fissato: un risultato prodotto da una macchina diventa utile soltanto quando qualcuno lo comprende, lo verifica e se ne assume la responsabilità tecnica.

Kroah-Hartman: 79 vulnerabilità, una decina di correzioni vere

Ancora più interessante è la posizione di Greg Kroah-Hartman, Linux Foundation Fellow e responsabile delle release stable del kernel, cioè una delle persone che distribuiscono materialmente le correzioni che finiscono sui sistemi Linux di tutto il mondo.

A Kernel Recipes 2026, a Parigi, Kroah-Hartman ha analizzato un caso molto pubblicizzato: le 79 vulnerabilità del kernel che Anthropic aveva annunciato di aver trovato con il suo modello Mythos. Esaminate una per una, il quadro è diventato molto meno spettacolare. Ventiquattro segnalazioni non contenevano dettagli sufficienti, quattordici non erano bug, tre contenevano dati inventati e quindici riguardavano problemi già corretti. Alla fine, secondo la sua valutazione, le correzioni davvero significative erano circa dieci.

Questo non significa che Kroah-Hartman consideri inutile l’intelligenza artificiale. Al contrario, descrive questi strumenti come un’ottima forma di analisi statica, proprio perché lavorano riconoscendo schemi ricorrenti nel codice. Il problema nasce quando il risultato della macchina viene trattato come una conclusione invece che come il punto di partenza di un’indagine. In un esperimento in cui alcune patch di sicurezza generate da LLM sono state fatte revisionare a dottorandi, circa la metà di quelle che sembravano convincenti si è rivelata sbagliata, inutile o riferita a problemi inesistenti. Per chi mantiene il kernel il rischio è evidente: automatizzare la ricerca delle vulnerabilità senza automatizzare con la stessa affidabilità la loro verifica significa scaricare enormi quantità di lavoro sugli esseri umani.

Stenberg e curl: sommersi, ma non contrari

Una posizione simile, osservata da un progetto completamente diverso, arriva da Daniel Stenberg, fondatore e principale sviluppatore di curl e libcurl, uno dei componenti open source più diffusi al mondo. Stenberg è da tempo molto critico verso le segnalazioni di sicurezza generate automaticamente e non verificate. A gennaio 2026 curl ha chiuso il proprio programma di bug bounty, dopo che il team era stato sommerso da segnalazioni di scarsa qualità prodotte con l’AI.

Ma anche la sua posizione è più sfumata di un semplice rifiuto. A maggio ha raccontato che strumenti automatici come AISLE, ZeroPath e Codex Security di OpenAI avevano portato, in meno di un anno, a qualche centinaio di correzioni di bug in curl, e che una dozzina abbondante di questi era diventata una CVE. Il progetto usa inoltre l’AI per la revisione del codice. Per Stenberg questi strumenti aiutano i revisori umani, ma non li sostituiscono. Il problema non è quindi l’intelligenza artificiale in sé, ma il fatto che generare una segnalazione convincente costa quasi nulla, mentre verificarla continua a richiedere tempo e competenze molto costose.

Ptacek: non scommettete contro gli LLM

Dall’altro lato del dibattito c’è una voce particolarmente significativa, quella di Thomas Ptacek, veterano della ricerca sulla sicurezza software e cofondatore di Matasano Security, società che è stata per anni uno dei nomi importanti nella ricerca sulle vulnerabilità. Ptacek invita a non sottovalutare ciò che sta accadendo. Secondo lui la ricerca di vulnerabilità potrebbe essere il problema di ingegneria del software più adatto agli LLM: è guidata dal riconoscimento di schemi, dispone di un enorme corpus di esempi pubblici e permette di verificare rapidamente se un tentativo funziona oppure no. La sua posizione è sostanzialmente opposta a quella di chi liquida le recenti scoperte come marketing: “non scommettete contro gli LLM su questo”.

Cosa succede nei progetti più piccoli

Il thread di Hacker News offre poi uno sguardo interessante su ciò che accade lontano dal kernel. Thomas Boutell, cofondatore di Apostrophe e promotore del lavoro che ha portato al formato PNG, racconta che il progetto open source che guida, molto più piccolo, riceveva da mesi almeno sei segnalazioni di sicurezza responsabili al mese, mentre nell’ultimo mese ne sono arrivate ventidue. La sua sintesi è efficace: il software è difficile e l’AI è meticolosa. Il suo team riesce ancora a tenere il passo usando a sua volta l’intelligenza artificiale, insieme alla revisione umana. Ma la sproporzione è evidente: il numero di persone, e di macchine, che possono cercare vulnerabilità in un progetto può crescere quasi senza limiti, mentre il numero di maintainer capaci di comprenderle e correggerle non cresce con la stessa velocità.

Nella stessa discussione interviene William Woodruff, maintainer open source coinvolto in progetti come Homebrew e Sigstore e autore di strumenti per la sicurezza della software supply chain. Woodruff descrive un altro effetto del sistema attuale: molte aziende hanno una “gestione del rischio” che consiste nel sollecitare i progetti open source a fare lavoro gratuito per loro, anche quando l’avviso è palesemente privo di senso o non ha alcun impatto nel contesto reale. È la mentalità del “pallino verde” sulla dashboard, che le CVE incoraggiano agganciando a ogni identificativo un punteggio CVSS. Il rischio è trasformare la sicurezza in una corsa a spegnere avvisi invece che in una valutazione concreta dell’esposizione.

La fine della scarsità delle vulnerabilità

Mettendo insieme queste opinioni emerge un quadro meno sensazionalistico, ma probabilmente più importante della cifra di 1.313 CVE. Le persone che lavorano direttamente sul kernel e sui grandi progetti open source non dubitano che l’intelligenza artificiale possa trovare vulnerabilità reali. Anzi, in molti casi la stanno già usando proprio per questo. Il problema è che trovare un possibile bug sta diventando molto più economico che stabilire se sia davvero pericoloso.

Per decenni il modello della sicurezza informatica ha trattato la scoperta di una vulnerabilità come un evento relativamente raro. Un ricercatore trovava un problema, qualcuno lo analizzava, veniva assegnata una CVE, veniva preparata una patch e gli amministratori decidevano quanto rapidamente applicarla. Quel sistema funziona molto meno bene quando milioni di righe di codice possono essere analizzate di continuo da migliaia di agenti automatici.

Il vero cambiamento introdotto dall’AI potrebbe quindi non essere un improvviso aumento dell’insicurezza del software. Potrebbe essere la fine della scarsità delle vulnerabilità conosciute.

Quando trovare un potenziale problema costa quasi nulla, il valore si sposta altrove: capire quali vulnerabilità siano davvero sfruttabili, correggerle senza introdurre nuovi errori, distribuire rapidamente gli aggiornamenti e progettare sistemi in cui una singola falla abbia conseguenze limitate.

È qui che le opinioni di Torvalds, Kroah-Hartman, Stenberg, Ptacek e degli altri sembrano convergere, nonostante le differenze. L’intelligenza artificiale non elimina il lavoro umano dalla sicurezza informatica. Almeno per ora sta facendo quasi l’opposto: produce una quantità di informazioni tale da rendere ancora più preziosi il giudizio umano, la conoscenza del sistema e la capacità di distinguere un rischio vero dal rumore.

Chi più paga, più vede

C’è però un aspetto di questa storia che mi preoccupa più del numero di CVE.

Gli strumenti che oggi trovano vulnerabilità su larga scala non sono gratuiti. Girano su modelli di frontiera a pagamento, e la loro efficacia cresce con quanto si è disposti a spendere: più token, più agenti in parallelo, più tempo di calcolo, più codice analizzato. Chi ha budget può passare al setaccio milioni di righe ogni giorno; chi non lo ha deve accontentarsi di molto meno.

Purtroppo tutto questo sta introducendo un modello di scarsa democratizzazione della tecnologia. Chi più paga, più abilità ha. Chi non paga, semplicemente, non ha abilità sufficienti per competere: né per trovare i bug nel proprio software prima che li trovi qualcun altro, né per difendersi da chi può permettersi di cercarli in quello altrui.

Per una grande azienda è una voce di costo. Per un maintainer volontario, per un piccolo progetto open source o per una PMI è un dislivello che rischia di diventare strutturale. Le stesse persone che oggi ricevono gratis le segnalazioni prodotte dalle macchine degli altri sono spesso quelle che non possono permettersi le stesse macchine per verificarle.

Vedo una sola via d’uscita realistica, e passa dall’hardware. Se l’hardware per l’inferenza locale continuerà a diventare più accessibile, e se i pesi dei modelli open source continueranno a migliorare, un giorno potremo avere LLM locali abbastanza potenti da renderci indipendenti dai modelli di frontiera. Allora la capacità di analizzare il proprio codice non dipenderà più da un abbonamento o da un budget di API, ma da una macchina che si possiede.

Fino a quel giorno, la sicurezza rischia di diventare l’ennesima cosa che si compra, invece di qualcosa che si sa fare.