Linux, intelligenza artificiale lcoale e il futuro della sicurezza del kernel

Greg Kroah-Hartman, maintainer of the stable Linux kernel branch, warned at FINOS that the time between bug discovery and exploitation has turned negative, with bugs exploited 7 days before patches are released. He urged developers to use local open-source LLMs for bug finding, noting that public AI models create noise and privacy risks, and that open-source models can fix 80-90% of issues locally.

Linux, intelligenza artificiale lcoale e il futuro della sicurezza del kernel Greg Kroah-Hartman, maintainer del ramo stabile del kernel Linux, ha tenuto una keynote al FINOS sull'impatto degli LLM nel mondo dell'open source. Il suo messaggio e chiaro: non e magia, e solo ingegneria. Il kernel non si ferma Linux gira su tutto. Il suo compito e rendere l'hardware trasparente, indipendentemente che si tratti di ARM64, RISC-V, AMD o x86. Il kernel esiste per far sì che le applicazioni funzionino senza che lo sviluppatore debba preoccuparsi di cosa c'e sotto. Il progetto non e mai finito. Mentre la maggior parte dei progetti rallenta nel tempo, Linux continua a crescere. L'anno scorso hanno lavorato oltre 5.000 sviluppatori, provenienti da almeno 375 aziende. Il ritmo e impressionante: 9 modifiche all'ora, 15 correzioni al giorno sugli alberi stabili, 100 CVE ogni settimana. Greg fa notare che questo ritmo non e una cosa nuova. Lo fanno da 12 o 13 anni. Quando qualcuno esce con un modello che trova 100 bug nel kernel, la sua reazione e semplice: "Ottimo, erano due giorni di lavoro." Il tempo tra scoperta e sfruttamento si e azzerato La situazione della sicurezza e diventata critica. Jim Zemlin, CEO della Linux Foundation, ha presentato dati allarmanti: il tempo tra la scoperta di un bug e il suo sfruttamento attivo si e ridotto fino a diventare negativo. Oggi i bug vengono sfruttati 7 giorni prima che la correzione venga rilasciata. Il ciclo tradizionale di scoperta, divulgazione, patch e distribuzione non funziona piu. Il kernel adotta un approccio diverso: ogni bug viene corretto e distribuito immediatamente, senza aspettare. La divulgazione avviene solo dopo aver dato tempo alle persone di aggiornarsi. Gli LLM sono diventati bravi a trovare bug Qualcosa e cambiato all'inizio di quest'anno. Gli strumenti AI, che prima producevano solo rumore nelle segnalazioni, hanno iniziato a fornire risultati concreti. Anthropic ha pubblicato un paper che spiega il motivo: questi modelli sono pattern matcher molto potenti. Possono analizzare tutti i bug corretti in passato e trovare dove le stesse correzioni non sono state ancora applicate. Per i progetti open source questo significa un'inondazione di segnalazioni. Curl ha annunciato che prendera una pausa per riprendersi. Il kernel e sommerso, ma il volume e cosi alto che le segnalazioni legittime si perdono nel rumore. I bug trovati con strumenti pubblici sono pubblici C'e un aspetto che molti non considerano. Quando usi un modello pubblico per trovare un bug, quel bug viene considerato pubblico. Il modello vuole soddisfarti, quindi se chiedi di trovare un bug in un'area specifica, lo trova. Ma se un altro utente fa la stessa richiesta, il modello trova lo stesso bug e lo segnala di nuovo. Questo crea problemi con i ricercatori di sicurezza che si aspettano il riconoscimento per le loro scoperte. Linguaggi come Go e Rust hanno gia adottato la politica che i bug trovati da LLM pubblici sono automaticamente pubblici. Il kernel e quasi lì. Ci sono anche preoccupazioni sulla privacy. I dati privati caricati sui modelli pubblici si mescolano con dati pubblici, e questo e stato confermato indipendentemente. Greg raccomanda di caricare solo codice pubblico. Usate i modelli open source, in locale Il consiglio pratico di Greg e semplice: installate modelli open source sul vostro computer e usateli per trovare e correggere bug. Oggi i modelli open source locali riescono a risolvere tra l'80 e il 90% dei problemi in un ambiente chiuso. Le aziende hanno speso miliardi per servizi proprietari quando potevano ottenere risultati simili con modelli gratuiti che girano sui desktop dei loro ingegneri. Un modello locale produce correzioni di cui circa i due terzi o tre quarti sono corrette. Basta rivederle e integrarle. Molte progetti open source hanno gia adottato questo approccio. Trovano e correggono tutti i bug con i modelli open source, e poi scoprono che i modelli proprietari ne trovano solo uno o due in piu. Il valore aggiunto e minimo. Non mandate codice privato online Il messaggio e chiaro: non caricare mai informazioni non pubbliche su servizi esterni. Molte aziende convincono i clienti a condividere dati per il training, ma questi dati possono fuoriuscire. Parlate con i vostri legali e con i vostri regulatori. Greg stesso e soggetto a restrizioni governative su cosa puo e cosa non puo caricare sui siti non controllati. Correggete tutti i bug, non solo i gravi C'e un'altra cosa importante da capire. Questi strumenti sono capaci di concatenare bug minori per creare un exploit completo. Questo e documentato e dimostrato. Quindi la pratica di classificare i bug per gravita e diventata obsoleta. Se un bug e piccolo, non significa che sia innocuo. L'approccio giusto e semplice: correggete tutti i bug. Non perdete tempo a discutere se uno e grave o meno. Correggeteli, testateli, deployateli. Poi mandate le correzioni a monte, ai maintainer. Non vogliete mantenere un fork. Questi strumenti possono anche scrivere test. Greg ha raccontato che un modello open source gli ha scritto un test per Kubernetes che ha dimostrato l'esistenza di un bug e ha verificato la correzione. E solo ingegneria Il punto centrale del discorso di Greg e che non c'e niente di magico in tutto questo. E il momento in cui il debito accumulato da anni di sviluppo software non sufficientemente sicuro sta finalmente tornando a galla. Lo stesso valeva per Y2K e per i fuzzing. La risposta e semplice: fate il lavoro. Correggete i bug, mandate le correzioni a monte, mantenete le vostre dipendenze aggiornate. Usate modelli open source in locale. Non preoccupatevi del modello di domani, concentratevi su quello che potete fare oggi. Ci sono risorse utili. OpenSSF ha pubblicato un documento dettagliato su come gestire la sicurezza del software. Il paper "Weekend at Bernie's" spiega come determinare se le vostre dipendenze sono ancora vive e mantenute. La conclusione di Greg e diretta: non e magia, e solo ingegneria. Fare il lavoro e tutto cio che serve per uscirne.