CISA KEV vs ENISA EUVD: 1.345 vs 265.000 CVE [2026]

Da ottobre 2026 l’Agenzia per la Cybersicurezza Nazionale ha iniziato a ispezionare le prime aziende soggette a NIS2, e una domanda molto pratica è arrivata sui tavoli dei CISO italiani: quale catalogo di vulnerabilità seguire per decidere cosa patchare per primo? Da una parte c’è il CISA Known Exploited Vulnerabilities (KEV), il catalogo americano nato nel 2021 e diventato lo standard de facto per la prioritizzazione. Dall’altra c’è ENISA EUVD, il database europeo delle vulnerabilità lanciato nell’aprile 2025 proprio per dare all’Unione uno strumento equivalente, autonomo dagli Stati Uniti.

Il confronto non è teorico. Le due fonti raccontano storie diverse sullo stesso rischio, coprono numeri diversi di CVE e vengono aggiornate a velocità diverse. Per un’azienda italiana che deve dimostrare all’ACN di avere un processo di gestione delle vulnerabilità documentato, capire dove appoggiarsi, o se serve usarle entrambe, fa la differenza tra un audit tranquillo e uno pieno di richieste di chiarimento. In questo articolo mettiamo a confronto le specifiche tecniche, la velocità di copertura, i costi di accesso e cinque casi reali del 2026 in cui le due fonti hanno guidato, o non guidato, le priorità di patching.

Cos’è CISA KEV e come funziona il catalogo americano

Il catalogo KEV nasce nel novembre 2021 sotto la direttiva vincolante BOD 22-01 dell’agenzia statunitense CISA (Cybersecurity and Infrastructure Security Agency). L’idea di fondo è semplice: invece di elencare tutte le vulnerabilità possibili, il KEV elenca solo quelle per cui esiste prova concreta di sfruttamento attivo in attacchi reali. Ogni voce include il codice CVE, il prodotto interessato, una breve descrizione della vulnerabilità, la data di aggiunta e una scadenza di remediation obbligatoria per le agenzie federali statunitensi, le cosiddette “FCEB agencies”.

La caratteristica che ha reso il KEV popolare ben oltre i confini USA è la sua dimensione contenuta. A differenza dei quasi 300.000 CVE pubblicati nel National Vulnerability Database, il KEV ne contiene circa 1.200-1.350, un sottoinsieme gestibile che qualsiasi team di sicurezza può monitorare senza sommergersi di rumore. CISA aggiorna il catalogo lo stesso giorno in cui riceve conferma di sfruttamento attivo, citando spesso fonti di intelligence pubbliche o segnalazioni di vendor. Nel giugno 2026, per fare un esempio recente, CISA ha aggiunto 23 nuove vulnerabilità in un solo mese, di cui 6 zero-day confermati.

Va detto che il KEV nasce per un pubblico specifico: le agenzie federali americane, con scadenze di 15 giorni per le vulnerabilità esposte su internet e 25 giorni per le altre. Le aziende private, comprese quelle italiane, lo usano su base volontaria, ma è diventato talmente citato nei report di settore (Clusit, Fortinet, TIM) da funzionare di fatto come riferimento globale informale. Puoi vedere l’evoluzione recente del catalogo nel nostro monitoraggio delle 16 falle aggiunte al KEV in tre settimane ad agosto 2026.

Ogni voce del catalogo segue uno schema fisso: identificatore CVE, nome del prodotto, nome del vendor, data di aggiunta, breve descrizione della vulnerabilità, azione richiesta e scadenza di remediation. Questa rigidità strutturale è un vantaggio operativo, perché permette di automatizzare l’ingestione senza dover interpretare testo libero. Il feed è distribuito sia in formato JSON sia in formato CSV, aggiornabile via script con una semplice richiesta HTTP, il che spiega perché così tanti strumenti di terze parti, dai SIEM open source fino alle piattaforme enterprise, lo abbiano integrato come sorgente predefinita fin dai primi mesi dopo il lancio.

Cos’è ENISA EUVD, il database europeo delle vulnerabilità

L’European Union Vulnerability Database nasce da un mandato preciso della direttiva NIS2: dare all’Unione Europea uno strumento proprio per tracciare vulnerabilità e sfruttamento, senza dipendere esclusivamente da fonti extra-UE. ENISA, l’agenzia europea per la cybersicurezza, lo ha lanciato ufficialmente nell’aprile 2025 e da allora lo ha ampliato progressivamente, aggregando dati da CSIRT nazionali, vendor e dalla stessa infrastruttura CVE globale.

