Il record CVE di MITRE mostra che l'AI scopre falle di sicurezza più velocemente di quanto i team riescano a gestirle

MITRE ha registrato il record di 48.244 vulnerabilità nel 2025, e il record CVE di MITRE ha continuato a crescere nella prima metà del 2026. La ricerca assistita dall'AI ha contribuito a individuare le falle più rapidamente, ma il volume delle disclosure sta ora superando la capacità di molti team di sicurezza di verificare, prioritizzare e correggere ogni segnalazione.

Entro giugno 2026 erano state registrate oltre 35.000 vulnerabilità, secondo i totali riportati. Ciò rappresentava già quasi tre quarti del precedente record annuale. La crescita non dimostra semplicemente che gli sviluppatori abbiano improvvisamente iniziato a scrivere software molto peggiore.

Il cambiamento più profondo riguarda l'individuazione. I sistemi di AI possono ispezionare grandi basi di codice, confrontare versioni software, proporre percorsi di attacco e rilevare comportamenti sospetti a una scala che i ricercatori umani non possono eguagliare. Anthropic, OpenAI, Google, Microsoft e i fornitori di sicurezza hanno tutti investito in modelli o programmi di ricerca incentrati sulla cyber security.

Questo crea una tensione evidente. Individuare prima le debolezze nascoste dà ai difensori il tempo di eliminarle. Tuttavia, ogni nuova disclosure entra anche in un sistema già sovraccarico di manutentori, coordinatori, team di sicurezza e proprietari di asset.

Il risultato non è una semplice esplosione degli attacchi riusciti. Le evidenze disponibili mostrano un'impennata delle disclosure, un aumento più contenuto dello sfruttamento osservato e un divario operativo sempre più ampio tra i due.

Il record CVE di MITRE cresce più rapidamente delle previsioni

Il cambiamento decisivo non è una singola vulnerabilità spettacolare. È l'accelerazione costante dell'intero sistema di disclosure.

Un identificatore Common Vulnerabilities and Exposures, o CVE, è un'etichetta standardizzata per una falla di sicurezza divulgata pubblicamente. I CVE consentono a fornitori, ricercatori, governi e strumenti di sicurezza di riferirsi allo stesso problema senza affidarsi a nomi incoerenti.

Il numero di casi registrati è rimasto nell'ordine delle decine di migliaia all'anno tra il 2017 e il 2020. Ha raggiunto 20.161 nel 2021, per poi salire a 40.077 nel 2024 e a 48.244 nel 2025. Entro giugno 2026 ne erano già stati registrati oltre 35.000.

Il Forum of Incident Response and Security Teams, noto come FIRST, prevedeva un altro record prima dell'inizio dell'anno. La sua previsione di febbraio collocava la stima mediana per il 2026 a 59.427 CVE.

Le disclosure effettive hanno rapidamente superato quella traiettoria. La previsione di metà anno di FIRST ha rilevato che il volume di pubblicazione fino ad aprile era superiore del 46,3% rispetto alla proiezione precedente. L'organizzazione ha innalzato la sua stima per l'intero anno a circa 66.000 CVE.

Questa rivalutazione ha identificato 6.420 CVE in più rispetto a quanto previsto dal modello iniziale fino ad aprile. Ha attribuito la differenza a diverse forze, tra cui l'individuazione assistita dall'AI, una segnalazione più ampia e cambiamenti all'interno dell'ecosistema CVE.

Il volume delle GitHub Security Advisory era aumentato del 449% su base annua. L'attività della CNA of Last Resort di VulnCheck era salita del 3.119%, mentre l'organizzazione elaborava un vasto arretrato di vulnerabilità prive di un'altra autorità di assegnazione.

Questi dettagli sono importanti perché il record CVE di MITRE non misura un'unica cosa. Combina nuova ricerca, segnalazioni più vecchie che entrano nel sistema, cicli di disclosure dei fornitori, copertura ampliata e cambiamenti amministrativi. Considerare ogni CVE aggiuntivo come prova di software appena diventato insicuro significherebbe interpretare erroneamente i dati.

