CVE falsi, rapporti generati dall’IA e necessità di verifica

Creare rapporti convincenti sulle vulnerabilità costa sempre meno, con conseguenze sempre più rilevanti per chi si occupa della manutenzione del software e per i team di sicurezza. Nel luglio 2026 sono state pubblicate sei vulnerabilità ed esposizioni comuni (CVE) relative a SQLite; due hanno ricevuto un punteggio di gravità pari a 9,8. I rapporti sembravano legittimi: descrivevano bug relativi alla sicurezza della memoria e includevano spiegazioni tecniche e codice di proof of concept.

Ma i ricercatori di JFrog hanno scoperto che alcune delle funzioni citate nei rapporti non erano presenti nelle versioni interessate. Inoltre, nessuna delle proof of concept (PoC) riproduceva le vulnerabilità segnalate. La pagina CVE ufficiale di SQLite indica attualmente che questi sei rapporti non riguardano bug; le relative schede CVE sono state successivamente respinte.

Il problema non riguarda solo SQLite. Daniel Stenberg, il responsabile della manutenzione di curl, ha stimato l’anno scorso che circa il 20% dei rapporti di sicurezza ricevuti fosse frutto di contenuti scadenti generati dall’IA. L’autorità di numerazione CVE (CNA) di GitHub ha ricevuto quasi 4.000 richieste di CVE nel maggio 2026: il volume è aumentato di circa 10 volte rispetto all’anno precedente. GitHub non ha attribuito questo aumento all’IA né segnalato un calo della qualità delle segnalazioni, ma la forte crescita dei volumi evidenzia il sovraccarico del processo di divulgazione delle vulnerabilità.

L’IA facilita la creazione di segnalazioni dettagliate sulle vulnerabilità, ma stabilire se siano legittime richiede tempo. Inoltre, quando una CVE entra nei flussi di dati sulla sicurezza e nelle banche dati pubbliche, correggere la scheda originale non significa automaticamente che ogni sua copia venga aggiornata. Cresce così la necessità di distinguere una vulnerabilità segnalata da una verificata sul piano tecnico.

Che cos’è una CVE «falsa»?

Si usa spesso l’espressione «CVE falsa» per indicare una CVE che probabilmente è stata segnalata per errore. Ma «falsa» non significa necessariamente ingannevole per scelta. La segnalazione potrebbe derivare da un’analisi statica che non rileva un controllo di convalida o interpreta erroneamente un input come controllabile da un aggressore. Un rapporto può descrivere una funzione reale, ma indicare un percorso di attacco non valido. È possibile assegnare un identificativo (ID CVE) e poi revocarlo se la condizione segnalata, di fatto, non costituisce una vulnerabilità. Questo è diverso da un rapporto deliberatamente inventato.

Neanche una controversia equivale a una CVE falsa. Un fornitore può contestare le conclusioni di un ricercatore sull’exploitability, sui confini di sicurezza o sull’eventualità che una funzione fosse destinata a elaborare input non attendibili. Ma una contestazione non dimostra che il ricercatore abbia commesso un errore. E respingere una CVE non significa necessariamente che sia stata inventata: può essere respinta perché duplicata o per motivi amministrativi. Sebbene un identificativo CVE non costituisca una verifica tecnica indipendente, il settore deve prendere sul serio le segnalazioni reali.

Perché le CVE false sono un problema

Uno dei problemi che stiamo osservando è l’uso dell’IA per generare rapporti sulle vulnerabilità senza verificare adeguatamente i risultati. Questi rapporti possono includere spiegazioni tecniche dettagliate, riferimenti al codice e persino PoC, e quindi sembrare legittimi. Ma, come abbiamo visto con le CVE di SQLite, alcune delle funzioni citate non esistevano nemmeno nelle versioni interessate.

GitHub ha segnalato un notevole aumento delle segnalazioni di vulnerabilità nel 2026, senza tuttavia attribuirlo all’IA né riferire un calo della qualità delle segnalazioni. Il timore è che, all’aumentare del numero di rapporti, cresca anche il lavoro necessario per esaminarli, a prescindere dalla fondatezza dei risultati.