A differenza del KEV, l’EUVD non si limita alle vulnerabilità sfruttate, ma cataloga l’intero universo delle CVE pubbliche, con un numero di voci che secondo un’analisi indipendente di VulnCheck si aggirava attorno a 265.000 record consultabili da interfaccia web (243.969 tramite API) a metà 2025, una cifra che abbiamo già documentato nella cronaca della crisi della CVE Foundation che ha spinto l’adozione di EUVD. Dentro questo oceano di dati, ENISA mantiene anche una lista più ristretta di vulnerabilità “sfruttate”, pensata per rispecchiare la logica del KEV ma con occhio europeo.

Il problema, emerso proprio nell’analisi di VulnCheck, è che questa lista di vulnerabilità sfruttate di EUVD risulta un sottoinsieme quasi puro del KEV americano: su 1.345 voci presenti nel catalogo CISA, la lista EUVD ne ometteva circa 75, senza aggiungere sfruttamenti individuati autonomamente dai CSIRT europei. Questo non significa che EUVD sia inutile: il suo valore sta nella copertura estesa di tutte le CVE, non solo di quelle sfruttate, e nel fatto di essere la fonte a cui la normativa NIS2 fa esplicito riferimento per le aziende regolate in Italia.

Sul piano tecnico, ogni voce EUVD include il codice CVE, una descrizione, il punteggio CVSS quando disponibile dal CNA (CVE Numbering Authority) di origine, i riferimenti agli advisory dei vendor e un campo specifico che indica lo stato rispetto al catalogo CISA, con valori come “CISA KEV: Added” oppure “CISA KEV: Not listed”. Questo campo, di per sé, è la prova più diretta che ENISA ha costruito EUVD pensando esplicitamente a un confronto continuo con il catalogo americano, piuttosto che a un sistema completamente indipendente. Per i team italiani, è anche il modo più rapido per capire, voce per voce, se una vulnerabilità presente in EUVD ha già ricevuto conferma di sfruttamento da parte di CISA o se si tratta ancora di un rischio solo potenziale.

CISA KEV vs ENISA EUVD: la tabella comparativa completa

Ecco un confronto punto per punto delle caratteristiche tecniche e operative dei due cataloghi, utile per capire dove si sovrappongono e dove invece divergono, e per decidere quale usare come riferimento primario nel proprio contesto aziendale.

Caratteristica	CISA KEV	ENISA EUVD
Ente gestore	Cybersecurity and Infrastructure Security Agency (USA)	ENISA, Agenzia UE per la Cybersicurezza
Anno di lancio	Novembre 2021	Aprile 2025
Base normativa	Binding Operational Directive 22-01	Direttiva NIS2
Voci totali catalogate	Circa 1.200-1.350 CVE sfruttate	Circa 265.000 CVE totali, con sottoinsieme “exploited” più ristretto
Criterio di inclusione	Prova concreta di sfruttamento attivo	Aggregazione da CSIRT nazionali, vendor e feed CVE globali
Frequenza di aggiornamento	Stesso giorno della conferma di sfruttamento	Continua, con discrepanze note tra sito e API
Scadenze di remediation	15 o 25 giorni per le agenzie federali USA	Nessuna scadenza propria, rimanda ai requisiti NIS2 nazionali
Formato dati	JSON scaricabile, feed pubblico	API REST pubblica, più interfaccia web
Costo di accesso	Gratuito	Gratuito
Ambito geografico primario	Stati Uniti, adozione globale volontaria	Unione Europea
Punteggio di rischio incluso	No, va integrato con CVSS o EPSS esterni	No, riporta CVSS quando disponibile dal CNA di origine
Copertura open source	Parziale, dipende dal prodotto	Parziale, sovrapposizione limitata con GitHub Advisories
Lingua dei contenuti	Inglese	Inglese, con metadati multilingua in espansione
Obbligo legale per aziende italiane	Nessuno, uso volontario	Riferimento indiretto tramite conformità NIS2 e vigilanza ACN

Il dato che salta più all’occhio è la differenza di scala: il KEV è deliberatamente piccolo e operativo, EUVD è pensato per essere esaustivo. Sono due filosofie diverse applicate allo stesso problema, la prioritizzazione delle vulnerabilità, e capirlo aiuta a scegliere lo strumento giusto per il contesto giusto.

Benchmark reali: copertura, velocità e affidabilità dei dati

