modelli openai anthropic

La crisi della cyber: perché l’AI preoccupa governi e imprese

La capacità dei modelli di AI di trovare vulnerabilità e accelerare la creazione di exploit rende più urgente ripensare la sicurezza del software. Il punto non è eliminare ogni bug, ma costruire sistemi resilienti, aggiornabili e capaci di limitare i danni anche quando le vulnerabilità emergono

Pubblicato il 20 apr 2026

Claudio Telmon

Information & Cyber Security Advisor” P4I

software microsoft giustizia CSA2 e sovranità digitale Human-Centric Security

Chiedi all'AI

Riassumi questo articolo

Approfondisci con altre fonti

Le recenti notizie sulla capacità di alcuni modelli di AI di scoprire nel software difetti che permettano di violarne la sicurezza, i cosiddetti security bugs, crea comprensibilmente una certa preoccupazione a tutti i livelli, dagli sviluppatori fino ai più alti livelli politici.

L’AI scopre vulnerabilità nel codice: cambia tutto per la sicurezza software

Nel contesto attuale, security bugs vuole dire possibilità di attacchi ampi e di grande impatto ad ogni genere di organizzazione, sia da parte di criminali che da parte di stati sovrani. Questi strumenti di AI avrebbero anche la capacità di scrivere più rapidamente dei programmi che sfruttino materialmente queste vulnerabilità per praticare un attacco (i cosiddetti exploit) e, potenzialmente, di realizzare agenti che effettivamente sfruttino gli exploit rapidamente per attaccare un gran numero di sistemi in modo anche sofisticato. È utile quindi inquadrare bene il problema e ragionare su come affrontarlo in una prospettiva strategica e sistemica, oltre che nell’ottica della gestione del possibile rischio contingente.

Indice degli argomenti

Perché il software resta vulnerabile per natura

Il primo punto è che il software è complesso e contiene errori. Un sistema operativo moderno equivale a miliardi di caratteri, una quantità enorme di testo. Solo che il software è scritto in linguaggi formali in cui un errore, anche solo un punto e virgola fuori posto, può creare un comportamento inatteso e indesiderato del software. Inutile dire che, data la complessità, di questi errori ce ne sono moltissimi. Del resto, lo vediamo tutti i giorni: un rallentamento, un comportamento anomalo occasionale, sono spesso sintomi minori di questi errori. I più evidenti vengono rilevati già in fase di sviluppo del software, molti altri vengono individuati nell’uso quotidiano, ma moltissimi possono rimanere nascosti per anni, perché non creano problemi tali da essere individuati. Il software di qualità, di fatto, non è quello senza errori, è quello che ne ha pochi.

Alcuni di questi errori, che nell’utilizzo quotidiano magari provocano solo un rallentamento, possono essere utilizzati da un attaccante, nelle giuste condizioni, per provocare un comportamento specifico, che causi una violazione della sicurezza: il blocco del programma, l’aggiramento di un controllo, l’accesso a informazioni che dovrebbero essere riservate o, nel peggiore dei casi, quella che si chiama “esecuzione di codice arbitrario”, magari con privilegi elevati. Da decenni, gruppi di persone passano il loro tempo a cercare questi bug, nel migliore dei casi per correggerli, oppure, nel peggiore dei casi, per sfruttarli o rivenderli a chi li vuole sfruttare. Quando vengono trovati e possono essere effettivamente sfruttati, questi bug diventano i famigerati “0-day”: vulnerabilità di sicurezza non ancora note agli sviluppatori del prodotto e al pubblico, e per le quali non sono ancora disponibili delle correzioni.

La complessità del software è tale che, in generale, si fa prima a partire dall’ipotesi che di 0-day nel software ce ne siano sempre, e che tutto stia nella quantità di tempo e competenze da investire nel trovarli. E, per essere chiari, ogni giorno ne vengono trovati a decine[1], anche nei software più diffusi: gli aggiornamenti di sicurezza che ci vengono proposti periodicamente servono proprio per correggerli. È facile capire come i programmi più critici e diffusi (sistemi operativi, piattaforme di virtualizzazione, ecc.) siano quelli più analizzati, ma anche quelli dove le cose più evidenti siano già state trovate e corrette, e dove l’attenzione a scrivere codice non vulnerabile sia maggiore: dopotutto, una vulnerabilità in questi contesti, sul mercato degli 0-day (mercato ormai simile per molti aspetti a quello delle armi) può valere molti soldi.

