L’IA trova le falle più in fretta

Il 4 novembre OpenAI ha descritto una campagna di agenti IA contro il kernel Linux, il software alla base dei telefoni Android, dell’infrastruttura cloud e dei supercomputer. In circa dieci giorni a partire da metà ottobre, gli agenti hanno prodotto exploit funzionanti per 948 falle distinte, ciascuna delle quali poteva trasformare un normale account utente nel pieno controllo di una macchina, e hanno scritto una patch candidata per ognuna. Una settimana prima Google aveva annunciato Gemini 4 Carbon e l’aveva affidato per primo a difensori informatici selezionati. Il tempo che passa tra l’esistenza di una falla e la sua scoperta si sta accorciando, e i laboratori vogliono che i difensori arrivino per primi.

Come ha lavorato OpenAI

La pipeline aveva cinque fasi e girava su un modello per la cybersicurezza che OpenAI ha rilasciato il 5 novembre come GPT-6 Cyber. Agenti esploratori hanno scelto 5'034 parti del kernel che meritavano un audit, circa il 7 per cento del suo codice. Agenti analisti le hanno trasformate in 2'308 possibili segnalazioni in 12 ore. Agenti di triage hanno cercato di riprodurre ciascuna in una macchina isolata e ci sono riusciti per 1'724, circa tre quarti, e OpenAI dice che solo il 3,1 per cento delle segnalazioni si basava su un’analisi errata. Le fasi successive hanno verificato quali falle potevano essere sfruttate e scritto le patch, e delle persone hanno esaminato i risultati prima di qualsiasi segnalazione.

La campagna è costata 1'213'430 dollari in crediti API, cioè circa 1'279 dollari per exploit. I sistemi bersaglio eseguivano una distribuzione Linux desktop standard con le sue normali protezioni attive. Una campagna a luglio con un modello precedente, GPT-5.6 Sol, aveva trovato 166 falle di questo tipo. Il nuovo modello ne ha trovate più di cinque volte tante, nonostante nel frattempo il kernel fosse stato rafforzato per tre mesi.

Che cosa dicono i laboratori sui limiti

OpenAI è franca su ciò che è andato storto. In una prima campagna la pipeline aveva segnalato 200 exploit riusciti, e la revisione umana ha scoperto che 20 di essi avevano ottenuto il pieno controllo attraverso una falla sconosciuta diversa da quella assegnata. «Questo suggerisce che anche uno sfruttamento riuscito da parte degli agenti richiede una validazione adeguata», ha scritto OpenAI, che ha aggiunto un controllo indipendente per verificare che ogni exploit usasse la falla assegnata. La sua lezione vale per qualsiasi lavoro automatizzato: «verificare il percorso verso un risultato, oltre a verificare il risultato stesso».

Anche le patch hanno richiesto lavoro. Le prime funzionavano, ma a volte aggiungevano codice inutile, ignoravano le convenzioni locali o non coprivano varianti della stessa falla, finché istruzioni aggiuntive e nuove iterazioni non le hanno migliorate. OpenAI definisce le sue cifre sui costi «piuttosto un limite superiore». Tutti questi numeri sono di OpenAI. Al 5 novembre non avevamo trovato alcun audit indipendente né alcuna dichiarazione pubblica dei maintainer del kernel su questo lotto.

Prima i difensori

L’annuncio di Google del 28 ottobre segue lo stesso schema. Definisce Gemini 4 Carbon «il nostro modello più potente, con capacità allo stato dell’arte nella cybersicurezza e sugli orizzonti lunghi» e riporta l’88,2 per cento su SEC-bench Pro per la ricerca di falle, il 54,8 per cento su ExploitGym e il 71,0 per cento su CWE-bench per le patch, tutte cifre di Google, misurate senza guardrail. L’accesso parte da un sottoinsieme di difensori informatici e si allarga per fasi attraverso il Fairwind Program, che secondo SecurityWeek conta più di 650 partecipanti, tra cui governi e gestori di infrastrutture critiche. Un rilascio per sviluppatori, aziende e consumatori è promesso «il prima possibile», senza una data.