Tre analisi indipendenti pubblicate tra il 2025 e il 2026 aiutano a mettere in prospettiva i numeri. La prima arriva da VulnCheck, che ha confrontato i conteggi diretti: il National Vulnerability Database segnava 294.484 CVE totali (279.338 escludendo le voci respinte), l’interfaccia web di EUVD ne mostrava 264.920 e l’endpoint API di EUVD si fermava a 243.969, una discrepanza di oltre 50.000 voci tra sito e API che VulnCheck ha definito una delle criticità più concrete della piattaforma europea nella sua fase di avvio.

La seconda analisi, pubblicata da Nautilus Radar in un confronto diretto tra quattro fonti (NVD, CISA KEV, ENISA EUVD e GitHub Security Advisories), colloca il KEV come la fonte più rapida in assoluto per la conferma di sfruttamento attivo, con aggiornamenti nello stesso giorno, mentre EUVD viene collocato su tempistiche di alcuni giorni e con copertura di exploitation definita parziale rispetto al KEV. GitHub Advisories, per confronto, copre oltre 30.000 avvisi mirati all’ecosistema open source, un ambito che né KEV né EUVD trattano in modo sistematico.

La terza fonte, sempre firmata VulnCheck, quantifica lo scarto tra le liste di exploitation: sulle vulnerabilità sfruttate, CISA KEV ne contava 1.345, la lista “exploited” di EUVD 1.270, mentre il catalogo commerciale VulnCheck KEV, che aggrega fonti più ampie incluse quelle non ancora confermate da CISA, arrivava a 3.672. Il messaggio che emerge da tutti e tre i confronti è coerente: nessuna fonte gratuita copre da sola la totalità dello sfruttamento reale, e chi si affida a una sola fonte accetta consapevolmente dei punti ciechi.

Questi numeri assumono ancora più peso se letti insieme al contesto in cui EUVD è nato. La piattaforma ha preso slancio proprio nel momento in cui il finanziamento della CVE Foundation statunitense ha attraversato una fase di incertezza, un episodio che abbiamo raccontato in dettaglio nel nostro pezzo sulle 17 ore di crisi che hanno spinto ENISA ad accelerare sull’adozione di EUVD come alternativa europea, con oltre 265.000 vulnerabilità già censite in quella fase iniziale. Anche il report Fortinet 2026 sulle minacce globali, che conta 122 miliardi di eventi di attacco osservati nell’anno e un incremento del 389% negli attacchi ransomware, cita esplicitamente l’adozione di cataloghi di exploitation pubblici come una delle poche difese scalabili contro un volume di minacce che nessun team umano può più tracciare manualmente voce per voce.

Prezzi e modalità di accesso: gratuito non significa uguale

Sia CISA KEV sia ENISA EUVD sono accessibili gratuitamente, via web o tramite API pubblica, e questo li rende adatti anche a team con budget di sicurezza limitati. La differenza pratica sta nel costo indiretto: integrare correttamente questi feed in un flusso di lavoro operativo richiede tempo di ingegneria, oppure l’adozione di piattaforme commerciali che li arricchiscono con punteggi di rischio, correlazione con l’inventario asset e automazione.

Fonte o strumento	Tipo di accesso	Copertura exploitation	Arricchimento incluso
CISA KEV (feed ufficiale)	Gratuito, JSON pubblico	Solo CVE sfruttate confermate	Nessuno, solo dati grezzi
ENISA EUVD (portale e API)	Gratuito, API REST pubblica	Sottoinsieme del KEV più contesto UE	CVSS quando disponibile, riferimenti CSIRT
NIST NVD	Gratuito	Non incluso nativamente	CVSS, CPE, CWE
GitHub Security Advisories	Gratuito	Limitata a dipendenze open source	Percorsi di remediation, versioni patchate
VulnCheck KEV (commerciale)	Freemium, piani a pagamento per accesso esteso	Più ampia del KEV ufficiale, include exploitation non ancora confermata da CISA	Scoring proprietario, API arricchita
Piattaforme enterprise (es. Qualys, Tenable)	Abbonamento enterprise, prezzi su richiesta	Aggregano KEV, EUVD, EPSS e telemetria proprietaria	Dashboard, correlazione con asset, reportistica di conformità

