CISA KEV: il catalogo Known Exploited Vulnerabilities

Che cos'è il catalogo CISA KEV?

Il catalogo Known Exploited Vulnerabilities (KEV) è mantenuto dalla Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti. CISA lo definisce la fonte autorevole delle vulnerabilità sfruttate in the wild e incoraggia vivamente tutte le organizzazioni a dare priorità alla loro correzione.

CISA ha istituito il catalogo nel novembre 2021 insieme alla Binding Operational Directive 22-01. Alla versione del catalogo del 24 settembre 2026 contiene 1.723 vulnerabilità. È una quota minima di tutte le CVE pubblicate, ed è proprio per questo che è utile: una voce KEV non è una previsione né un livello di gravità, è la registrazione di uno sfruttamento.

Come viene aggiunta una vulnerabilità

CISA aggiunge una vulnerabilità quando soddisfa tre criteri:

1. Ha un ID CVE.
2. È attivamente sfruttata, con evidenze affidabili che sia stata o venga sfruttata.
3. Esistono indicazioni chiare per la correzione, un'azione chiara per le organizzazioni colpite, come un aggiornamento del vendor.

Il terzo criterio conta nella pratica: una vulnerabilità può essere sfruttata per un certo tempo prima di comparire in KEV, perché non c'era una correzione a cui rimandare. Chiunque può proporre una vulnerabilità tramite un modulo raggiungibile dalla pagina KEV di CISA.

Che cosa contiene ogni voce KEV

Campo	Che cosa contiene
cveID	L'identificatore CVE
vendorProject, product	Chi produce il software interessato, e quale prodotto
vulnerabilityName, shortDescription	Un nome e una breve descrizione
dateAdded, dueDate	Quando CISA l'ha aggiunta, e la scadenza di correzione per le agenzie federali statunitensi
requiredAction	Che cosa fare, di solito applicare gli aggiornamenti o le mitigazioni del vendor, oppure interrompere l'uso
knownRansomwareCampaignUse	"Known" se è stata usata in una campagna ransomware, altrimenti "Unknown"
forensicTriage	"Yes" se la BOD 26-04 richiede per essa un triage forense
notes, cwes	Riferimenti e tipi di debolezza

361 voci sono attualmente contrassegnate come usate in campagne ransomware. Se deve stabilire un ordine all'interno di KEV, quelle vengono per prime.

BOD 26-04: le scadenze KEV per le agenzie federali

Per le agenzie del ramo esecutivo civile federale degli Stati Uniti, KEV non è un consiglio. La Binding Operational Directive 26-04, emanata il 10 giugno 2026, stabilisce la velocità con cui devono intervenire. Ha revocato la BOD 22-01, che concedeva due settimane per la maggior parte delle voci KEV e sei mesi per le CVE assegnate prima del 2021, e la BOD 19-02. I criteri per aggiungere una vulnerabilità a KEV non sono cambiati.

La BOD 26-04 fissa ogni scadenza in base a quattro domande, ispirate al modello decisionale SSVC di CISA:

• Esposizione pubblica: l'asset è raggiungibile da reti pubbliche?
• Stato KEV: la vulnerabilità è nel catalogo?
• Automazione dell'exploit: un attaccante può automatizzare lo sfruttamento?
• Impatto tecnico: lo sfruttamento dà un controllo parziale o totale?

Dalle risposte derivano scadenze che vanno da 3 giorni, con un triage forense per verificare se il sistema fosse già compromesso, fino alla correzione al successivo aggiornamento del sistema. La direttiva non si applica alle aziende esterne al governo federale, salvo che un contratto lo preveda. Anche così, è un utile termine di paragone per la Sua policy.

Come usare KEV se sviluppa software

La maggior parte delle voci KEV riguarda prodotti di grandi vendor: la sola Microsoft ne conta 388, seguita da Cisco, Apple, Adobe e Google. Compare anche l'open source, e quando compare si trova all'interno dei prodotti di altri. Log4Shell (CVE-2021-44228) è l'esempio che tutti ricordano.

Nemmeno le pipeline di build sono esenti. Le GitHub Actions compromesse tj-actions/changed-files (CVE-2025-30066) e reviewdog/action-setup (CVE-2025-30154) sono entrambe nel catalogo: una vulnerabilità di cui è noto lo sfruttamento può trovarsi nel workflow che compila il Suo prodotto, non solo nel prodotto.