Anche il numero di prodotti software rappresentati nel monitoraggio delle vulnerabilità è aumentato in modo sostanziale. I ricercatori di sicurezza ora esaminano più applicazioni, dispositivi, librerie, servizi cloud e componenti open source. Una migliore visibilità rivela naturalmente falle che in precedenza restavano prive di documentazione.

Le pubblicazioni di grandi fornitori possono produrre picchi mensili improvvisi. Un'azienda potrebbe divulgare insieme centinaia di problemi correlati dopo aver completato una revisione coordinata. Il grafico risultante riflette il calendario di pubblicazione oltre al tasso effettivo di individuazione.

Tuttavia, queste precisazioni non cancellano il cambiamento. L'AI sta ampliando la quantità di codice che i ricercatori possono esaminare e riducendo il tempo necessario per identificare debolezze plausibili. Questa nuova capacità arriva mentre l'infrastruttura di segnalazione affronta già un carico di lavoro crescente.

Il record misura quindi sia progresso sia pressione. Più falle diventano visibili prima che gli aggressori le trovino, ma ogni segnalazione valida crea lavoro per manutentori e difensori.

L'individuazione delle vulnerabilità con l'AI ha cambiato la scala della ricerca di bug

L'individuazione delle vulnerabilità con l'AI trasforma la revisione del codice da un'attività manuale scarsa in un processo che può essere eseguito ripetutamente su enormi patrimoni software.

La ricerca tradizionale sulle vulnerabilità richiede specialisti in grado di comprendere un'applicazione, identificare comportamenti pericolosi, costruire test e confermare se un attacco sia praticabile. Gli scanner automatizzati aiutano, ma spesso si basano su schemi noti e producono falsi positivi.

I modelli AI di frontiera aggiungono un ulteriore livello. Possono ragionare tra file diversi, tracciare i dati attraverso un programma, confrontare versioni corrette e non corrette, generare casi di test e suggerire combinazioni di debolezze. I ricercatori umani devono ancora validare le segnalazioni rilevanti, ma la fase di ricerca può coprire più terreno.

Claude Mythos Preview di Anthropic è diventato un esempio di rilievo nel 2026. L'azienda ha dichiarato di aver iniziato a usare uno snapshot iniziale del modello a febbraio per esaminare software open source. Società di sicurezza esterne hanno poi contribuito a classificare, validare e segnalare le vulnerabilità ad alta gravità o critiche.

La dashboard pubblica delle disclosure di Anthropic registrava 462 identificatori emessi in uno snapshot di agosto. Includevano 177 record CVE e 285 GitHub Security Advisories, sebbene una singola segnalazione potesse ricevere entrambi gli identificatori.

Le affermazioni più ampie erano molto maggiori. Anthropic ha dichiarato che Project Glasswing aveva individuato oltre 10.000 vulnerabilità ad alta gravità o critiche. I record pubblici coprivano solo una parte di quel totale dichiarato, impedendo ai ricercatori di valutare la maggior parte delle singole segnalazioni.

Epoch AI ha esaminato i dati sulle disclosure di 21 grandi organizzazioni tecnologiche, tra cui Microsoft, Google, Apple, Oracle, Cisco, Linux, Mozilla e Apache. I suoi dati sulla gravità mostravano circa 1.550 CVE ad alta gravità e critici pubblicati a giugno.

Quel totale di giugno superava di oltre tre volte il record mensile osservato prima che Anthropic annunciasse Mythos Preview. Luglio ha raggiunto circa 2.500 disclosure ad alta gravità e critiche, circa cinque volte il record precedente.

Epoch ha avvertito che le cifre coprono le disclosure pubbliche, non ogni falla scoperta privatamente. Ha inoltre osservato che le valutazioni di gravità cambiano man mano che i record ricevono nuove informazioni. I totali mensili storici possono variare dopo che gli analisti rivedono i singoli CVE.

La tempistica sostiene comunque la conclusione che i modelli di frontiera siano diventati strumenti di ricerca significativi. I programmi di AI hanno iniziato a operare accanto ad audit interni ampliati, nuove iniziative di disclosure e maggiori investimenti da parte dei grandi fornitori.