Per un’azienda italiana di medie dimensioni, la scelta più pragmatica nel 2026 è spesso ibrida: usare direttamente i feed gratuiti di KEV ed EUVD per la prioritizzazione quotidiana, e riservare un investimento in piattaforme enterprise solo quando il volume di asset da monitorare rende insostenibile la correlazione manuale. Un piccolo team con poche decine di asset esposti può gestire l’intero processo con uno script schedulato e un foglio di calcolo condiviso, mentre un’organizzazione con migliaia di endpoint distribuiti su più sedi difficilmente riesce a scalare senza una piattaforma che colleghi automaticamente ogni CVE all’inventario tecnico reale.

NIS2, ACN e obblighi di conformità in Italia

La direttiva NIS2 non impone esplicitamente l’uso del catalogo KEV o del database EUVD, ma il testo normativo cita in più punti l’obbligo per le organizzazioni di adottare misure tecniche e organizzative adeguate per la gestione delle vulnerabilità, ed ENISA è stata designata come ente di riferimento per la costruzione di uno strumento europeo equivalente. In pratica, per le aziende soggette a vigilanza ACN, dimostrare di monitorare EUVD rafforza la narrativa di conformità con lo spirito della norma, mentre ignorare il KEV significherebbe perdere l’accesso alla fonte più rapida per la conferma di sfruttamento reale.

Le prime ispezioni ACN, partite da ottobre 2026 su circa 20.000 aziende italiane secondo le stime riportate nel nostro approfondimento sulle ispezioni NIS2 e le sanzioni fino a 10 milioni di euro, hanno chiarito un punto: i verificatori non chiedono uno strumento specifico, ma pretendono un processo documentato di prioritizzazione che tenga conto di più fonti. Un’azienda che risponde “usiamo solo CVSS” fatica a dimostrare di seguire lo sfruttamento reale, mentre chi combina KEV, EUVD ed EPSS, il punteggio di probabilità di sfruttamento mantenuto da FIRST.org, porta un’evidenza molto più solida in sede di audit.

Il contesto italiano rende urgente questa scelta. Il report Clusit 2026 conta 507 attacchi gravi in Italia, il numero più alto in Europa, mentre il rapporto TIM segnala che solo il 3,9% delle aziende italiane si dichiarava pienamente pronto agli obblighi NIS2 al momento della pubblicazione. In questo scenario, appoggiarsi a un solo catalogo di vulnerabilità è un rischio che sempre meno CISO italiani sono disposti a correre. Puoi approfondire il quadro completo nel nostro report Clusit 2026 sui 507 attacchi in Italia.

C’è poi un secondo livello normativo da considerare, quello del Cyber Resilience Act, che impone ai produttori di software e hardware connesso obblighi di gestione delle vulnerabilità lungo tutto il ciclo di vita del prodotto, con sanzioni che possono arrivare fino a 15 milioni di euro per le violazioni più gravi. Per un produttore che deve documentare come gestisce le vulnerabilità dei propri prodotti dopo il rilascio, incrociare KEV ed EUVD non è solo una buona pratica di sicurezza, ma diventa parte della prova di conformità richiesta sia dal CRA sia dalla NIS2, due normative che in Italia si sovrappongono per molte aziende del settore tecnologico e manifatturiero.

Cinque casi reali del 2026: KEV ed EUVD messi alla prova

Guardare a episodi concreti aiuta più di qualsiasi tabella a capire come i due cataloghi si comportano sul campo. I sei casi seguenti, tutti registrati nel corso del 2026, coprono settori diversi (energia, industria, cloud, networking) e mostrano quanto la scelta della fonte possa cambiare i tempi di reazione di un’organizzazione.

Titan ransomware e Check Point IKEv1. Nell’agosto 2026 il gruppo ransomware Titan ha colpito nove aziende italiane in un solo giorno, sfruttando CVE-2026-50751, una vulnerabilità di autenticazione impropria nel protocollo IKEv1 dei gateway Check Point. La falla era già presente nel catalogo CISA KEV prima della campagna, e i team che monitoravano il feed avevano ricevuto un segnale di allarme con giorni di anticipo rispetto alle prime segnalazioni pubbliche italiane.

Clop e PTC Windchill. La falla CVE-2026-12569 in PTC Windchill/FlexPLM, con punteggio CVSS 9.8, è stata sfruttata dal gruppo Clop per colpire 43 vittime, tra cui Shell. È un caso da manuale di supply chain: il prodotto PLM colpito è usato in filiere industriali complesse, ed EUVD ha fornito ai team europei un contesto regolatorio più ricco sull’impatto verso operatori NIS2, mentre KEV ha garantito la conferma tempestiva dello sfruttamento attivo.

