Di fronte a migliaia di vulnerabilità individuate dall’AI, chi si occupa di cybersecurity si trova davanti ad un paradosso: la macchina scopre problemi più in fretta di quanto un’organizzazione riesca a gestirli. La sfida non è più trovare le falle, ma decidere quali contano, correggerle e chiudere il ciclo prima che lo faccia un attaccante.
Indice degli argomenti
AI e gestione delle vulnerabilità: lo sviluppo accelera il rischio
Il modo in cui le aziende costruiscono software sta attraversando una trasformazione profonda, spesso ancora poco visibile. È iniziata con i coding assistant, è esplosa con la Generative AI e sta entrando ora in una fase più delicata: quella in cui l’intelligenza artificiale non si limita ad aiutare un programmatore a scrivere codice, ma analizza autonomamente intere librerie di codice di programmazione, formula ipotesi sulle loro debolezze, le verifica e produce una dimostrazione del problema (PoC, Proof of Concept) che può essere utilizzata tanto per risolverlo che per utilizzarlo per condurre attacchi informatici.
Il vantaggio per le imprese è evidente: scrivere codice costa meno tempo, modificare le applicazioni è più rapido, i test si automatizzano e i cicli di rilascio si accorciano. C’è però una seconda faccia della stessa rivoluzione: se il software viene prodotto più rapidamente, anche le sue vulnerabilità vengono introdotte, individuate e potenzialmente sfruttate altrettanto velocemente.
Non stiamo parlando del fatto che il codice generato dall’intelligenza artificiale sia necessariamente più insicuro di quello scritto da un essere umano. Il problema è un altro: la velocità della generazione del software sta aumentando molto più rapidamente della capacità delle organizzazioni di verificare tutto ciò che viene prodotto.
Una ricerca pubblicata nel 2026 su Empirical Software Engineering ha analizzato 2.315 snippet (frammenti) di codice generati con ChatGPT, individuando 56 vulnerabilità in soli 48 file. Lo stesso studio mostra però che i modelli più recenti riescono a identificare il 75–80% di quelle vulnerabilità ed in molti casi propongono correzioni efficaci.
È la contraddizione che da tempo accompagna, e lo stesso farà sempre di più in futuro, la cybersecurity nei prossimi anni: l’AI è insieme parte del problema e parte della soluzione. E la differenza non la farà tanto la qualità di questo o quel modello AI, quanto il modo in cui i modelli “parteciperanno” al ciclo di vita del software e dei sistemi informatici.
Mythos e l’AI che ragiona sulle vulnerabilità del codice
Claude Mythos è il caso che ha reso evidente quanto in fretta stia cambiando lo scenario. Nell’aprile 2026 Anthropic ha presentato un sistema che porta la ricerca di vulnerabilità su un piano diverso rispetto agli strumenti automatici tradizionali e ai modelli AI precedenti: non un software che controlla il codice alla ricerca di pattern conosciuti, ma un agente in grado di formulare ipotesi, eseguire il software, verificare le proprie predizioni e iterare l’analisi fino a produrre proof-of-concept utilizzabili anche per violare la sicurezza delle informazioni.
La differenza sostanziale rispetto agli strumenti del passato è che oltre a rilevare un problema, un agente AI oggi prova a capire se quel problema, eventualmente in combinazione con altri, possa essere sfruttato per generare un attacco complesso.
Uno degli esempi più eclatanti riguarda il codice del protocollo TCP di OpenBSD. Un difetto era rimasto nascosto per 27 anni in uno dei codici più sottoposti a revisione al mondo, perché una determinata condizione era considerata matematicamente impossibile e, proprio per questo, nessuno l’aveva protetta. Mythos ha messo in discussione quell’assunzione e ha individuato il meccanismo che “rendeva possibile l’impossibile”.
Assunzioni e precondizioni sotto esame
Per chi fa threat modeling la lezione è concreta: come detto precedentemente, gli strumenti di analisi tradizionali (e in questa categoria qui facciamo rientrare anche tutte le soluzioni che fino a pochi mesi fa potevamo considerare innovative perché dotate di componenti basati su machine learning e strumenti di AI di precedente generazione) ricercano pattern conosciuti o prevedibili; oggi l’AI può invece essere usata per mettere in discussione le ipotesi (assunzioni, precondizioni, vincoli) su cui si basa tanto la progettazione che l’implementazione di un sistema informatico, aprendo una nuova superficie di rischio: ogni “questo non può succedere” che non viene verificato, può diventare una vulnerabilità.
La gestione delle vulnerabilità davanti al salto di scala dell’AI
La sfida per la cybersecurity e, più in generale, della digitalizzazione, paradossalmente oggi deriva proprio dall’avere a disposizione strumenti enormemente più potenti del passato per rilevare e comprendere le vulnerabilità dei sistemi informatici.
I primi risultati dell’utilizzo delle AI più recenti, per la discovery delle vulnerabilità, rendono il fenomeno tangibile: Mozilla ha applicato una versione preliminare di Mythos a Firefox individuando 271 vulnerabilità, 180 delle quali ad alta severità; Cloudflare ha riportato circa 2.000 finding sui propri sistemi critici; le organizzazioni coinvolte nel Project Glasswing hanno identificato complessivamente oltre 10.000 vulnerabilità high o critical.
Numeri e tempi del collo di bottiglia operativo
Nell’Operational Summary del primo semestre 2026 l’Agenzia per la Cybersicurezza Nazionale ha censito 37.032 nuove CVE pubblicate, il 54% in più rispetto allo stesso periodo del 2025: di queste, 5.722 disponevano già di un Proof of Concept e per 69 risultava uno sfruttamento attivo. Ed è la stessa Agenzia ad attribuire l’incremento al crescente impiego dei modelli AI di frontiera, che stanno riducendo i tempi di analisi del codice, di vulnerability research e di generazione di PoC.
Ne consegue che, a breve, i team di sviluppo software di tutte le aziende si troveranno a gestire un numero di vulnerabilità 10 o 100 volte superiore rispetto a quanto era possibile rilevare fino ad oggi: un problema di natura organizzativa prima ancora che tecnica.
Ogni vulnerabilità va infatti compresa, validata, classificata, prioritizzata, assegnata a qualcuno, corretta, sottoposta a test di regressione e portata sui sistemi di produzione, il tutto mentre i team continuano a sviluppare nuove funzionalità e a rispettare le scadenze di business.
Allo stesso modo, riguardo a tutte le organizzazioni che utilizzano servizi e prodotti software, fino ad oggi le loro strutture IT hanno gestito i processi di vulnerability management al loro limite operativo, con evidente difficoltà in termini di efficacia e tempestività di intervento.
Ciò è dimostrato dai dati: il Data Breach Investigations Report 2026 di Verizon indica che lo sfruttamento delle vulnerabilità è il primo vettore di accesso iniziale noto, presente nel 31% dei breach; nello stesso periodo il tempo medio per risolvere completamente le vulnerabilità critiche è peggiorato da 32 a 43 giorni, e delle vulnerabilità con sfruttamento attivo noto (catalogo KEV di CISA) solo il 26% risulta completamente rimediato.
Sul fronte opposto, Mandiant ha misurato che il tempo mediano tra l’accesso iniziale a una rete e la cessione di quell’accesso a un altro gruppo criminale è crollato dalle oltre otto ore del 2022 a 22 secondi nel 2025.
Se la capacità di discovery cresce alla velocità delle macchine, quella di remediation continua quindi a dipendere da persone e processi oggi ancora troppo complessi.
La risposta istintiva a questo scenario sarebbe quella di dotarsi di nuove tecnologie: un nuovo scanner, un nuovo sistema di detection, e così via… E’ una risposta semplice, e come tale non può essere risolutiva di un problema complesso. Se le vulnerabilità crescono di numero e vengono scoperte più in fretta, aggiungere capacità di discovery senza intervenire sul resto del processo e sull’approccio operativo serve soltanto a gonfiare il backlog.
Dal punteggio al rischio nella gestione delle vulnerabilità
Per anni il punteggio CVSS è stato lo strumento principale per classificare la gravità di una vulnerabilità. Questa scala di valutazione, incentrata sulla natura intrinseca della vulnerabiltà e priva di riferimenti rispetto allo specifico contesto di utilizzo in ogni organizzazione, non è più idonea per definire le priorità di intervento.
Le tecniche di attacco individuate dalle moderne AI possono essere infatti costituite da catene, anche molto lunghe, di vulnerabilità fino ad oggi ritenute scarsamente critiche le quali, per questo motivo, sono risolte in tempi lunghissimi in favore delle problematiche ritenute di maggiore rilievo.
Pertanto, quando i finding passano da centinaia a migliaia, l’obiettivo della classificazione deve cambiare per aiutare a individuare le problematiche che possono rappresentare il rischio maggiore, tenendo conto di aspetti che fino a ieri erano scarsamente considerati dai più: chi può raggiungere il sistema, quanto è esposto e quale percorso apre verso un asset realmente critico.
La conseguenza è un cambio di prospettiva che, nella nostra esperienza, definisce il primo passo che un’organizzazione deve compiere per stare al passo delle nuove sfide: passare dalla gestione della vulnerabilità alla gestione del rischio associato alla vulnerabilità.
Secure testing continuo contro le vulnerabilità generate dall’AI
Il tradizionale penetration testing eseguito una volta all’anno, o il security assessment a ridosso di un rilascio, non reggono un ambiente in cui il codice cambia continuamente e le vulnerabilità emergono a ritmi crescenti. La sicurezza deve entrare nella pipeline: SAST e SCA su codice e dipendenze, SBOM, DAST sugli ambienti di test, controlli sull’infrastructure as code e sulle configurazioni diventano parte di un processo continuo.
Validazione e security regression
L’automazione, però, non pensa da attaccante. Uno scanner individua un’anomalia, ma raramente comprende la logica funzionale che rende quella vulnerabilità realmente sfruttabile. Per questo restano indispensabili gli abuse case ed i misuse case, attività offensive mirate e soprattutto la validazione della sfruttabilità nel contesto specifico: un aspetto che, va detto, quasi nessuno presidia.
E c’è un passaggio che vediamo sottovalutare quasi ovunque: la correzione stessa va testata, perché quando la pressione aumenta una patch può risolvere una vulnerabilità e introdurne un’altra. La security regression diventa parte integrante del ciclo.
In sintesi, la sicurezza smette di essere una sequenza lineare – sviluppo, test, rilascio, sicurezza – e diventa un loop: sviluppo, detection, validazione, remediation, test, rilascio, nuovo monitoraggio.
SSDLC e gestione delle vulnerabilità nell’esperienza sul campo
Il Software Development Life Cycle deve quindi cambiare natura: da verifica concentrata alla fine dello sviluppo a meccanismo continuo, integrato nelle pipeline e collegato direttamente ai processi di remediation. Il codice generato dall’AI, in particolare, va trattato come codice che richiede verifica indipendente, non perché sia necessariamente peggiore, ma perché arriva a una velocità che rende impraticabile affidarsi alla sola revisione manuale.
Servono review obbligatorie, gate bloccanti sulle pipeline principali, controlli SAST e SCA, SBOM aggiornate e una separazione netta tra chi genera il codice e chi ne verifica la sicurezza. L’AI può accelerare la produzione, ma non deve accelerare automaticamente il passaggio in produzione.
In una serie di casi reali che abbiamo seguito presso grandi organizzazioni, l’introduzione di scansioni automatiche nelle pipeline ha avuto come prime effetto l’emersione in poche settimane di un debito di sicurezza accumulato nel corso degli anni. Il dato più interessante non è però la dimensione, ma quello che è successo dopo l’introduzione dei controlli: le vulnerabilità hanno iniziato a emergere rapidamente, e proprio questo ha reso più evidente che individuarle di nuove è diventato più facile che risolverle.
Pipeline, gate e policy di remediation
La risposta è stata portare i controlli di sicurezza dentro il processo di sviluppo senza trasformarli in un freno al lavoro quotidiano: i security check sono stati eseguiti in modo asincrono sui feature branch, mentre sulle merge request verso il progetto principale sono stati introdotti gate bloccanti. I finding sono stati portati nel sistema di ticketing e associati a policy di remediation differenziate per severità e origine.
Sono esempi che mostrano innazitutto che una policy che non modifica il comportamento della pipeline di lavoro, rischia di rimanere soltanto una policy; soprattutto, è l’evidenza che, in un contesto dominato dalle attività di sviluppo software, la sicurezza diventa effettiva quando entra nei meccanismi con cui l’organizzazione decide se un software può essere rilasciato oppure no.
L’AI difensiva nella gestione dei finding
Se è vero che l’AI moltiplica le vulnerabilità da gestire, la risposta non può essere tenerla fuori dai processi di sicurezza. L’intelligenza artificiale può essere utilizzata anche come strumento difensivo, nel triage dei finding, nella generazione di test, nell’analisi del codice, nella proposta di remediation, perché riduce il tempo necessario a trasformare un finding in un’azione. Questa è una condizione necessaria perché gli interventi sul processo siano realmente agibili, alla velocità delle macchine.
Ovviamente, ciò deve avvenire solo a due condizioni, non negoziabili: la supervisione umana e la segregazione dei compiti. Il modello che genera il codice non può essere l’unico soggetto incaricato di certificarne la sicurezza. È lo stesso principio che applichiamo da sempre alle persone: chi produce una modifica non dovrebbe essere l’unico responsabile della sua approvazione.
Vulnerabilità e service management lungo il ciclo di vita
Un altro errore di prospettiva da evitare: pensare che l’SSDLC finisca con il go-live. Una vulnerabilità scoperta in esercizio deve entrare nei processi operativi (incident management, change management, patching, gestione dei fornitori, monitoraggio delle CVE, …) e con la discovery accelerata anche il service management dovrà cambiare ritmo: finestre di patching più frequenti, processi di hotfix formalizzati, fornitori vincolati a tempi di remediation coerenti con la criticità delle vulnerabilità.
È presente una conseguenza più radicale, di cui si parla pochissimo: non tutte le vulnerabilità potranno essere risolte. Cosa succede quando il software non è più supportato, quando non esiste una patch, quando il firmware non può essere aggiornato o la mitigazione non riduce il rischio a un livello accettabile?
A quel punto la domanda smette di essere “come lo aggiorniamo?” e diventa “come diversamente proteggere questo asset?” (e qui, di nuovo, l’AI può essere uno strumento per trovare nuove modalità di protezione), fino a “possiamo permetterci di continuare a usarlo?”. La sicurezza entra così nel territorio dell’IT Asset Disposition: decommissioning pianificato, ritiro sicuro, protezione e distruzione dei dati, chain of custody.
La fine del ciclo di vita di un asset è sempre più influenzata da aspetti di rischio di cybersecurity.
Il costo della remediation nell’era dell’AI
Dietro questa trasformazione non c’è soltanto una questione tecnica: è presente un tema economico. Il Cost of a Data Breach Report 2026 di IBM quantifica il costo medio globale di una violazione dei dati in 4,99 milioni di dollari, in crescita del 12% sull’anno precedente; le organizzazioni che utilizzano in modo esteso AI e automazione nella sicurezza registrano invece un costo medio inferiore di circa 1,93 milioni. L’AI non elimina il rischio: il suo valore sta nella possibilità di comprimere la distanza tra quattro momenti decisivi: la vulnerabilità viene introdotta, viene scoperta, viene validata, viene corretta. Più quella distanza si accorcia, meno tempo resta all’attaccante.
Regolatori e sicurezza del software con AI
Che il tema sia uscito definitivamente dal perimetro dei tecnici lo dimostrano i regolatori. Con la lettera del 7 luglio 2026 la Banca Centrale Europea ha chiesto alle principali banche europee piani d’azione concreti contro le minacce cyber abilitate dai modelli AI di frontiera: protezione degli asset esposti, sicurezza del software open source e di terze parti, rafforzamento della detection, utilizzo dell’AI difensiva sotto supervisione umana, maggiore responsabilizzazione dei fornitori ICT. È un passaggio culturale prima ancora che normativo: la cybersecurity non è più una questione di strumenti acquistati dal dipartimento IT, ma di governance, budget, competenze, responsabilità e continuità operativa.
I framework per lo sviluppo sicuro con AI
Anche i framework vanno nella stessa direzione, e chi deve mettere a terra questi principi non parte da zero. ENISA ha pubblicato a luglio 2026 la versione definitiva del Secure by Design and Default Playbook, con checklist, evidenze minime e criteri di release gate innestabili direttamente nelle pipeline; il NIST ha affiancato all’SSDF (Secure Software Development Framework) un profilo dedicato allo sviluppo con AI generativa (SP 800-218A); OWASP presidia il fronte applicativo con la Top 10 for LLM Applications e la AI Testing Guide.
Dalla discovery alla remediation: la nuova maturità cyber
L’effetto Mythos, alla fine, non riguarda soltanto Mythos: riguarda il salto di scala che l’intelligenza artificiale sta imprimendo alla cybersecurity. Per decenni la capacità di trovare vulnerabilità è stata una risorsa scarsa, servivano ricercatori specializzati, molto tempo, conoscenze difficili da replicare.
Quella scarsità sta finendo: una macchina può analizzare quantità di codice che nessun team umano esaminerebbe manualmente, ripetere l’operazione senza sosta, formulare ipotesi e testarle.
Il lavoro umano non scompare: si sposta. Le persone smettono progressivamente di essere gli esecutori di ogni controllo e diventano i supervisori del rischio, decidono cosa bloccare, cosa correggere, cosa accettare temporaneamente e, in alcuni casi, cosa dismettere.
Cambia anche la definizione di maturità della cybersecurity. Dire “abbiamo trovato 10.000 vulnerabilità” non significa più nulla. La domanda giusta è: quante ne abbiamo comprese, quante prioritizzate, quante corrette, e in quanto tempo.
La gestione delle vulnerabilità si misura nel tempo di risposta
Se scoprire una vulnerabilità costerà sempre meno, correggerla costa come prima: tempo, persone, decisioni.
È questo il paradosso che l’intelligenza artificiale ha portato al centro della cybersecurity, e non si risolve rallentando i processi di sviluppo, né moltiplicando all’infinito gli strumenti di analisi. Si risolve costruendo un ciclo di vita diverso: un SSDLC in cui la sicurezza entra già nei requisiti e nell’architettura; in cui i controlli sono integrati nella pipeline e i gate possono bloccare un rilascio quando il rischio supera la soglia; in cui la priorità si stabilisce sul contesto e non soltanto su un punteggio; in cui l’AI viene usata anche per difendere, ma sotto supervisione umana; e in cui il service management presidia il software fino alla dismissione.
Perché il vero indicatore della sicurezza di un’organizzazione non sarà più la sua capacità di scoprire una vulnerabilità. Sarà la sua capacità di chiudere il ciclo. Prima che lo faccia qualcun altro.
Partecipa alla community