Google ha descritto il proprio recente volume di scoperte come senza precedenti per scala e velocità. I dati dei fornitori indicavano che molte falle appena segnalate provenivano dalla ricerca interna anziché da aggressori esterni. Questa distinzione offre ai difensori l'opportunità di correggere le debolezze prima che i gruppi criminali le trasformino in armi.

L'AI aiuta inoltre i ricercatori a riesaminare software datato. Il codice legacy può contenere errori sopravvissuti ad anni di test perché nessuno aveva abbastanza tempo per esaminare ogni percorso. Un modello che cerca continuamente comportamenti sospetti può individuare vulnerabilità non correlate allo sviluppo recente.

Questo vantaggio va oltre le grandi aziende tecnologiche. I manutentori open source, i fornitori più piccoli e le società di consulenza per la sicurezza possono utilizzare l'analisi automatizzata per ispezionare componenti che in precedenza ricevevano un'attenzione limitata.

Eppure l'individuazione è solo il primo passo. Una falla plausibile deve essere riprodotta, valutata, segnalata in modo sicuro, ricevere un identificatore, essere corretta, testata e distribuita. L'AI accelera l'inizio di questa catena senza espandere automaticamente ogni team alla sua conclusione.

Questo squilibrio spiega perché un numero maggiore di scoperte non produca immediatamente sistemi più sicuri. Il beneficio dipende dalla capacità dei manutentori di trasformare le segnalazioni in correzioni affidabili prima che gli aggressori le trasformino in exploit.

Più disclosure non significano che ogni falla sia un'emergenza

Il problema centrale della cybersecurity si è spostato dall'individuare un numero sufficiente di vulnerabilità all'identificare quali segnalazioni creino un rischio immediato e concretamente raggiungibile.

Il record CVE grezzo di MITRE è un conteggio, non una coda di priorità. Una vulnerabilità in un gateway esposto a Internet con sfruttamento attivo merita una risposta diversa da una falla locale in un componente inutilizzato.

FIRST ha esaminato questa distinzione attraverso dati sulla sfruttabilità. La sua valutazione di metà anno ha filtrato le vulnerabilità utilizzando il catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency e risultati dell'Exploit Prediction Scoring System superiori al 10%.

L'organizzazione ha rilevato che la sfruttabilità operativa è rimasta sostanzialmente stabile nonostante l'aumento del volume totale. Nella sua terminologia, i difensori affrontavano più pioggia, ma non necessariamente un'alluvione proporzionalmente più grande.

Questa conclusione mette in discussione un'interpretazione comune dell'individuazione delle vulnerabilità con l'AI. I modelli stanno chiaramente aiutando i ricercatori a produrre più segnalazioni. Le evidenze attuali non mostrano che ogni debolezza trovata dall'AI diventi più facile o più attraente da sfruttare.

VulnCheck ha analizzato 1.061 scoperte assistite dall'AI attribuite pubblicamente e collegate al Project Glasswing di Anthropic e alla Berkeley Vulnerability Research Initiative. Ha rilevato che 14, ovvero l'1,3%, erano state confermate come sfruttate in natura.

Quel tasso era vicino al tasso di sfruttamento nell'intero dataset di VulnCheck. Il confronto suggerisce che le scoperte assistite dall'AI non fossero intrinsecamente più propense a trasformarsi in attacchi reali rispetto alle vulnerabilità scoperte con metodi convenzionali.

Il divario è ancora più evidente nei risultati pubblicati da Anthropic. VulnCheck ha riportato che Claude Mythos aveva identificato 23.019 candidati a vulnerabilità, mentre nella sua analisi solo 126 erano apparsi come CVE. Uno era stato confermato come sfruttato.

Queste cifre non dimostrano che i candidati rimanenti fossero innocui. Molti potrebbero essere ancora in revisione, soggetti a disclosure coordinata, in attesa di patch o trattenuti perché la pubblicazione creerebbe rischi. Mostrano però che i conteggi dei candidati e i CVE validati non sono intercambiabili.

Google Threat Intelligence Group è giunto a una conclusione correlata partendo da un dataset diverso. La sua analisi dello sfruttamento ha registrato 141 vulnerabilità sia divulgate sia sfruttate tra gennaio e agosto 2026.

Quel totale superava le 127 registrate nell'intero 2025. Lo sfruttamento medio mensile è salito da 10,5 casi nel 2025 a 18 nel 2026.