Ivanti EPMM e i governi UE. Un altro esempio riguarda CVE-2026-1281 su Ivanti EPMM, con CVSS 9.8, che ha colpito quattro governi europei. Trattandosi di un attacco con bersagli direttamente europei, questo è precisamente il tipo di scenario per cui ENISA ha costruito EUVD: dare visibilità mirata su exploitation che colpisce l’ecosistema UE, indipendentemente dalla rilevanza per le agenzie federali americane.

VMware vCenter su scala globale. CVE-2026-59310 ha esposto 361 server VMware vCenter in 47 paesi. Qui il KEV ha fatto da apripista per la conferma di sfruttamento, ma la dimensione realmente multinazionale dell’incidente ha reso evidente quanto sia difficile per una singola fonte, americana o europea, tracciare in tempo reale ogni singolo bersaglio colpito nel mondo.

Azure SQL Database, il caso della falla con CVSS massimo. CVE-2026-56162 ha raggiunto un punteggio CVSS di 10.0, il massimo possibile, su Azure SQL Database. Un punteggio così alto avrebbe già giustificato priorità assoluta secondo qualsiasi framework CVSS puro, ma è stata l’aggiunta al catalogo KEV a trasformare l’allerta in un’azione di patching effettivamente misurabile per i team che seguono le scadenze BOD 22-01 come riferimento interno, anche fuori dagli Stati Uniti.

N-central e la corsa contro tre CVE in parallelo. Il caso della piattaforma di gestione remota N-central di N-able, colpita da tre CVE distinte con punteggi CVSS fino a 9,8, mostra un altro limite pratico: quando più vulnerabilità critiche sullo stesso prodotto entrano nel KEV a distanza di giorni, i team che si affidano solo a un controllo manuale periodico rischiano di trattarle come un unico evento anziché come tre finestre di esposizione separate. L’automazione dell’ingestione del feed, descritta più avanti in questo articolo, è nata proprio per evitare questo tipo di errore di prioritizzazione.

Cosa dice CISA sulle priorità di patching

Le indicazioni ufficiali di CISA sull’uso del catalogo KEV restano il riferimento più citato quando si parla di prioritizzazione delle vulnerabilità, anche da parte di team europei che non hanno alcun obbligo diretto verso l’agenzia americana.

Sulla pagina ufficiale del catalogo, CISA scrive che “le organizzazioni dovrebbero usare il catalogo KEV come input per il proprio framework di prioritizzazione della gestione delle vulnerabilità” (fonte: CISA, Known Exploited Vulnerabilities Catalog), un’indicazione che lascia intenzionalmente spazio a combinare il KEV con altre fonti, incluso EUVD per chi opera in Europa.

Nella pagina di guida generale, CISA rincara la dose: “CISA raccomanda fortemente a tutte le organizzazioni di rivedere e monitorare il catalogo KEV e di dare priorità alla remediation delle vulnerabilità elencate, per ridurre la probabilità di compromissione da parte di attori di minaccia noti” (fonte: CISA, Known Exploited Vulnerabilities). La stessa pagina aggiunge che “CISA raccomanda fortemente a tutti gli stakeholder di includere un requisito per affrontare immediatamente le vulnerabilità del catalogo KEV come parte del proprio piano di gestione delle vulnerabilità” (fonte: CISA, Known Exploited Vulnerabilities).

Sul tema della prioritizzazione oltre il semplice punteggio CVSS, CISA suggerisce di affiancare framework più sofisticati: “prioritizzate in base agli attributi organizzativi, usando framework di gestione delle vulnerabilità come la Stakeholder-Specific Vulnerability Categorization (SSVC), che utilizzano lo stato di sfruttamento e altri dati sulla vulnerabilità per aiutare a dare priorità agli sforzi di remediation” (fonte: CISA, Transforming the Vulnerability Management Landscape), un consiglio che vale tanto per chi usa solo il KEV quanto per chi lo combina con EUVD.

Infine, ripercorrendo la storia del catalogo, CISA ricorda l’origine delle scadenze obbligatorie: “va ricordato che il catalogo KEV era accompagnato da una Binding Operational Directive rivolta alle agenzie federali civili esecutive (FCEB), che imponeva loro di rimediare alle vulnerabilità KEV esposte su internet entro 15 giorni e a tutte le altre entro 25 giorni” (fonte: CISA, KEV Catalog Reaches 1000). Molte aziende italiane, pur non essendo soggette a quella direttiva, hanno adottato le stesse finestre temporali come standard interno.

