Nella sicurezza informatica, è da tempo prassi comune classificare le vulnerabilità utilizzando il CVE: a ogni difetto viene assegnato un numero, seguito da un punteggio CVSS, un tipo di CWE, un elenco dei prodotti interessati e, quindi, si può stabilire la priorità delle patch. Ma il 2024 e il 2025 hanno dimostrato quanto questa catena possa essere fragile se uno dei nodi chiave fallisce.
Innanzitutto, nel febbraio 2024, il National Vulnerability Database (NVD), gestito dal NIST, ha subito una battuta d’arresto. Per molti anni, l’NVD aveva svolto un lavoro di routine ma fondamentale: prelevare le voci dall’elenco del Common Vulnerability Index (CVE) e aggiornarle con le informazioni necessarie ai responsabili della sicurezza e agli scanner, inclusi punteggi CVSS, associazioni di tipi di errore, elenchi di software interessati e altri campi.
Crescita di CNVD e CNNVD dalla data di pubblicazione più vecchia. Elenco MITRE CVE per confronto. Nota: contiene tutti i CVE pubblici nell’elenco MITRE, inclusi quelli contrassegnati come RIFIUTATI (Fonte Bitsight)
La crisi dei finanziamenti pubblici statunitensi
Nel mezzo del rallentamento, l’NVD ha riconosciuto un crescente arretrato di voci non elaborate. La priorità è stata spostata alle vulnerabilità più recenti, principalmente quelle rilasciate dopo il 2018, ma l’arretrato stesso è rimasto.
Advertising
Quasi immediatamente, si verificò un altro sconvolgimento, questa volta organizzativo.
Dopo la conferenza VulnCon 2025, dove si discusse pubblicamente del futuro del programma CVE e della qualità delle pubblicazioni delle organizzazioni autorizzate a pubblicare CVE (note come CNA), emerse una notizia sul contratto del Dipartimento della Sicurezza Interna degli Stati Uniti che finanzia il programma. Il contratto non fu rinnovato nei tempi previsti, scatenando il panico, tra cui la possibilità di suddividere la catalogazione delle vulnerabilità in diverse liste indipendenti. Alla fine, la crisi fu mitigata, furono trovati i fondi e il programma continuò il suo lavoro senza interruzioni.
Ma questo fatto di per sé si rivelò spiacevole: il settore si era fin troppo abituato all’idea che MITRE e NIST avrebbero sempre agito come pilastri di supporto, ma si scoprì che anche loro presentavano delle vulnerabilità.
NVD vs CNVD. Occidente ed Oriente a confronto
Di recente, un ricercatore di Bitsight ha deciso di dare un’occhiata più ampia : cosa succede nei database governativi sulle vulnerabilità al di fuori degli Stati Uniti, e in particolare in Cina. Perché la Cina ne ha due, e operano secondo regole diverse.
In Cina, due database statali sulle vulnerabilità, CNNVD e CNVD , operano in parallelo.
Advertising
Entrambi i database utilizzano i propri identificatori e gestiscono i record separatamente, ma entrambi possono memorizzare i riferimenti CVE se il numero esiste già. I riferimenti incrociati tra CNVD e CNNVD sono pressoché inesistenti, quindi le voci devono essere confrontate utilizzando i CVE e le descrizioni corrispondenti.
Tipi di vulnerabilità in CNNVD. Traduzione fornita da Google Translate. Sono mostrati i primi 20 su 26. (Fonte Bitsight)
Il CNNVD è gestito dal centro di valutazione della sicurezza informatica del CNITSEC. La sua gestione è affidata a un’entità affiliata al Ministero della Sicurezza dello Stato. A giudicare dal modo in cui il CNNVD viene popolato e dal suo calendario di pubblicazione, il database sembra essere adattato a un flusso “esterno”: quando una vulnerabilità viene divulgata da fonti internazionali, un record viene rapidamente visualizzato nel CNNVD. In pratica, il CNNVD opera spesso come specchio del CVE, ma nel rispetto delle normative cinesi sulla pubblicazione.
Il CNVD è sotto il controllo del Chinese Computer Emergency Response Team (CNCERT). Il CNVD funziona più come una base di sicurezza tradizionale: registra nuove vulnerabilità, pubblica avvisi e assiste coloro che riparano falle nei prodotti e nelle infrastrutture.
Le regole dell’apparato delle vulnerabilità Cinesi
Un livello normativo separato e molto rigoroso si trova al di sopra dei due database. Le normative cinesi stabiliscono non solo cosa può essere divulgato su una vulnerabilità, ma anche quando può essere divulgato. Il documento chiave è il Network Product Vulnerability Management System ( RMSV), entrato in vigore nel luglio 2021. L’RMSV stabilisce una procedura che si differenzia significativamente dalla prassi occidentale di divulgazione coordinata.
RMSV richiede che le informazioni sulle vulnerabilità siano condivise con le agenzie governative, incluso il ministero competente. La scadenza è rigorosa: entro 48 ore dalla scoperta. I dettagli tecnici non possono essere divulgati fino al rilascio di una patch. Le pubblicazioni non devono contenere proof-of-concept, né tantomeno exploit completi. Una clausola separata vieta di gonfiare artificialmente la gravità del problema. Invece di accordi volontari tra ricercatori e fornitori, è in vigore una procedura prescritta, che privilegia la gestibilità e il controllo rispetto alla velocità di divulgazione.
L’accesso ai dati non è facilmente automatizzabile. Entrambi i database richiedono la registrazione e l’accesso. I dati possono essere scaricati, ma l’accesso automatizzato è pressoché inesistente: le richieste sono legate ad azioni nell’interfaccia e i file vengono generati lato server su richiesta. I dati vengono forniti in XML, ma occasionalmente errori XML possono causare l’interruzione dei parser standard, richiedendo un’estrazione dei dati più accurata.
Le dinamiche generali di entrambi i database cinesi rispecchiano in gran parte la crescita dei CVE, come previsto: una parte significativa delle voci riflette vulnerabilità internazionali. Ciò è particolarmente evidente in CNNVD, dove spesso compare un set quasi completo di CVE. Allo stesso tempo, sorgono problemi di qualità dei dati. Errori di battitura sono comuni negli stessi identificatori CVE: lettere mancanti, simboli errati, trattini sostituiti da altri caratteri ed errori negli anni. Per un analista, tali errori comportano un inutile lavoro manuale, ma per un professionista della sicurezza diventano un vero problema: le ricerche CVE iniziano a presentare lacune e la correlazione automatica con patch e regole di rilevamento si interrompe nei punti più inaspettati.
La mancanza di corrispondenza tra i database
I campi CNVD e CNNVD sono in qualche modo simili ai cataloghi occidentali, ma la sovrapposizione è incompleta. Entrambi i database hanno una scala di gravità. Questa scala è concettualmente simile ai livelli tipicamente ottenuti da CVSS , sebbene la distribuzione per livello non corrisponda esattamente alle statistiche internazionali. CNNVD ha un campo separato per il tipo di vulnerabilità; il suo ruolo è simile a CWE, ma non c’è una corrispondenza diretta. CNVD memorizza le date di invio e pubblicazione. In base a queste date, circa il 90% delle voci appare entro una settimana dall’aggiunta delle informazioni al database. Tuttavia, ci sono anche casi insoliti in cui la data di invio è successiva alla data di divulgazione ufficiale, il che assomiglia a un errore di inserimento dati e richiede cautela nell’utilizzo di tali tempistiche.
Il CNVD presenta un altro parametro che può essere facilmente scambiato per un collegamento a un incidente. In pratica, quasi tutte le schede sono etichettate come vulnerabilità software e hardware comuni. Spicca un gruppo separato di 74 record dell’estate 2020, etichettati come “vulnerabilità innescate da eventi”. A giudicare dalle descrizioni, queste schede ricordano più storie di furti e attacchi nell’ecosistema crypto che un’indicazione che la vulnerabilità sia stata effettivamente sfruttata.
Pubblicazioni in ritorno, dopo l’ingresso delle nuove normative
A parte queste anomalie, emerge un quadro semplice. Nella maggior parte dei casi, CNVD e CNNVDpubblicano i dati più tardi di CVE o lo stesso giorno. Le pubblicazioni anticipate sono rare: circa lo 0,55% per CNNVD e lo 0,18% per CNVD. Considerando l’intero periodo dal 2011, ci sono circa 1.400 dati in cui il database cinese è stato il primo.
Tuttavia, il ritardo, seppur raro, non è di solito di un paio di giorni. In media, il ritardo è di circa tre mesi. Le pubblicazioni più veloci sono più comuni tra le vulnerabilità a cui è stato assegnato un livello di gravità inferiore nella valutazione cinese. Nel CNNVD, le prime schede includono una percentuale significativa di voci senza un livello di gravità. Questa distribuzione è simile alla situazione quando i livelli di gravità sono ricavati da fonti occidentali. Finché non è disponibile un livello di gravità occidentale, il campo rimane vuoto o non specificato.
I record CNVD e CNNVD senza assegnazioni CVE sono una storia diversa. Il comportamento dei database è cambiato a partire dal 2021 circa, in concomitanza con l’introduzione di RMSV. Il CNVD ha iniziato a pubblicare tali record notevolmente più lentamente dopo l’introduzione dei regolamenti.
Il CNNVD ha iniziato a ridurre le sue pubblicazioni circa un anno prima dei regolamenti, e poi, nell’ultimo anno, ha ricominciato a pubblicare più record senza assegnazioni CVE. I dati stessi suggeriscono diverse possibili ragioni. I database potrebbero essere diventati più bravi ad associare i record ai CVE e a lasciare i record senza numerazione meno frequentemente. I nuovi regolamenti potrebbero aver rimosso alcune vulnerabilità dall’accesso pubblico. Inoltre, alcune di queste vulnerabilità potrebbero essere legate a software e dispositivi locali che si trovano raramente al di fuori della Cina e quindi non sono inclusi nei cataloghi internazionali. Molto probabilmente, sono in gioco diversi fattori.
📢 Resta aggiornatoTi è piaciuto questo articolo? Rimani sempre informato seguendoci su Google Discover (scorri in basso e clicca segui) e su 🔔 Google News. Ne stiamo anche discutendo sui nostri social: 💼 LinkedIn, 📘 Facebook e 📸 Instagram. Hai una notizia o un approfondimento da segnalarci? ✉️ Scrivici
La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella.
Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.
Sono ufficialmente aperte le adesioni al Program Sponsor della Red Hot Cyber Conference 2027, la sesta edizione dell’evento annuale gratuito promosso dalla community di Red Hot Cyber per diffondere cultura, competenze e consapevolezza sui temi della cybersecurity, dell’innovazione e delle tecnologie digitali. La Conference si terrà a Roma, martedì 18 e mercoledì 19 maggio 2027, presso l’Auditorium del Seraphicum, nel cuore del quartiere EUR, con una giornata dedicata ai workshop pratici e alle attività tecniche e una seconda giornata interamente dedicata alla conferenza.
Anche per il 2027, le aziende potranno scegliere di sostenere concretamente il progetto attraverso il Program Sponsor, partecipando alla crescita di un appuntamento che mette in relazione professionisti, aziende, istituzioni, studenti, ricercatori e appassionati di tecnologia. Il programma prevede la possibilità di aderire come Sponsor Sostenitore, una formula pensata per le aziende che desiderano essere tra le prime realtà a credere e contribuire alla realizzazione della nuova edizione, oppure attraverso i tre consueti livelli di sponsorizzazione Platinum, Gold e Silver. Ogni livello di sponsorizzazione acquistato, sarà accompagnato da un pacchetto Advertising, con l'opportunità di visibilità attraverso articoli, banner e contenuti all’interno del circuito editoriale di Red Hot Cyber.
Le aziende interessate a conoscere le formule disponibili, il Media Kit e tutte le opportunità previste dal Program Sponsor 2027 possono richiedere informazioni scrivendo a [email protected].