Tuttavia, solo lo 0,23% di tutte le vulnerabilità divulgate nel 2026 è apparso nello sfruttamento osservato. Ciò rappresentava approssimativamente una vulnerabilità sfruttata attivamente ogni 431 disclosure.

La piccola percentuale non dovrebbe incoraggiare il compiacimento. Una sola vulnerabilità può colpire migliaia di organizzazioni, soprattutto quando si trova in un prodotto esposto a Internet e ampiamente distribuito. Gli aggressori non hanno bisogno di trasformare in armi ogni CVE per causare danni estesi.

I dati sullo sfruttamento sono diventati più preoccupanti anche più avanti nell’anno. Google ha rilevato che, dopo maggio, la crescita delle divulgazioni e quella dello sfruttamento si sono mosse quasi di pari passo. Il volume indicizzato delle divulgazioni è aumentato del 128%, mentre lo sfruttamento indicizzato è cresciuto del 127%.

Lo sfruttamento ad alto rischio è più che raddoppiato. Google ha contato 75 vulnerabilità ad alto rischio sfruttate da gennaio ad agosto 2026, contro le 28 dell’intero 2025.

L’attività zero-day è rimasta più stabile. Uno zero-day è una vulnerabilità sfruttata prima che il fornitore o gli utenti dispongano di una correzione efficace. La media mensile è passata da otto nel 2025 a 11 nel 2026, anche se ad agosto ha raggiunto 22.

Google ha suggerito che gli attaccanti potrebbero ottenere un valore più immediato trasformando rapidamente in armi falle note, chiamate n-day, piuttosto che usando l’AI per scoprire zero-day del tutto nuovi. I modelli possono confrontare patch, note di rilascio, versioni dei prodotti e codice proof-of-concept per accelerare questo processo.

Per questo i team di sicurezza hanno bisogno di contesto sul rischio, non solo di elenchi più ampi di vulnerabilità. Il catalogo delle vulnerabilità sfruttate di CISA identifica le falle per cui esistono prove di sfruttamento attivo. EPSS stima la probabilità che una CVE pubblicata venga sfruttata a breve.

Questi segnali sono imperfetti, ma aiutano le organizzazioni a distinguere tra debolezze documentate e percorsi d’attacco urgenti. L’esposizione degli asset, i privilegi, i sistemi raggiungibili e le mitigazioni disponibili restano elementi essenziali della decisione.

Il vero collo di bottiglia è la capacità di triage e patching

L’AI può produrre risultati di sicurezza più rapidamente di quanto le organizzazioni riescano a stabilire la responsabilità, testare le correzioni e distribuire patch in sicurezza.

Ogni vulnerabilità valida avvia un processo operativo. Un manutentore deve riprodurre il problema, valutarne la gravità, identificare le versioni interessate, creare una correzione, testare eventuali regressioni, preparare un avviso e coordinare la pubblicazione.

I clienti affrontano poi la propria catena di attività. Devono individuare il prodotto interessato, capire se una funzionalità vulnerabile è attiva, valutare i controlli compensativi, pianificare un aggiornamento e confermare che la patch abbia avuto successo.

Questo lavoro diventa difficile quando un’organizzazione non dispone di un inventario software accurato. Un team di sicurezza non può stabilire con fiducia la priorità di una vulnerabilità se non sa dove viene eseguito il componente interessato o quali servizi aziendali ne dipendono.

Le dipendenze di terze parti rendono il problema più complesso. Una libreria vulnerabile potrebbe trovarsi diversi livelli sotto un’applicazione e rimanere invisibile al suo operatore. Container, plugin, firmware e servizi gestiti possono rendere ancora meno chiara la responsabilità.

La carenza di personale intensifica la pressione. Yukimi Sota, della filiale giapponese di Proofpoint, ha dichiarato al servizio di notizie originale che molte aziende stavano rimanendo indietro nelle contromisure perché il settore della sicurezza non disponeva di un numero sufficiente di lavoratori.