Guida alla migrazione: integrare KEV ed EUVD nel processo di vulnerability management

Passare da un processo basato solo su CVSS a uno che incrocia KEV, EUVD ed EPSS richiede un percorso strutturato, non un cambio improvvisato di strumenti. Ecco i passaggi che i team di sicurezza italiani stanno seguendo per prepararsi alle verifiche ACN, in un ordine pensato per ridurre al minimo l’interruzione dei processi già esistenti.

• Mappate l’inventario degli asset esposti e collegateli ai CPE (Common Platform Enumeration) corrispondenti, così da poter incrociare automaticamente i feed di vulnerabilità con ciò che possedete davvero.
• Automatizzate l’ingestione del feed JSON pubblico di CISA KEV e dell’API REST di ENISA EUVD, con un job schedulato almeno una volta al giorno, dato che il KEV può aggiornarsi anche più volte in 24 ore.
• Arricchite ogni CVE rilevante con il punteggio EPSS pubblicato da FIRST.org, per stimare la probabilità di sfruttamento anche per le vulnerabilità non ancora presenti né in KEV né in EUVD.
• Definite SLA interni di remediation ispirati alle scadenze BOD 22-01, 15 giorni per asset esposti su internet e 25 per gli altri, anche se non siete legalmente obbligati a rispettarle, perché sono ormai lo standard de facto citato nei report di settore.
• Integrate i feed nel vostro SIEM o SOAR, seguendo un approccio simile a quello descritto nella nostra guida per monitorare il catalogo CISA KEV con Python 3.12, adattando la stessa logica anche all’endpoint di EUVD.
• Documentate ogni decisione di prioritizzazione con riferimento esplicito alla fonte, KEV, EUVD, EPSS o CVSS, perché è proprio questa tracciabilità che gli ispettori ACN cercano durante gli audit NIS2.
• Rivedete trimestralmente i falsi negativi tra le due fonti, cioè le CVE sfruttate segnalate solo da una delle due, per capire se la vostra superficie d’attacco è più esposta a minacce con bersaglio USA o europeo.

Come interrogare le API: un esempio pratico

Sul piano tecnico, integrare i due feed non richiede infrastrutture complesse. Entrambe le fonti espongono endpoint pubblici che restituiscono dati strutturati, e un semplice script permette già di incrociare le due liste per capire quali CVE compaiono in una fonte ma non nell’altra. Ecco un esempio minimale in Python che scarica il feed JSON di CISA KEV e interroga l’API di ENISA EUVD per lo stesso set di identificatori CVE, un punto di partenza che ogni team può poi collegare al proprio inventario asset.

import requests

KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
EUVD_API = "https://euvd.enisa.europa.eu/api/vulnerabilities"

def get_kev_ids():
    r = requests.get(KEV_URL, timeout=15)
    r.raise_for_status()
    data = r.json()
    return {v["cveID"] for v in data["vulnerabilities"]}

def check_euvd(cve_id):
    r = requests.get(f"{EUVD_API}/{cve_id}", timeout=15)
    return r.status_code == 200

def find_gaps(kev_ids):
    only_in_kev = []
    for cve in kev_ids:
        if not check_euvd(cve):
            only_in_kev.append(cve)
    return only_in_kev

if __name__ == "__main__":
    kev_ids = get_kev_ids()
    gaps = find_gaps(kev_ids)
    print(f"CVE presenti in KEV ma assenti da EUVD: {len(gaps)}")

Uno script di questo tipo, eseguito una volta al giorno e collegato a un canale di notifica interno, basta a coprire la maggior parte dei casi descritti in questo articolo: individua le vulnerabilità che il KEV segnala come sfruttate ma che EUVD non ha ancora recepito, permettendo al team di sicurezza di reagire senza attendere l’allineamento tra le due fonti. Per team più maturi, lo stesso principio si applica integrando anche l’endpoint EPSS di FIRST.org, così da avere in un’unica dashboard tre livelli di segnale: sfruttamento confermato (KEV), rilevanza normativa europea (EUVD) e probabilità statistica di sfruttamento futuro (EPSS).

Pro e contro di CISA KEV ed ENISA EUVD

I vantaggi e i limiti di CISA KEV

