Per due decenni, l'NVD (National Vulnerability Database) ha costituito di fatto il fondamento della gestione delle vulnerabilità. Scanner, sistemi SIEM, strumenti di patch e framework di conformità si basavano tutti sul presupposto che, quando un CVE veniva inserito nell'NVD, gli analisti del NIST avrebbero prontamente aggiunto i punteggi di gravità, le corrispondenze con le versioni dei prodotti e i metadati contestuali che rendono effettivamente utile un ID CVE grezzo.
Il 15 aprile 2026, tale ipotesi ha smesso ufficialmente di essere attendibile.
Il NIST ha annunciato che l'NVD sta passando a un modello di arricchimento basato sul rischio. La maggior parte dei nuovi CVE inseriti nel database non riceverà più, per impostazione predefinita, il punteggio CVSS aggiunto dal NIST, né la mappatura dei prodotti CPE, né un'analisi indipendente. Per le organizzazioni i cui flussi di lavoro relativi alle vulnerabilità dipendono dai dati arricchiti dall'NVD, ciò crea un problema di copertura reale e crescente. Per gli sviluppatori e i fornitori di prodotti di sicurezza che integrano tali dati nei propri strumenti, ciò solleva una questione ancora più spinosa: cosa vi sta dicendo esattamente il vostro feed in questo momento?
L'NVD non riesce più a stare al passo con le vulnerabilità segnalate
Secondo quanto comunicato dallo stesso NIST, le segnalazioni CVE sono aumentate del 263% tra il 2020 e il 2025, e nel primo trimestre del 2026 erano già superiori di quasi un terzo rispetto allo stesso periodo dell'anno precedente.
Nel 2025 il NIST ha arricchito quasi 42.000 CVE, con un aumento del 45% rispetto a qualsiasi anno precedente. Tuttavia, questo aumento di produttività non è stato sufficiente a tenere il passo con il crescente numero di segnalazioni, il che ha portato all'adozione di un sistema di triage formalizzato.
A partire dal 15 aprile 2026, il NIST arricchirà solo le vulnerabilità presenti nel catalogo KVE (Known Exploited Vulnerabilities) della CISA, nel software utilizzato dal governo federale o nel software designato come critico ai sensi dell'Ordine Esecutivo 14028. Tutte le altre vulnerabilità saranno elencate nell'NVD, ma senza l'arricchimento aggiunto dal NIST e non saranno elaborate immediatamente.
Di conseguenza, quasi 300.000 CVE in arretrato pubblicati prima del 1° marzo 2026 sono stati trasferiti in blocco nella categoria "Non programmati".
Per i CVE che in futuro non rientreranno nei criteri di priorità del NIST, i punteggi di gravità saranno ora basati sui dati forniti dall'Autorità di numerazione CVE (CNA), spesso il fornitore del software interessato, anziché su un'analisi indipendente del NIST. Il NIST smetterà inoltre di ricalcolare i punteggi di gravità qualora la CNA ne abbia già fornito uno.
Tutti i principali scanner di vulnerabilità, tutte le regole di correlazione SIEM, tutti i punteggi di rischio di terze parti e tutti i quadri normativi di conformità, dal PCI DSS al FedRAMP, si basano sulla pipeline di arricchimento dati dell'NVD.
Con l'aggiornamento, tale processo è stato ora formalmente ridotto, con la conseguenza che alcune vulnerabilità CVE potenzialmente pericolose potrebbero non essere classificate come tali o individuate tempestivamente.
C'è un ulteriore fattore di accelerazione che vale la pena comprendere, poiché la riduzione dell'arricchimento si scontra con la rapida diffusione dei sistemi di rilevamento delle minacce assistiti dall'intelligenza artificiale.
I modelli avanzati di intelligenza artificiale e gli strumenti di programmazione stanno abbassando notevolmente la soglia per l'identificazione delle vulnerabilità sfruttabili e dei percorsi di attacco complessi nelle applicazioni, determinando un'impennata nella segnalazione di vulnerabilità CVE. Nel febbraio 2026, il Forum of Incident Response and Security Teams (FIRST) ha previsto che nel 2026 sarebbero state segnalate ben 50.000 vulnerabilità CVE in più, un numero da record. L'attuale infrastruttura di arricchimento dei dati non è in grado di gestire questo volume mantenendo gli standard di qualità precedenti.
Perché i prodotti basati esclusivamente su NVD presentano un problema
Un record CVE grezzo include in genere un ID, una descrizione e dei riferimenti. I metadati che sono alla base della gestione automatizzata delle vulnerabilità sono stati storicamente forniti dagli analisti dell'NVD. Questi dati si riferiscono a punteggi di gravità CVSS convalidati in modo indipendente, a mappature dei prodotti CPE e a classificazioni delle vulnerabilità CWE.
Ma è proprio l’«arricchimento» a rendere un CVE utilizzabile. Senza di esso, i flussi di lavoro che ne dipendono subiscono un deterioramento prevedibile.
La definizione delle priorità basata sul CVSS si indebolisce
Quando uno scanner o uno strumento di applicazione delle patch si aspetta un punteggio di gravità fornito dall'NVD e non ne trova alcuno, la vulnerabilità potrebbe essere classificata come "gravità sconosciuta", non rientrare nelle politiche di applicazione delle patch basate sullo SLA o essere considerata meno prioritaria.
L'aggiornamento del NIST dell'aprile 2026 ha confermato che:
- Le vulnerabilità CVE che non rientrano nei nuovi criteri di priorità non saranno automaticamente sottoposte a una valutazione indipendente
- Il NIST non genererà più un proprio punteggio CVSS qualora un CNA ne abbia già fornito uno (anche se tale CNA è il fornitore del software interessato)
Una mappatura CPE insufficiente o mancante causa un rilevamento CVE inadeguato
La documentazione ufficiale di NVD descrive l'identificazione dei prodotti come una componente fondamentale dell'arricchimento dei dati, poiché consente agli utenti di verificare a livello di programmazione se una vulnerabilità nota riguarda i prodotti presenti nel loro ambiente.
Se le mappature CPE sono assenti, incomplete o in ritardo, gli strumenti che si basano principalmente sulla corrispondenza CPE potrebbero non individuare la corrispondenza o individuarla in ritardo.
I fornitori di prodotti per la sicurezza sono tra i più colpiti, poiché i loro prodotti dipendono spesso dall'identificazione dei dispositivi CPE e dall'arricchimento dei dati CVE. Gli strumenti di gestione delle patch, protezione degli endpoint, controllo degli accessi di rete e gestione delle risorse si basano su informazioni accurate sulle vulnerabilità per determinare quali sistemi sono interessati, quale sia la gravità del problema e quali azioni intraprendere.
Per i team impegnati nello sviluppo di nuovi prodotti di sicurezza, basarsi esclusivamente sull'NVD significa partire da una base che potrebbe già presentare alcune lacune fondamentali: una copertura limitata delle vulnerabilità zero-day, la mancanza di informazioni aggiuntive per una quota crescente di CVE e cicli di aggiornamento che potrebbero non riuscire a tenere il passo con la rapidità con cui l'intelligenza artificiale individua e sfrutta le vulnerabilità.
Per i team che dispongono già di funzionalità di applicazione delle patch o di correzione, il rischio è diverso ma altrettanto rilevante. L'efficacia di un motore di correzione dipende interamente dalle informazioni sulle vulnerabilità che riceve. Se tali informazioni sono incomplete, in ritardo o eccessivamente dipendenti dall'arricchimento dei dati derivati dall'NVD, i flussi di lavoro a valle potrebbero tralasciare i prodotti interessati, attribuire una priorità inferiore alle vulnerabilità di gravità sconosciuta o non intervenire prima che l'esposizione aumenti.
Se tali prodotti dovessero presentare gli stessi punti deboli di NVD, tali punti deboli potrebbero ripercuotersi su tutti i clienti a valle.
È proprio questa lacuna che la valutazione delle vulnerabilità OESIS Framework è stata concepita per colmare: aiutare i team che si occupano di prodotti di sicurezza a potenziare le informazioni sulle vulnerabilità senza fare affidamento esclusivamente sull'arricchimento dei dati dell'NVD.
In che modo OPSWAT la questione in modo diverso
OPSWAT il modulo di valutazione delle vulnerabilità del framework OESIS appositamente per gli sviluppatori di prodotti di sicurezza che necessitano di dati sulle vulnerabilità affidabili e utilizzabili da integrare nei propri strumenti.
Progettato per colmare il divario
Il modulo integra più fonti, anziché basarsi su un'unica fonte.
Si avvale di una vasta gamma di fonti commerciali e open source relative alle vulnerabilità per garantire una copertura tempestiva e accurata di centinaia di fornitori e applicazioni.
Il catalogo delle vulnerabilità OESIS comprende attualmente oltre 65.000 CVE distinti e più di 150.000 casi di vulnerabilità, e viene aggiornato in modo continuo — più volte al giorno — anziché attendere i cicli di elaborazione dell'NVD.
Un punteggio di gravità proprietario che va oltre il CVSS, fornendo maggiori informazioni di contesto.
I dati sulle vulnerabilità OPSWAT includono OPSWAT Score, un sistema di valutazione proprietario che va oltre il punteggio CVSS di base, integrando ulteriori parametri quali la diffusione dei CVE, il rischio di compromissione e il ciclo di vita dei CVE.
In un contesto in cui una quota crescente dei punteggi CVSS potrebbe essere auto-dichiarata dai CNA, questo livello di analisi indipendente potrebbe aiutare i prodotti di sicurezza a fornire ai propri utenti un indicatore di priorità più attendibile.
Il servizio di intelligence sulle vulnerabilità OESIS supporta due percorsi di integrazione, senza necessità di una complessa fase di avvio:
- Feed del catalogo: confronta i dati sulle vulnerabilità di OESIS con l'inventario software esistente direttamente sul server, senza bisogno di agenti sugli endpoint. I prodotti esistenti dotati di funzionalità di inventario software possono utilizzare i dati di OESIS per individuare le vulnerabilità nelle risorse gestite.
- Endpoint (Software Kit)Endpoint : Integra il framework OESIS direttamente nel tuo prodotto per vulnerability detection in tempo reale vulnerability detection direttamente sul dispositivo. Ideale per i prodotti di sicurezza che girano sugli endpoint
Ricerca interna sulle vulnerabilità
Il team interno di ricerca sulle minacce OPSWAT, Unit 515, svolge attività continue di ricerca sulla sicurezza offensiva, simulazioni di attacchi, test avanzati e divulgazione responsabile riguardanti infrastrutture critiche e software aziendale. Il team ha identificato e segnalato oltre 50 vulnerabilità zero-day, tra cui risultati critici in software ampiamente diffusi, quali piattaforme ICS/OT come i PLC Delta e piattaforme native per l'intelligenza artificiale.
L' effetto netto per gli sviluppatori di prodotti di sicurezza è che i loro strumenti potrebbero continuare a garantire una copertura più ampia delle vulnerabilità anche se l'ambito di arricchimento dell'NVD dovesse restringersi, senza che i clienti debbano accettare una visibilità ridotta o ricorrere a soluzioni manuali.
Individuazione + Risoluzione: il ciclo completo
Il rilevamento individua i punti vulnerabili. La correzione li risolve. Insieme, contribuiscono a chiudere il più possibile il ciclo del rischio. OESIS Vulnerability Assessment si occupa del rilevamento e della definizione delle priorità. OESIS Patch Management è disponibile per i team che desiderano disporre di entrambe le funzionalità all'interno di un unico framework:
- Rilevamento: Applicazioni vulnerabili, con corrispondenza di versione, OPSWAT e contrassegnate da KEV
- Priorità: OPSWAT aiuta a individuare gli aspetti da risolvere per primi, sulla base di segnali di exploit reali
- Rimedio: La vostra pipeline esistente può elaborare i dati in uscita da OESIS oppure OESIS Patch Management applicare le patch, imporre le versioni o bloccare l'accesso direttamente
- Verifica: OESIS esegue una nuova scansione post-ripristino per verificare che l'endpoint sia privo di minacce prima di ripristinare l'accesso
Un rilevamento senza correzione è solo un rapporto. Un rilevamento con correzione è un rischio risolto. OESIS mira a fornire al vostro prodotto entrambe le cose, aiutandovi a chiudere più rapidamente il ciclo di rilevamento e correzione per stare al passo con la rapidità delle minacce basate sull'intelligenza artificiale.
Le vulnerabilità di AI-Speed richiedono un sistema di rilevamento specifico per AI-Speed
I produttori di soluzioni di sicurezza non possono permettersi di considerare le informazioni sulle vulnerabilità come una dipendenza secondaria a evoluzione lenta. Con l'aumento del volume dei CVE e la minore coerenza dei dati, i team di sviluppo hanno bisogno di un modo per mantenere i flussi di lavoro relativi al rilevamento, alla definizione delle priorità e alla correzione allineati all'esposizione reale.
È qui che entra in gioco OESIS Framework Vulnerability Assessment. Offre agli sviluppatori di prodotti un modo pratico per rafforzare la copertura delle vulnerabilità senza dover ricostruire da zero la propria infrastruttura di endpoint o di correzione. Ai team che stanno lanciando un nuovo prodotto, può aiutare a garantire una copertura affidabile in una fase precoce. Ai team che stanno migliorando un prodotto esistente, offre un modo più agevole per confrontare la copertura, verificare i miglioramenti e decidere come dovrebbe essere un'integrazione più approfondita.