I recenti accessi non autorizzati e le fughe di informazioni presso aziende giapponesi hanno conferito al rapporto ulteriore urgenza. Gli incidenti avrebbero incluso Times Car, un importante servizio di car sharing, e spinto il governo giapponese a esortare le imprese a rafforzare le proprie difese.

Il rischio immediato non è che ogni nuova CVE richieda una distribuzione d’emergenza. Il rischio è che una coda non strutturata porti i team a non individuare il ristretto numero di falle che gli attaccanti stanno già sfruttando.

Applicare patch a tutto nell’ordine di pubblicazione sprecherebbe tempo prezioso. Potrebbe anche introdurre interruzioni quando modifiche affrettate incidono su complessi sistemi di produzione. I difensori devono combinare l’intelligence sulle minacce con il contesto dei propri asset e della propria attività.

Una sequenza pratica di priorità parte dallo sfruttamento attivo. I team dovrebbero poi considerare l’esposizione a Internet, i requisiti di autenticazione, la complessità dell’attacco, i privilegi ottenuti, la sensibilità dei dati e l’importanza del servizio interessato.

La gravità assegnata dal fornitore da sola non può rispondere a queste domande. Una vulnerabilità critica in un sistema di test isolato può presentare un pericolo meno immediato di una falla ad alta gravità su un gateway pubblico.

I team di sicurezza necessitano inoltre di un modo affidabile per conservare le decisioni. Avvisi, registri delle eccezioni, note sui sistemi interessati e prove delle mitigazioni spesso finiscono dispersi tra ticket, chat, fogli di calcolo ed email.

Una base di conoscenza tecnica ricercabile può aiutare i team a collegare le notifiche di vulnerabilità ai documenti di architettura e ai precedenti interventi di remediation. Non sostituisce la scansione o il patching, ma riduce le indagini ripetute.

Anche in questa fase l’AI può essere utile. Un modello può riassumere gli avvisi, associare i nomi dei prodotti agli inventari, confrontare le versioni, redigere istruzioni di remediation e aiutare gli analisti a raggruppare segnalazioni duplicate.

Questi utilizzi richiedono controlli. I team di sicurezza devono verificare le conclusioni generate, proteggere le informazioni riservate sui sistemi ed evitare di inviare credenziali o dettagli sensibili dell’architettura a servizi non autorizzati.

Le correzioni automatizzate creano un rischio distinto. Una patch che elimina un percorso di codice vulnerabile potrebbe introdurre un altro difetto o compromettere il comportamento in produzione. I manutentori hanno comunque bisogno di test, revisione e distribuzione graduale.

La pressione ricade in modo diseguale sull’ecosistema software. I grandi fornitori possono gestire team dedicati alla sicurezza dei prodotti e coordinare cicli di divulgazione su larga scala. I piccoli progetti open source potrebbero dipendere da pochi volontari che gestiscono migliaia di utenti.

La ricerca assistita dall’AI può quindi trasferire i costi dagli sviluppatori di modelli e dai laboratori di sicurezza ben finanziati a manutentori con risorse limitate. Trovare più bug è prezioso, ma i programmi di divulgazione devono tenere conto della capacità di risposta del destinatario.

Una segnalazione responsabile richiede deduplicazione, chiari passaggi di riproduzione, prove della gravità e finestre ragionevoli per la remediation. Inviare migliaia di avvisi a bassa affidabilità consumerebbe attenzione senza produrre benefici di sicurezza equivalenti.

Il risultato più solido è una pipeline equilibrata. L’AI effettua ricerche ampie, gli esseri umani convalidano i risultati rilevanti, i manutentori ricevono segnalazioni utili e i difensori classificano le distribuzioni in base all’esposizione reale.

Senza questa disciplina, un maggior volume di rilevamenti diventa un’altra fonte di affaticamento da avvisi. I team vedono più segnalazioni mentre le poche più pericolose restano sepolte.

L’AI cambia entrambi i lati della corsa alle vulnerabilità

La competizione strategica non è tra difensori AI e attaccanti tradizionali. Entrambe le parti possono usare capacità simili in fasi diverse dello stesso ciclo di vita delle vulnerabilità.

I difensori ottengono oggi un vantaggio significativo quando i programmi AI interni individuano e correggono le falle prima della pubblicazione. Google ha riferito che 401 delle 433 vulnerabilità di Chrome in un importante aggiornamento sono state trovate internamente.