Il punto di forza principale del KEV è la velocità: aggiornamenti nello stesso giorno della conferma di sfruttamento, un catalogo piccolo e gestibile, e un’adozione talmente ampia da essere diventato lo standard implicito citato in quasi ogni report di settore, compresi quelli italiani di Clusit e TIM. È gratuito, ha un formato dati semplice da integrare e offre scadenze di remediation chiare, anche se pensate originariamente per le agenzie federali americane.

I limiti sono altrettanto chiari. Copre solo 1.200-1.350 CVE su un universo di quasi 300.000, quindi lascia fuori moltissime vulnerabilità ad alto rischio ma non ancora confermate come sfruttate. Non include un punteggio di rischio proprio, va sempre integrato con CVSS o EPSS. E non ha alcun legame diretto con la normativa europea, quindi da solo non basta a dimostrare conformità NIS2 in un audit ACN. Un ulteriore limite pratico riguarda la copertura geografica dell’intelligence: essendo costruito principalmente sulla visibilità di CISA sulle minacce contro infrastrutture statunitensi, può in teoria arrivare in ritardo su campagne che colpiscono prevalentemente bersagli europei, anche se nella pratica osservata nel 2026 questo scarto temporale è risultato minimo per la maggior parte delle vulnerabilità critiche.

I vantaggi e i limiti di ENISA EUVD

ENISA EUVD porta sul tavolo una prospettiva europea che il KEV non ha, aggregando dati da CSIRT nazionali e offrendo una copertura molto più ampia dell’universo CVE, non limitata alle sole vulnerabilità sfruttate. È gratuito, nasce esplicitamente per supportare gli obblighi NIS2 ed è la scelta più naturale per dimostrare allineamento normativo agli ispettori ACN.

Di contro, è una piattaforma relativamente giovane, lanciata solo nell’aprile 2025, e secondo l’analisi indipendente di VulnCheck la sua lista di vulnerabilità sfruttate è di fatto un sottoinsieme quasi puro del KEV americano, con circa 75 voci mancanti rispetto al catalogo CISA al momento dell’analisi. Esiste inoltre una discrepanza concreta tra i dati mostrati dal portale web e quelli restituiti dall’API, con oltre 50.000 CVE visibili solo sul sito, un problema di maturità tecnica che ENISA sta affrontando progressivamente. Per un team che costruisce automazioni basate esclusivamente sull’API, questo significa che una parte non trascurabile del catalogo può restare temporaneamente invisibile ai propri script, un dettaglio da tenere presente prima di considerare EUVD come unica fonte di verità.

Quale scegliere: cinque casi d’uso concreti

Non esiste una risposta unica, ma il contesto operativo aiuta a orientare la scelta. La dimensione dell’azienda, il settore regolato e la distribuzione geografica degli asset contano più del semplice budget disponibile per la sicurezza.

Aziende italiane soggette a NIS2 con vigilanza ACN diretta dovrebbero trattare EUVD come riferimento primario per la documentazione di conformità, ma continuare a monitorare KEV per non perdere la velocità di conferma sullo sfruttamento reale.

Multinazionali con filiali sia europee sia statunitensi traggono vantaggio dall’uso di entrambi i cataloghi in parallelo, perché ogni filiale può dover rispondere a un regolatore diverso con requisiti diversi.

PMI con budget di sicurezza limitato possono partire dal solo feed KEV, più compatto e più semplice da integrare manualmente, aggiungendo EUVD in un secondo momento quando il processo matura.

SOC e MSSP che gestiscono più clienti contemporaneamente beneficiano dell’integrazione di entrambe le API in un SIEM centralizzato, arricchendo i dati con EPSS per coprire anche le vulnerabilità non ancora presenti in nessuno dei due cataloghi.

Team di compliance e audit interno dovrebbero usare EUVD per il mapping regolatorio verso NIS2 e Cyber Resilience Act, riservando il KEV come prova documentale di tempestività nella risposta a exploitation confermata.

Il verdetto: usare entrambi, non scegliere uno solo

I dati raccolti in questo confronto portano a una conclusione poco elegante ma onesta: non esiste un vincitore assoluto tra CISA KEV ed ENISA EUVD, perché rispondono a domande diverse. Il KEV vince nettamente sulla velocità di conferma dello sfruttamento reale e sulla semplicità operativa, con un catalogo di circa 1.200-1.350 voci aggiornato lo stesso giorno. EUVD vince sulla copertura complessiva, con circa 265.000 CVE censite, e sulla rilevanza diretta per gli obblighi NIS2 in Italia e in Europa.