Dobbiamo poi ricordare che il software non è un prodotto statico: viene continuamente modificato, adattato e “migliorato”, potenzialmente aggiungendo vulnerabilità dove prima non ce n’erano. Per completare il quadro, ricordiamo che esiste anche una enorme quantità di software “minori”, cioè meno diffusi o critici, spesso scritti con minore cura e minori competenze, dove semplicemente nessuno ha mai ritenuto che valesse la pena di cercare con altrettanta attenzione: dopotutto, cercare vulnerabilità è un’attività lunga e, tendenzialmente, tediosa.

Dove l’AI può cambiare la sicurezza del software

Proprio in queste attività lunghe e tediose i tool di AI si trovano perfettamente nel loro: parliamo di analisi di grandi quantità di codice scritto in linguaggi formali, alla ricerca di problemi che vanno dal semplice errore grammaticale, fino a funzioni che dovrebbero effettuare determinate operazioni ed invece ne fanno di leggermente diverse. Come per molti strumenti utilizzati nel settore della sicurezza, possono essere utilizzati in due momenti e con due scopi: in fase di realizzazione e manutenzione del software, per correggere eventuali difetti prima di renderlo disponibile; o successivamente, per trovare appunto degli 0-day, per segnalarli o per sfruttarli. La seconda possibilità è quella che sta mettendo in discussione la possibilità di rendere diffusamente disponibili gli strumenti più avanzati ed efficaci e che chiarisce anche l’interesse, non solo da parte degli sviluppatori di prodotti, ad avere accesso a questi strumenti.

Il rischio operativo: più vulnerabilità da gestire

Una prima preoccupazione che è stata riportata è che gli sviluppatori vengano “sommersi” da vulnerabilità da correggere. Il problema in realtà c’è già da tempo[2], e nella forma peggiore, ovvero di report di bassa qualità e spesso riferibili a falsi positivi. In questo senso, una reportistica su vere vulnerabilità gravi può rappresentare un miglioramento. Il problema potrà essere il tempo necessario per produrre un numero maggiore di aggiornamenti adeguatamente testati, magari mentre le vulnerabilità vengono attivamente sfruttate. Ma se le vulnerabilità vengono sfruttate, non ci sono molte alternative a produrre le correzioni il più velocemente possibile. Più complesso il tema per i progetti open source, che non hanno in generale la possibilità di aumentare le risorse da dedicare alle attività di correzione. Il problema maggiore sarà però comunque dal lato delle aziende utente, quelle che gli aggiornamenti li devono installare, e i cui sistemi possono essere nel frattempo compromessi.

Il fronte più esposto dei software “minori”

C’è un ambito però che potrebbe subire un impatto altrettanto importante, ed è quello dei software “minori”: quelli che finora non sono stati analizzati con particolare attenzione, se non per caso, perché sono meno interessanti per i potenziali attaccanti. Software che con i tool in discussione potrebbe divenire più semplice, veloce, economico e quindi conveniente analizzare alla ricerca di vulnerabilità. E software che potrebbero non avere il vantaggio di partecipare a programmi di supporto come Project Glasswing.

Perché gli 0-day diventeranno la norma

A questo punto, è necessaria una considerazione, e cioè che questa capacità di trovare 0-day diventerà rapidamente la norma. Inoltre, dato che i diversi gruppi di cybercrime hanno spesso legami più o meno stretti con i governi, ci possiamo aspettare comunque un aumento importante degli 0-day che saranno attivamente sfruttati anche da questi soggetti. È anche probabile che, per fare un esempio, gli strumenti cinesi che sicuramente vengono sviluppati, finiscano per seguire logiche almeno un po’ diverse, e quindi finiscano per trovare comunque degli 0-day che non sono stati rilevati dai tool statunitensi, e viceversa. Dopotutto, l’ipotesi è che ci sia sempre un certo numero di 0-day non ancora scoperti, e al momento è difficile ipotizzare che anche gli strumenti più avanzati siano efficaci al 100% in questa ricerca, producendo un mitologico software senza vulnerabilità.

Sicurezza del software e velocità di risposta delle aziende