Questo schema suggerisce che l’impennata delle divulgazioni includa lavoro preventivo. Una scoperta controllata dal fornitore consente agli ingegneri di sviluppare una patch, coordinarne il rilascio e preparare i clienti prima che informazioni tecniche dettagliate si diffondano.

Gli attaccanti acquisiscono leva dopo la divulgazione. L’AI può assimilare un avviso, confrontare modifiche al codice, generare un proof of concept, scansionare sistemi esposti e adattare codice exploit pubblico. Queste attività comprimono il periodo tra la pubblicazione e il tentativo di sfruttamento.

Recorded Future ha affermato che il tempo medio necessario agli attaccanti per sfruttare le vulnerabilità è sceso da 72 ore nel 2025 a 24 ore nel 2026. Questa stima rafforza la necessità di dare priorità immediata alle falle raggiungibili, anche se la maggior parte delle CVE non compare mai negli attacchi osservati.

I sistemi AI potrebbero alla fine scoprire e sfruttare autonomamente falle sconosciute. Casi pubblici e affermazioni dei fornitori mostrano progressi verso catene più lunghe di lavoro nella cybersecurity, ma le prove disponibili restano disomogenee.

Alcune dimostrazioni avvengono in ambienti controllati con obiettivi scelti con cura, notevoli risorse di calcolo, istruzioni personalizzate e supervisione di esperti. I loro risultati non dimostrano che criminali comuni possano riprodurre le stesse prestazioni su larga scala.

Palo Alto Networks ha dichiarato che modelli avanzati di Anthropic e OpenAI l’hanno aiutata a trovare 75 vulnerabilità nei propri prodotti, oltre sette volte il suo consueto conteggio mensile. Il suo chief product officer ha anche riconosciuto che lo sforzo ha richiesto una notevole personalizzazione e competenza umana.

Questa precisazione è importante. La capacità del modello è solo una parte di un attacco operativo. Gli avversari hanno ancora bisogno di accesso al bersaglio, infrastruttura, convalida, furtività, persistenza e di un modo per trasformare l’accesso tecnico in un risultato utile.

Anche i difensori dispongono di vantaggi strutturali. I fornitori controllano il codice sorgente, i test interni, la telemetria dei prodotti e la distribuzione delle patch. Possono indirizzare i modelli verso i propri sistemi e convalidare i risultati con ingegneri che comprendono l’architettura.

Gli attaccanti beneficiano dell’asimmetria. Hanno bisogno di un solo percorso utile verso un bersaglio, mentre i difensori devono gestire ogni sistema importante. L’AI non crea questo squilibrio, ma una ricerca più rapida può intensificarlo.

La divulgazione stessa collega le due parti. Pubblicare una CVE offre ai difensori un identificatore condiviso e informazioni per la remediation. Può anche indicare agli attaccanti su cosa concentrarsi, soprattutto quando una patch rivela il codice vulnerabile.

Ritardare indefinitamente la divulgazione non è una soluzione. Le falle non segnalate possono rimanere sfruttabili senza offrire ai clienti alcuna strada verso la protezione. L’obiettivo è un coordinamento che dia ai manutentori il tempo di rilasciare una correzione limitando al contempo l’esposizione tecnica non necessaria.

Le prove più solide finora supportano una conclusione più circoscritta rispetto alle affermazioni ottimistiche o allarmistiche. L’AI sta già aumentando la capacità di scoperta delle vulnerabilità. Sta anche aiutando nell’analisi e nello sviluppo di exploit, ma lo sfruttamento non è aumentato in proporzione diretta alle divulgazioni grezze.

Questo equilibrio può cambiare. I modelli stanno migliorando, la formazione focalizzata sulla sicurezza informatica si sta espandendo e più organizzazioni stanno integrando agenti nei flussi di lavoro di ricerca. I controlli di accesso attorno ai sistemi più capaci influenzeranno la rapidità con cui queste abilità si diffonderanno.

I responsabili della sicurezza dovrebbero evitare di pianificare sulla base di una singola previsione drammatica. Dovrebbero presumere che sia la scoperta sia la trasformazione in armi diventeranno più rapide, quindi costruire processi che rimangano utili in diverse possibili tempistiche.