La stessa analisi di Nautilus Radar, che ha messo a confronto quattro fonti diverse, arriva a una conclusione simile: l’approccio più resiliente alla gestione delle vulnerabilità combina più fonti contemporaneamente, non ne isola una sola. Per un’azienda italiana alle prese con le prime ispezioni ACN, la combinazione pratica più sensata resta questa: EUVD come base documentale per la conformità NIS2, KEV come segnale operativo di allarme rapido, ed EPSS come livello aggiuntivo di prioritizzazione per tutto ciò che nessuno dei due cataloghi ha ancora formalmente incluso.

Nei prossimi mesi è probabile che il divario tra le due fonti si riduca. ENISA ha già mostrato di voler colmare le lacune segnalate da VulnCheck, ed è ragionevole aspettarsi che l’allineamento tra sito e API di EUVD migliori con le prossime revisioni della piattaforma. Fino a quel momento, però, trattare KEV ed EUVD come intercambiabili resta un errore che nessun team di sicurezza italiano dovrebbe permettersi, soprattutto con gli ispettori ACN che hanno già iniziato a bussare alle porte delle prime 20.000 aziende sotto vigilanza NIS2.

Domande frequenti su CISA KEV ed ENISA EUVD

CISA KEV ed ENISA EUVD sono in competizione tra loro?
No, sono fonti complementari. Il KEV riflette la visibilità di CISA sulle minacce contro infrastrutture statunitensi, EUVD riflette la visibilità di ENISA sulle minacce contro l’ecosistema digitale europeo. Usarli insieme copre più angolazioni dello stesso problema.

Un’azienda italiana è obbligata per legge a usare ENISA EUVD?
No, la direttiva NIS2 non impone l’uso di uno strumento specifico. Richiede però misure adeguate di gestione delle vulnerabilità, ed EUVD è lo strumento che ENISA ha costruito esplicitamente per supportare quell’obbligo.

Perché il catalogo CISA KEV contiene così poche vulnerabilità rispetto a EUVD?
Perché il KEV include solo le CVE per cui esiste prova concreta di sfruttamento attivo, mentre EUVD cataloga l’intero universo delle vulnerabilità pubbliche, non solo quelle sfruttate.

Le scadenze di 15 e 25 giorni del KEV valgono anche per le aziende europee?
No, quelle scadenze derivano dalla Binding Operational Directive 22-01 e vincolano solo le agenzie federali civili statunitensi. Molte aziende europee le adottano comunque come standard interno volontario.

È vero che la lista delle vulnerabilità sfruttate di EUVD è incompleta rispetto al KEV?
Secondo un’analisi indipendente di VulnCheck condotta nel 2025, la lista delle vulnerabilità sfruttate di EUVD ometteva circa 75 voci presenti nel catalogo CISA KEV, risultando di fatto un sottoinsieme parziale piuttosto che una fonte autonoma di rilevamento.

Conviene integrare anche l’EPSS insieme a KEV ed EUVD?
Sì. L’EPSS, mantenuto da FIRST.org, stima la probabilità di sfruttamento futuro anche per vulnerabilità non ancora confermate come sfruttate, colmando parte del divario che né KEV né EUVD coprono da soli.

Quale delle due fonti è più adatta per un audit ACN sulla conformità NIS2?
EUVD è la scelta più naturale come riferimento documentale, dato il suo legame diretto con la normativa europea, ma affiancarlo al KEV rafforza la prova di un processo di prioritizzazione basato su evidenze concrete di sfruttamento, non solo su punteggi teorici. Gli ispettori tendono a valutare positivamente processi che citano entrambe le fonti insieme a una data di ultima revisione documentata.

Esistono alternative commerciali che uniscono KEV, EUVD e altre fonti?
Sì, piattaforme come VulnCheck KEV offrono un catalogo esteso con scoring proprietario, mentre suite enterprise come Qualys o Tenable integrano KEV, EUVD ed EPSS insieme alla telemetria interna, con prezzi su abbonamento pensati per team di sicurezza di grandi dimensioni. Per i team più piccoli, però, i feed gratuiti restano più che sufficienti come punto di partenza.

Con quale frequenza vanno controllati i due cataloghi per restare al passo con NIS2?
Per il KEV è consigliabile un controllo automatizzato giornaliero, dato il ritmo di aggiornamento stesso giorno. Per EUVD un controllo giornaliero o al massimo ogni due giorni è sufficiente, vista la natura più graduale degli aggiornamenti, ma entrambi vanno rivisti manualmente almeno una volta al mese in sede di reportistica interna.