I fattori da considerare sono tanti, ma possiamo ipotizzare che le aziende si troveranno quindi a vivere in un contesto con più 0-day, trovati in più prodotti, (ma comunque anche in quelli più diffusi e critici), sfruttati più rapidamente e in modo più diffuso. Quali potranno essere le conseguenze? Se guardiamo ai casi storici, come ad esempio quello di log4j nel 2021[3], o il famoso Heartbleed di openSSL nel 2014[4], vediamo che, seppure l’impatto sia stato rilevante, ha fatto molta differenza la capacità delle aziende di aggiornare il più rapidamente possibile i propri sistemi, attività che comunque hanno richiesto tempi significativi. La capacità di realizzare malware di ancora più rapida e ampia diffusione che sfrutti immediatamente queste vulnerabilità, potrebbe quindi risultare anche di maggiore impatto che avere un gran numero di 0-day a disposizione.

I processi di aggiornamento dei sistemi dovranno diventare necessariamente più veloci: sapere cosa esattamente si abbia installato, non solo come prodotti, ma anche come componenti e versioni, potrebbe diventare un fattore decisivo. E dato che sempre più spesso le aziende esternalizzano buona parte dei propri servizi ICT, il controllo sui propri fornitori diventerà fondamentale, anche in termini di capacità di valutarne l’adeguatezza in termini di gestione delle proprie vulnerabilità.

Il mercato grigio degli 0-day e gli usi mirati

Questo, però, riguarda gli scenari di vulnerabilità sfruttate in modo pubblico e diffuso. Ci potrà essere, contestualmente, un aumento degli 0-day resi disponibili in quel mercato grigio dal quale si approvvigionano anche, fra gli altri, gli stati sovrani ed i relativi eserciti, servizi segreti e forze dell’ordine. Questi 0-day potranno essere sfruttati in modo più mirato e quindi essere rilevati più tardi, o addirittura potrebbero non essere sfruttati ma essere mantenuti in un “arsenale” da utilizzare in situazioni di conflitto. In questo ambito, possono essere particolarmente critici quei software applicativi o comunque “secondari” per usi verticali, che magari non sono oggetto di grande attenzione, ma la cui compromissione potrebbe comportare impatti importanti su settori specifici.

Una lezione storica: da sendmail a postfix

Come si può affrontare il problema in una prospettiva di più lungo respiro? Vale la pena di considerare a questo proposito uno dei casi più “storici” del settore, ovvero sendmail vs. postfix. Siamo nel 1997. Sendmail è “il” programma per la gestione della posta elettronica, ed è il principale riferimento da ormai più di dieci anni. Quasi ogni organizzazione che gestisca la propria posta elettronica (cioè, quasi tutte quelle che allora usavano già Internet) ha la propria installazione di sendmail. Sendmail, però, è anche un incubo dal punto di vista della sicurezza: un grosso (per allora) programma monolitico eseguito con privilegi elevati, cresciuto su sé stesso con l’aggiunta di funzionalità in modo poco strutturato. Sendmail ha una quantità di vulnerabilità impressionante, e se un’installazione non risulta vulnerabile, si può essere tranquilli che qualcosa verrà fuori il mese successivo.

Nel 1997 Wietse Venema[5], uno dei guru della sicurezza di allora, decide che è tempo di affrontare il problema, e sviluppare un’alternativa a sendmail, progettata però con un’architettura pensata per la sicurezza. Nasce così postfix[6], realizzato con un’architettura modulare che ricorda le logiche dei microservizi attuali. Ogni modulo fa poche cose, ha i permessi strettamente necessari per farle (cioè, molto pochi) e verifica cosa gli passano gli altri moduli, dei quali non si fida, creando così anche un sistema fortemente resiliente a possibili vulnerabilità del singolo modulo. Come effetto collaterale di questa architettura parallela, è anche estremamente efficiente. Il risultato: le prime vulnerabilità significative di postfix vengono trovate quasi dieci anni più tardi, vulnerabilità che comunque incidono sul servizio e non sul sistema che lo ospita.

La sicurezza del software nasce da architetture resilienti

Cosa impariamo da quel caso? La base della sicurezza non è l’assenza di errori nei programmi: è la capacità di disegnare programmi, sistemi e reti intrinsecamente resilienti a questi errori, che diventano complessi o impossibili da sfruttare, e riducendone l’impatto. C’è una gran quantità di concetti che sono arcinoti: da ridondanza a difesa in profondità, da segmentazione a privilegio minimo, sono concetti che esistevano già ai tempi di Wietse Venema e anche prima. Alcuni adesso si ripresentano in vesti un po’ diverse (es. zero trust) ma l’obiettivo è sempre di limitare la possibilità di compromettere un componente vulnerabile, o di ridurre le conseguenze di una compromissione.