Ciò significa cicli più brevi di identificazione degli asset, procedure testate per patch di emergenza, migliore segmentazione e monitoraggio più solido dello sfruttamento. Significa inoltre usare l’AI difensiva dove il suo output può essere verificato rispetto a dati autorevoli.

Cosa dovrebbero monitorare i team di sicurezza

Tre segnali mostreranno se l’impennata delle vulnerabilità rimane gestibile o diventa una crisi di sfruttamento più ampia.

Il primo segnale è il rapporto tra il totale delle CVE e lo sfruttamento confermato. I conteggi grezzi delle divulgazioni probabilmente continueranno a stabilire record, ma da soli non determinano il rischio operativo.

I team dovrebbero monitorare il catalogo CISA, la telemetria sullo sfruttamento e i punteggi di probabilità ad alta affidabilità. Se le vulnerabilità sfruttate rimangono una piccola frazione delle divulgazioni, la prioritizzazione può contenere gran parte del carico di lavoro.

Se lo sfruttamento inizierà a crescere più rapidamente delle divulgazioni, l’argomento centrale cambierà. Ciò indicherebbe che gli attaccanti stanno trasformando una quota maggiore dei rilevamenti in operazioni funzionanti, non semplicemente beneficiando di un bacino più ampio.

Il secondo segnale è il ritardo tra scoperta, convalida e disponibilità della patch. I programmi assistiti dall’AI possono rivendicare migliaia di candidati, mentre solo una frazione compare negli avvisi pubblici con correzioni.

Una riduzione del ritardo di conversione mostrerebbe che fornitori e coordinatori stanno espandendo la capacità insieme alla scoperta. Un arretrato crescente significherebbe che l’AI ha accelerato la parte iniziale della pipeline senza risolvere il più difficile collo di bottiglia della remediation.

I registri pubblici dovrebbero rendere tutto questo più facile da valutare. Una rendicontazione utile separerebbe candidati, vulnerabilità convalidate, identificatori assegnati, patch completate e correzioni distribuite.

Il terzo segnale è la velocità di sfruttamento dopo che una patch o un avviso diventano pubblici. In passato, i difensori misuravano in settimane le finestre di risposta per molte vulnerabilità. Evidenze di una strumentalizzazione sistematica entro un giorno costringerebbero più organizzazioni ad automatizzare i controlli di esposizione e le correzioni d’emergenza.

Questo segnale conta più di spettacolari dimostrazioni in laboratorio. Una riduzione ripetibile del tempo necessario alla strumentalizzazione nel mondo reale influenzerebbe ogni azienda che utilizza software diffuso, anche se gli aggressori non arrivassero mai a una scoperta completamente autonoma di vulnerabilità zero-day.

Il record CVE di MITRE dovrebbe quindi indurre una revisione dei processi, non un panico indiscriminato. Le organizzazioni devono sapere quali sistemi utilizzano, quali sono esposti a internet e chi è responsabile delle decisioni di correzione.

Dovrebbero inoltre verificare se gli aggiornamenti urgenti possono passare dall’avviso alla distribuzione senza rimanere bloccati nelle code di approvazione. Procedure di emergenza che esistono solo sulla carta non saranno adeguate a una finestra di sfruttamento di 24 ore.

La scoperta di vulnerabilità tramite IA resta un’opportunità difensiva. Può portare alla luce vecchie debolezze prima che le trovino i criminali e aiutare i manutentori a esaminare codice che non ha ricevuto una revisione sufficiente.

Il vantaggio dipende da ciò che accade dopo la scoperta. Un problema che nessuno convalida genera rumore. Una CVE convalidata senza una patch disponibile crea esposizione. Una patch che i clienti non possono distribuire lascia invariato il rischio sottostante.

Per sviluppatori, responsabili della sicurezza e acquirenti di tecnologia, la domanda chiave non è più se l’IA possa trovare più difetti. Le evidenze indicano che può farlo. La domanda è se la vostra organizzazione riesca a trasformare quel flusso di segnalazioni in un piccolo elenco ordinato di azioni prima che un aggressore faccia lo stesso.