L’intelligenza artificiale sta assumendo un ruolo sempre più importante nell’analisi del codice open source e anche il progetto GNOME si trova a dover affrontare le conseguenze di questa evoluzione. Michael Catanzaro, sviluppatore GNOME e manutentore del browser Epiphany, ha proposto di rivedere le restrizioni che impediscono di utilizzare report sulle vulnerabilità preparati con l’aiuto dell’intelligenza artificiale.
La questione nasce dall’aumento degli strumenti capaci di analizzare automaticamente grandi quantità di codice alla ricerca di errori. Secondo Catanzaro, ignorare questi strumenti non rappresenta più una strategia sostenibile, soprattutto perché le stesse tecnologie possono essere utilizzate anche da chi cerca vulnerabilità da sfruttare.
La posizione dello sviluppatore è però accompagnata da un problema altrettanto concreto: l’enorme quantità di segnalazioni che gli strumenti automatici possono produrre. L’esperienza maturata con la sicurezza di GNOME ha mostrato che trovare potenziali problemi è soltanto il primo passaggio. Ogni segnalazione deve essere verificata, classificata e, quando necessario, corretta dagli sviluppatori.
Il tema riguarda quindi non soltanto l’efficacia dell’IA nella ricerca delle vulnerabilità, ma anche la capacità dei progetti open source di gestire il crescente numero di segnalazioni.
L’IA trova più problemi, ma aumenta anche il lavoro per gli sviluppatori
Catanzaro sostiene che la qualità degli strumenti di analisi basati sull’IA sia migliorata sensibilmente rispetto al passato. Durante precedenti interventi aveva espresso maggiore scetticismo sulla possibilità che questi sistemi potessero competere con l’analisi manuale effettuata da sviluppatori esperti. Oggi la sua valutazione è cambiata.
Un elemento citato a sostegno di questa posizione riguarda fwupd 2.0.21, dove gli sviluppatori hanno corretto più di 250 potenziali problemi di sicurezza individuati da diversi scanner basati sull’intelligenza artificiale nell’arco di tre mesi. È importante sottolineare che il numero non corrisponde automaticamente a 250 vulnerabilità confermate: si tratta di problemi potenziali sottoposti successivamente a verifica.
Anche il numero di vulnerabilità registrate per GNOME è aumentato negli ultimi anni. Secondo i dati riportati da Catanzaro, le segnalazioni che hanno portato a CVE sono passate da 13 nel 2023 a 97 nel 2025, arrivando a 141 al 30 settembre 2026.
Questi numeri devono però essere interpretati con attenzione. L’aumento dei CVE non dimostra automaticamente che GNOME sia diventato meno sicuro. A incidere sono anche l’utilizzo di nuovi strumenti di ricerca, una migliore gestione delle segnalazioni e una maggiore propensione a registrare formalmente i problemi individuati.
Un altro esempio arriva da WebKitGTK, dove il numero di CVE del 2026 risulta particolarmente elevato. Una parte consistente della crescita è legata all’analisi di componenti come Skia e ANGLE inclusi nelle build di WebKit.
La questione diventa ancora più interessante osservando il programma GNOME Bug Bounty. L’iniziativa ha ricevuto 298 report complessivi, dei quali 71 sono stati accettati. Nel periodo considerato sono stati distribuiti 183.900 euro in ricompense. Il flusso di segnalazioni è però diventato difficile da gestire, al punto che Catanzaro ha chiesto la chiusura del programma.
La situazione evidenzia un paradosso: strumenti più efficaci permettono di scoprire più problemi, ma senza un numero sufficiente di persone disponibili a verificare i risultati possono trasformarsi in un nuovo collo di bottiglia.
GNOME deve ripensare il rapporto tra IA, vulnerabilità e comunità open source
Secondo Catanzaro, vietare i report prodotti con l’assistenza dell’IA rischia di escludere una parte significativa delle segnalazioni utili. La sua proposta è quindi quella di consentire l’utilizzo di questi strumenti, concentrando l’attenzione sulla qualità della vulnerabilità segnalata anziché sul metodo utilizzato per scoprirla.
Il problema non riguarda soltanto GNOME. I sistemi di intelligenza artificiale sono ormai accessibili a ricercatori indipendenti, aziende e potenziali aggressori. Se un progetto impedisce ai ricercatori di utilizzare l’IA per analizzare il proprio codice, non può impedire che la stessa tecnologia venga utilizzata da soggetti interessati a individuare vulnerabilità sfruttabili.
Catanzaro propone quindi un approccio nel quale l’IA viene considerata uno strumento di ricerca e non un sostituto del lavoro umano. Il report può essere prodotto con l’aiuto di un modello, ma la validazione della vulnerabilità deve comunque passare attraverso una verifica tecnica.
Questo punto è fondamentale perché un risultato prodotto da uno scanner non equivale automaticamente a una vulnerabilità reale. Un programma può individuare un comportamento anomalo senza dimostrare che possa essere sfruttato concretamente contro un’applicazione o un utente.
L’esperienza con GLib e libsoup ha mostrato proprio questa difficoltà. Alcune analisi hanno evidenziato possibili problemi legati a overflow numerici, gestione degli input e comportamenti anomali, ma stabilire la reale rilevanza di una segnalazione richiede competenze tecniche e conoscenza del contesto nel quale il codice viene utilizzato.
Per questo motivo il futuro della sicurezza dei progetti Linux potrebbe dipendere da un modello ibrido. L’IA può occuparsi dell’analisi su larga scala e individuare rapidamente porzioni di codice sospette, mentre gli sviluppatori possono concentrarsi sulla verifica, sulla classificazione e sulla correzione dei problemi.
La proposta di Catanzaro arriva inoltre in un momento nel quale molti progetti open source devono gestire risorse limitate. Un numero enorme di segnalazioni non verificate può infatti diventare quasi altrettanto problematico della mancanza di segnalazioni.
La sfida per GNOME e per altri grandi progetti open source sarà quindi trovare un equilibrio tra apertura verso i nuovi strumenti di sicurezza e capacità concreta di gestire i risultati. L’intelligenza artificiale può aumentare enormemente la capacità di individuare errori, ma la responsabilità di stabilire quali problemi siano realmente importanti e come correggerli rimane nelle mani degli sviluppatori.