C’è anche un altro concetto, più specifico per sistemi e applicazioni, e che risale allo stesso periodo, ed è quello di Trusted Computing Base (TCB): l’insieme dei (pochi, piccoli e semplici) componenti hardware e software che sono critici per la sicurezza di un sistema ben disegnato, dove, per contro, quello che non è nella TCB non è critico, nel senso che i suoi difetti non permettono di acquisire maggiori privilegi rispetto a quelli già disponibili. Perché il problema più grosso che deriva dagli 0-day non è tanto la compromissione del singolo applicativo, quanto la capacità poi di ampliare la portata dell’attacco con i cosiddetti movimenti laterali, fino a compromettere l’intero sistema informativo dell’organizzazione. Questo non viene fatto sfruttando uno 0-day ad ogni passaggio, ma sfruttando debolezze architetturali e di gestione.

Il concetto di TCB è utilizzato ad esempio nel contesto delle certificazioni di sicurezza come i Common Criteria, sui quali si basa anche EUCC[7], lo schema europeo di certificazione per i prodotti più critici. Tutto questo però è ancora molto lontano dalle pratiche di buona parte delle organizzazioni. Eppure, se questi rischi sono reali e possono compromettere seriamente la capacità di operare di un’organizzazione, allora è necessario tenerne conto nelle proprie valutazioni di rischio aziendale, agendo però concretamente, e non semplicemente con qualche documento formale, scritto magari per soddisfare un requisito normativo.

La partita europea tra resilienza e sovranità digitale

Da un punto di vista strategico, potrebbe essere opportuno per l’Europa supportare lo sviluppo componenti che possano costituire delle TCB per i principali framework utilizzati in contesti critici, sufficientemente testate, che possa essere una base per lo sviluppo di prodotti affidabili dal punto di vista della cybersecurity, prevedendo anzi che i prodotti sviluppati in una prospettiva di sovranità digitale rispettino non tanto generici requisiti di “assenza di vulnerabilità sfruttabili”, di discutibile efficacia nella prospettiva che si presenta, ma più specificamente di disegno architetturale resiliente ed in grado di rilevare e segnalare eventuali anomalie che possano indicare un tentativo di compromissione. In questo, il supporto a progetti open source, che sembra essere una via preferenziale attualmente indicata, può essere d’aiuto. Ma questo vuole dire supportare economicamente questi progetti in modo importante, e non sperare semplicemente di avere soluzioni “gratuite” ai problemi di dipendenza dai grossi vendor esteri. L’azione di miglioramento della resilienza agli incidenti di cybersecurity non si può ridurre a requisiti normativi, ma deve essere affiancata da azioni concrete in termini di modelli e di supporto alla loro realizzazione.

Il precedente di SATAN e la logica dei tool dual-use

Come ultima nota, un ulteriore aneddoto su Wietse Venema. Oltre che per postfix, è noto anche per un altro strumento di sicurezza: nel 1995, insieme a Dan Farmer ha sviluppato SATAN[8], che è l’antesignano di quelli che adesso sono i vulnerability scanner. Fino ad allora, la verifica di vulnerabilità era un’attività principalmente svolta manualmente, vulnerabilità per vulnerabilità. SATAN, ampiamente pubblicizzato prima del suo rilascio, era il primo tool di scripting che permetteva di automatizzare queste verifiche. Prima del rilascio, ci furono previsioni catastrofiche su quello che sarebbe successo grazie a questa automazione, che avrebbe reso tutto molto più veloce, e avrebbe consentito anche a persone meno capaci di testare vulnerabilità in modo automatico su un gran numero di sistemi. Il nome provocatorio del tool e il suo logo non aiutarono, e ci fu chi propose che ne venisse vietata la diffusione. Il giorno del rilascio, quello che successe fu… niente: dove c’era veramente interesse a violare i sistemi, in effetti, i vecchi sistemi manuali, per quanto meno efficienti, erano più che sufficienti per trovare i varchi necessari.

Per contro, successivamente lo sviluppo di strumenti di vulnerability scanning, come Nessus e i tanti altri strumenti che seguirono, cambiarono radicalmente la capacità delle aziende di proteggersi da attacchi che fino ad allora si praticavano con facilità. Si era, e si è tuttora, in una situazione di forte asimmetria: difendersi è difficile e costoso, praticare attacchi è semplice ed economico, e basta avere successo una volta. In media e sul lungo termine, la disponibilità di strumenti dual-use è molto più facile che sia a vantaggio di chi vuole proteggersi che di chi vuole attaccare, perché a quest’ultimo già adesso non mancano le possibilità.