Chi ha selezionato e classificato segnalazioni di vulnerabilità conosce bene le difficoltà pratiche. Un modello di IA può individuare una chiamata API sospetta, abbozzare uno scenario di exploit e produrre rapidamente un rapporto dall’aspetto professionale. Per stabilire se lo scenario sia realizzabile può essere necessario controllare la versione esatta, ricostruire il flusso di controllo, capire come i dati raggiungono la funzione, predisporre un ambiente di test ed eseguire il presunto exploit. È lo stesso processo, che la segnalazione sia corretta o meno, e può essere costoso.

Le CVE false possono anche danneggiare la reputazione. L’annuncio di una vulnerabilità può diffondersi rapidamente nei flussi di dati degli scanner, nelle banche dati sulla sicurezza e nei risultati di ricerca. Una successiva rettifica, tuttavia, potrebbe non avere la stessa diffusione. Anche dopo che una segnalazione è stata contestata o respinta, i fornitori possono trovarsi sulla difensiva con i clienti che avevano visto il rapporto originale.

Esiste inoltre il rischio che vulnerabilità reali passino inosservate o vengano affrontate in ritardo perché i team impiegano tempo a esaminare segnalazioni errate. Quando chi mantiene il software e i team di sicurezza dispongono di risorse limitate, ogni ora dedicata a dimostrare che un falso positivo non è fondato è un’ora che si sarebbe potuta impiegare per indagare su un problema di sicurezza reale.

Contrastare il problema con l’automazione

Molti ricercatori ricorrono ancora alla selezione e classificazione manuale per gestire la nuova ondata di segnalazioni, ma non è una soluzione sostenibile. L’automazione si rivela un valido aiuto per verificare una segnalazione di vulnerabilità rispetto alla versione effettivamente interessata e alla relativa configurazione. Ecco le cinque domande da porsi:

• I presupposti necessari per l’attacco sono plausibili, inclusi configurazione e autorizzazioni?
• La funzione in questione è presente nella versione interessata?
• Un aggressore può raggiungere il codice vulnerabile? Determinare se il codice in questione può essere eseguito nelle condizioni interessate e se un aggressore può fornire un input che lo raggiunga.
• I tester riescono a riprodurre il comportamento in un test controllato o con una PoC?
• Il comportamento osservato produce l’impatto sulla sicurezza descritto nell’avviso?

Gli strumenti basati su agenti possono creare ambienti di test, analizzare i percorsi del codice, generare PoC e registrare prove dell’esecuzione da sottoporre a verifica. Non possono però convalidare automaticamente ogni affermazione. Anche quando una vulnerabilità è autentica, una PoC può non funzionare se l’ambiente è incompleto o il trigger è errato. I tester possono riprodurre un arresto anomalo senza dimostrare la sfruttabilità dichiarata. Ecco perché il giudizio umano resta fondamentale. Questi strumenti, tuttavia, possono aiutare i team ad avvicinarsi a una risposta riproducibile prima che una segnalazione sottragga altro tempo ai team di ingegneria, gestione delle vulnerabilità e assistenza clienti.

Affrontare il sovraccarico nell’ecosistema CVE

Nessuna politica concisa potrà risolvere magicamente il problema delle CVE false. Sarebbe però utile richiedere prove più solide a corredo delle segnalazioni e indicare con maggiore chiarezza lo stato della riproduzione. Sarebbe inoltre utile definire meglio come gestire le segnalazioni contestate e correggere più rapidamente i dati a valle. I ricercatori dovrebbero essere incoraggiati a convalidare i risultati ottenuti con l’ausilio dell’IA prima di inviarli.

I team di sicurezza e i fornitori devono concentrarsi sull’esame delle prove. Un punteggio critico per una CVE non indica se il percorso vulnerabile è raggiungibile nel loro ambiente. Il fatto che una PoC non funzioni non significa che sia tutto a posto. Inoltre, ricevere un ID CVE non esonera i team dal lavoro tecnico necessario per comprendere un problema.

L’IA sta potenziando la capacità di individuare le vulnerabilità e, al tempo stesso, consente di formulare affermazioni dall’aspetto convincente ma errate. In un contesto in cui le segnalazioni si moltiplicano, le organizzazioni devono investire nella verifica. Ciò comporta la creazione di test, la riproduzione dei risultati, la verifica delle ipotesi e una valutazione più agevole delle prove. È un ambito in cui i test di sicurezza basati su agenti potrebbero svolgere un ruolo importante.