Anthropic ha inaugurato questo schema con Mythos ad aprile, e OpenAI lo segue. GPT-6 Cyber va prima a un gruppo selezionato di clienti approvati di Daybreak Red, il suo programma per i test di sicurezza autorizzati, e OpenAI classifica il modello come Critical per la cybersicurezza secondo il proprio Preparedness Framework. Il suo annuncio spiega perché: «È chiaro che abbiamo una finestra limitata per usare i modelli di frontiera per rendere sicuro il software».

Il punto di vista dei maintainer

Ogni segnalazione arriva a qualcuno che deve correggere la falla. A marzo Greg Kroah-Hartman, maintainer senior del kernel, ha detto a The Register che circa un mese prima le segnalazioni fatte con l’IA erano passate dalla spazzatura a casi autentici: «Ora abbiamo segnalazioni vere». A maggio Linus Torvalds ha scritto che «il continuo diluvio di segnalazioni IA ha praticamente reso la lista sulla sicurezza quasi del tutto ingestibile», perché molte persone trovano gli stessi bug con gli stessi strumenti. Il suo consiglio a chi segnala: «Se avete trovato un bug usando strumenti di IA, è probabile che l’abbia trovato anche qualcun altro». A luglio il team del kernel ha pubblicato 432 CVE nell’arco di una sola domenica e del lunedì successivo.

Mentre la scansione di OpenAI era in corso, maintainer e altri contributori stavano già correggendo molte delle stesse falle: dopo dieci giorni, 61 erano state corrette upstream, 43 avevano patch in attesa e 299 erano in discussione pubblica. OpenAI dice di aver seguito le indicazioni della comunità del kernel e di aver finora comunicato 304 segnalazioni critiche con patch candidate. A nostro avviso la risorsa scarsa è ormai l’attenzione di chi esamina, testa e rilascia le correzioni.

Che cosa può fare un’azienda

La maggior parte delle aziende si limita a far girare il software che riceve queste correzioni, spesso in grandi lotti. OpenAI stessa ne trae la conclusione: per ora, un account con pochi privilegi su un sistema che «non è aggiornato con le ultime patch disponibili dovrebbe essere considerato funzionalmente equivalente a un accesso root per un attore malevolo dotato di ampie risorse». Ne derivano, a nostro avviso, quattro cose.

Applicate le patch più in fretta, e sappiate che cosa fate girare. Jan Schaumann, chief information security architect di Akamai, ha scritto a luglio che dare priorità alle singole modifiche del kernel non è più praticabile, e ha detto a The Register che «aggiornamenti automatici, regolari e frequenti» sembrano l’unico approccio ragionevole, per quanto difficili siano per le grandi organizzazioni. Serve un elenco aggiornato di ogni server, dispositivo e servizio, e di chi aggiorna ciascuno.

Scegliete fornitori che applicano le patch rapidamente, e chiedete quanto tempo impiega una correzione critica ad arrivare da voi. Chiedete ai vostri fornitori di software come usano questi modelli: se analizzano il proprio codice, come verificano ciò che i modelli segnalano e se partecipano a programmi come Daybreak o Fairwind.

Tenete i dati sensibili in sistemi che controllate voi, con accessi limitati per ruolo, così che una falla nel servizio di qualcun altro esponga meno. Il controllo non elimina l’obbligo di applicare le patch: lo rende vostro. OpenAI raccomanda anche sandbox e isolamento per limitare i danni quando qualcosa viene sfruttato.

Dove ci collochiamo

Non costruiamo scanner di sicurezza. La nostra parte è l’ultimo punto di quell’elenco. Twin, già disponibile, dà agli assistenti di un’azienda un unico cervello con accessi per ruolo, ogni operazione di scrittura legata all’accesso del singolo utente e ogni passaggio registrato, in hosting in Svizzera, nell’UE, negli Stati Uniti o sull’hardware dell’azienda. Eigna, in accesso anticipato e costruito dal nostro partner Eigna Labs, è un modello privato che gira nel cloud dell’azienda o sui suoi server ed è progettato per funzionare offline in reti chiuse. Come qualsiasi altra cosa che un’azienda gestisce, entrambi vanno tenuti aggiornati.