1. Confronti KEV con ciò che distribuisce, non con ciò che i Suoi repository dichiarano. Una libreria vulnerabile introdotta in modo transitivo, o scaricata da uno script di build, è comunque nel prodotto.
2. Tratti una corrispondenza come un incidente, non come una voce di backlog. La corregga, oppure la mitighi e registri il motivo.
3. Verifichi il periodo di esposizione. Quali release hanno distribuito la versione vulnerabile, e da quando? È ciò che chiedono i clienti.
4. Tenga d'occhio i tempi di segnalazione. Ai sensi del Cyber Resilience Act dell'UE, una vulnerabilità attivamente sfruttata in un prodotto fa scattare per il fabbricante un obbligo di preallarme entro 24 ore.
5. Classifichi tutto il resto con EPSS e CVSS. Prioritizzazione delle vulnerabilità descrive il metodo.

Come ottenere i dati KEV

• CISA: la pagina del catalogo, più CSV, JSON e uno schema JSON.
• GitHub: cisagov/kev-data replica i file di dati e si aggiorna insieme al catalogo.
• Email: CISA offre un'iscrizione agli aggiornamenti del catalogo.
• I Suoi strumenti: molti scanner e piattaforme di gestione delle vulnerabilità segnalano le voci KEV, tra cui Grype, Tenable, Qualys e Rapid7.

Come aiuta CRACI

KEV Le dice quali vulnerabilità vengono sfruttate. CRACI Le dice dove si trovano. Esegue i Suoi job GitHub Actions e registra i pacchetti effettivamente scaricati da ciascun job, comprese le dipendenze transitive, i pacchetti in cache e le dipendenze nascoste che nessun lockfile elenca, e rivaluta di continuo le SBOM monitorate.

• Quali build sono colpite. La cronologia delle build mostra quali build passate contenevano la dipendenza vulnerabile, diretta o transitiva, così Lei conosce il periodo di esposizione.
• Chi la corregge. I team di sicurezza eseguono il triage dei risultati e inviano ciascuno al team responsabile della correzione.
• Evitare che venga distribuita di nuovo. I gate di policy possono bloccare una build che contiene una specifica CVE.
• Segnalarla. Per le vulnerabilità attivamente sfruttate ai sensi del CRA, CRACI invia le notifiche alle autorità per conto del fabbricante.

CISA KEV: domande frequenti

Che cos'è CISA KEV?

Il catalogo Known Exploited Vulnerabilities (KEV) è l'elenco di CISA delle vulnerabilità sfruttate in the wild. CISA lo definisce la fonte autorevole delle vulnerabilità sfruttate e incoraggia ogni organizzazione a dare priorità alla loro correzione.

Quante vulnerabilità ci sono nel catalogo KEV?

1.723 alla versione del catalogo del 24 settembre 2026, su centinaia di migliaia di CVE pubblicate. 361 di esse sono contrassegnate come note per essere state usate in campagne ransomware.

Che cosa fa entrare una vulnerabilità in KEV?

Tre criteri: ha un ID CVE, esistono evidenze affidabili che sia stata o venga sfruttata, ed esistono indicazioni chiare per la correzione, come un aggiornamento del vendor.

Le aziende private devono rispettare le scadenze KEV?

No. Le scadenze vincolano le agenzie del ramo esecutivo civile federale degli Stati Uniti ai sensi della Binding Operational Directive 26-04. Tutti gli altri possono usare il catalogo come segnale di prioritizzazione, e molti clienti e auditor se lo aspettano.

Che cosa ha sostituito la BOD 22-01?

La BOD 26-04, emanata il 10 giugno 2026, ha revocato la BOD 22-01 e la BOD 19-02. Invece di due settimane fisse per le voci KEV, stabilisce scadenze che vanno da 3 giorni al successivo aggiornamento del sistema, in base allo stato KEV, all'esposizione pubblica, alla possibilità di automatizzare lo sfruttamento e all'impatto tecnico.

Qual è la differenza tra KEV ed EPSS?

KEV registra le vulnerabilità già sfruttate. EPSS stima la probabilità che una qualsiasi CVE pubblicata venga sfruttata nei prossimi 30 giorni. Usi prima KEV, poi EPSS per classificare tutto il resto.