CISA KEV ed EPSS: dare priorità in base alle prove di sfruttamento

Lo scanner ti restituisce 400 finding e hai una settimana. CVSS può ordinarli per gravità, ma un 9.8 che nessuno usa può aspettare, mentre un 7.5 che gli attaccanti sfruttano già no. Due fonti gratuite ti dicono quali difetti vengono usati nella pratica. Il catalogo Known Exploited Vulnerabilities (KEV) di CISA elenca i difetti con sfruttamento confermato. L'Exploit Prediction Scoring System (EPSS) di FIRST stima quanto è probabile che ciascun difetto venga sfruttato nei prossimi 30 giorni.

Questo articolo spiega entrambi, mostra come si affiancano a CVSS e poi ti guida in un lab in cui interroghi i due feed per gli stessi CVE e costruisci una piccola tabella di priorità. Il punto da ricordare: gravità, prove di sfruttamento e la tua esposizione decidono insieme l'ordine delle patch. Ciascun fattore, da solo, dà un ordine sbagliato.

Se non conosci CVSS, leggi prima che cos'è CVSS. Per la differenza tra vulnerabilità, minaccia ed exploit, vedi che cos'è una vulnerabilità.

#Cosa dice CVSS e cosa lascia fuori

Il Common Vulnerability Scoring System valuta un difetto a partire dal suo vettore: come lo raggiunge un attaccante, quanto sforzo richiede, se servono privilegi o un'azione dell'utente e cosa può danneggiare. Il punteggio base è un numero da 0 a 10 ricavato da queste proprietà.

Il punteggio base risponde a una domanda: quanto sarebbe grave se qualcuno lo usasse? Non dice se qualcuno lo sta usando. CVSS ha metriche temporali che possono includere la maturità dell'exploit, ma la maggior parte delle dashboard mostra per primo il punteggio base, e quel numero non cambia dopo la pubblicazione del CVE.

Due CVE del lab qui sotto mostrano la distanza. CVE-2021-44228 (Log4Shell) ha un punteggio base di 10.0 nella NVD. CVE-2023-44487 (HTTP/2 Rapid Reset) ha 7.5. Un ordinamento basato solo sul punteggio mette Log4Shell al primo posto, ed è giusto. Il problema si vede con un backlog di quaranta difetti valutati 9.8 e nessun segno che uno di questi sia stato usato. Un punteggio ti dà un punto di partenza. Non ti dà un ordine.

#CISA KEV: sfruttamento confermato

Il catalogo KEV è l'elenco CISA delle vulnerabilità sfruttate in the wild. CISA dice di mantenere la fonte autorevole per quell'elenco e raccomanda alle organizzazioni di usare il catalogo come input per il proprio framework di priorità. L'inserimento dipende da prove affidabili che il difetto sia attivamente usato. Le voci arrivano man mano che arrivano le prove.

Il file del catalogo che ho scaricato per questo articolo (versione del catalogo 2026.11.06, rilasciata il 2026-11-06) ha 1.769 voci. Ogni voce ha questi campi:

• cveID, vendorProject, product e vulnerabilityName
• dateAdded, il giorno in cui CISA ha aggiunto il CVE
• dueDate, la scadenza fissata da CISA
• requiredAction, di solito una correzione del vendor o una mitigazione
• knownRansomwareCampaignUse, che vale Known o Unknown
• notes e cwes

Delle 1.769 voci, 361 sono contrassegnate Known per l'uso in ransomware. 285 sono state aggiunte nel 2026 fino alla data di rilascio.

Ci sono due limiti da tenere presenti. Il primo: il catalogo non è completo. Lo sfruttamento spesso inizia prima che CISA lo confermi, e alcuni difetti sfruttati non ottengono mai una voce. Un CVE assente da KEV non è confermato, e questo non vuol dire che sia sicuro. Il secondo: KEV non dice se la tua copia di un prodotto è interessata. Quella risposta viene dal tuo inventario.

#Da dove vengono le scadenze

La maggior parte delle persone conosce le scadenze KEV dalla BOD 22-01, una binding operational directive emessa da CISA il 3 novembre 2021. Imponeva alle agenzie federali statunitensi di correggere le voci KEV entro sei mesi per i CVE assegnati prima del 2021, ed entro due settimane per tutte le altre vulnerabilità. Nelle voci più vecchie il campo dueDate riflette ancora quel modello.

La BOD 22-01 non è più la regola. La sua pagina su cisa.gov ora dice che è stata revocata e sostituita dalla BOD 26-04, che CISA elenca con data 10 giugno 2026. La BOD 26-04 fissa i tempi di correzione in base a quattro input:

• Stato KEV: il CVE è nel catalogo?
• Esposizione dell'asset: gli utenti non autenticati su reti pubbliche possono raggiungere l'asset?
• Automazione dell'exploit: un avversario può automatizzare ogni fase dell'exploit?
• Impatto tecnico: quanto controllo dà un exploit riuscito?

La Tabella 1 della BOD 26-04 contiene i tempi effettivi. La direttiva conta giorni di calendario e definisce le voci "& forensic triage", che vanno corrette entro tre giorni e poi controllate per cercare segni di compromissione. Leggi la tabella sulla pagina della direttiva per i valori esatti. Non copiare i numeri da questo articolo o da vecchi post.

Il catalogo mostra entrambe le epoche. Nel file che ho scaricato, il divario tra dateAdded e dueDate è di 21 giorni per 1.025 voci, di 14 giorni per 286 voci e di circa sei mesi (181 o 182 giorni) per 249 voci. Quasi tutte le voci a sei mesi hanno ID CVE del 2020 o precedenti, il che corrisponde alla regola della BOD 22-01. I divari di 21 e 14 giorni sono date che CISA ha fissato voce per voce, quindi non riflettono un'unica regola fissa. 152 voci citano la BOD 26-04 in requiredAction o in notes.

#FIRST EPSS: probabilità nei prossimi 30 giorni

FIRST, il Forum of Incident Response and Security Teams, gestisce EPSS. FIRST lo descrive come un modello di machine learning che stima la probabilità che un CVE pubblicato venga sfruttato in the wild nei prossimi 30 giorni. FIRST pubblica il punteggio ogni giorno per ogni CVE. I dati sono gratuiti e non richiedono registrazione.

Ogni CVE riceve due numeri:

• Il punteggio è una probabilità tra 0 e 1. Un punteggio di 0.05 significa una probabilità del 5% di sfruttamento entro 30 giorni. FIRST dice che il modello è calibrato perché il punteggio corrisponda a quel tasso.
• Il percentile è la posizione in classifica. Un percentile di 0.99 significa che il CVE ha un punteggio più alto del 99% dei CVE valutati quel giorno.

La maggior parte dei punteggi resta vicina allo zero, perché la maggior parte delle vulnerabilità non viene mai sfruttata. Per questo il percentile è spesso più facile da leggere del punteggio grezzo. Un punteggio di 0.909 sembra alto già da solo, e un percentile di 0.998 ti dice come si colloca rispetto al resto dell'elenco di quel giorno.

FIRST dice che il modello usa circa 2.850 feature di cinque categorie (codice di exploit, chiacchiericcio online, metriche CVSS, età e volume dei riferimenti, tra le altre) e che apprende dall'attività di sfruttamento osservata fornita dai partner. I punteggi si muovono quando arrivano nuovi segnali. L'API può restituire una cronologia di 30 giorni per un singolo CVE, utile quando devi spiegare perché un punteggio è salito.

EPSS ha un limite chiaro. Prevede l'attività di sfruttamento. Non dice nulla su quanto sia grave un difetto, né sul fatto che i tuoi sistemi eseguano il codice interessato. Considera un punteggio alto come un motivo per guardare l'asset, e controlla l'asset prima di presumere che sia a rischio.

#Come si combinano con CVSS

Ogni fonte risponde a una domanda diversa:

L'ordine delle patch nasce dalla combinazione dei quattro. Questo è un punto di partenza e non una legge. Prima viene ciò che è confermato e raggiungibile. Poi ciò che è confermato ma non raggiungibile, e ciò che è non confermato con EPSS alto e raggiungibile. Il resto segue per CVSS e per valore dell'asset. La BOD 26-04 combina lo stesso tipo di input, quindi le regole federali seguono la stessa logica.

#Lab pratico: costruisci una tabella di priorità

Ti servono:

• Una shell Bash. L'esecuzione di riferimento ha usato Git Bash su Windows 11, con curl 8.12.1 e Python 3.12.
• Accesso a internet verso www.cisa.gov, api.first.org e services.nvd.nist.gov.
• jq, facoltativo. jq non era installato sulla macchina di riferimento, quindi ogni comando jq qui sotto ha un equivalente in Python 3.12, e gli output mostrati vengono dai comandi Python.

Questi passaggi leggono solo cataloghi pubblici. Nessuno di essi fa la scansione di un host. Se in seguito controlli la colonna dell'esposizione su servizi attivi, fallo solo su sistemi tuoi o per cui hai un permesso scritto di test.

#Passo 1: scarica il catalogo KEV

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json
ls -l kev.json

Il download è silenzioso. Nell'esecuzione di riferimento il file pesava 1,832,349 byte. Apri l'inizio del file e controlla catalogVersion e dateReleased prima di fidarti dei conteggi.

#Passo 2: conta le voci

jq '.vulnerabilities | length' kev.json

Sulla macchina di riferimento questo ha restituito command not found, perché jq mancava. L'equivalente in Python ha restituito:

python -c "import json; d=json.load(open('kev.json')); print(len(d['vulnerabilities']))"

1769

Il campo count al livello più alto dovrebbe mostrare lo stesso numero.

#Passo 3: cerca un CVE in KEV

jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | {cveID, dateAdded, dueDate, requiredAction}' kev.json

L'equivalente in Python ha stampato questo, qui con requiredAction accorciato:

{
  "cveID": "CVE-2021-44228",
  "dateAdded": "2021-12-10",
  "dueDate": "2021-12-24",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. ..."
}

Esegui la stessa query per CVE-2023-4863 e ottieni dateAdded 2023-09-13 e dueDate 2023-10-04. Le date sono il motivo per tenere il file del catalogo: registrano quando CISA ha agito, oltre al fatto che abbia agito.

#Passo 4: chiedi a EPSS degli stessi CVE

curl -s 'https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2023-4863' | jq '.data'

La risposta grezza dell'esecuzione di riferimento:

{"status":"OK","status-code":200,"version":"1.0","access":"public","total":2,"offset":0,"limit":100,"data":[{"cve":"CVE-2023-4863","epss":"0.999790000","percentile":"0.999800000","date":"2026-11-07"},{"cve":"CVE-2021-44228","epss":"0.999990000","percentile":"1.000000000","date":"2026-11-07"}]}

Nel codice contano due dettagli. Le righe tornano in un ordine diverso da quello della richiesta, quindi fai il match su cve e non affidarti mai alla posizione. I valori sono stringhe, quindi convertili in numeri prima di ordinarli o confrontarli.

#Passo 5: costruisci la tabella con uno script

Salva questo come priority.py. Gli basta la libreria standard di Python.

import json, sys, time, urllib.request

KEV_FILE = sys.argv[1]
CVES = sys.argv[2:]

def get(url):
    with urllib.request.urlopen(url, timeout=60) as r:
        return json.load(r)

kev = {v["cveID"]: v for v in json.load(open(KEV_FILE))["vulnerabilities"]}
epss = {row["cve"]: row for row in get(
    "https://api.first.org/data/v1/epss?cve=" + ",".join(CVES))["data"]}

print("| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |")
print("|---|---|---|---|---|")
for cve in CVES:
    nvd = get(f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={cve}")
    metrics = nvd["vulnerabilities"][0]["cve"].get("metrics", {})
    cvss = metrics.get("cvssMetricV31", [{}])[0].get("cvssData", {}).get("baseScore", "n/a")
    e = epss.get(cve, {})
    print(f"| {cve} | {cvss} | {'yes' if cve in kev else 'no'} | "
          f"{float(e.get('epss', 0)):.5f} | {float(e.get('percentile', 0)):.5f} |")
    time.sleep(7)  # the NVD API rate-limits requests without a key

Eseguilo su sei CVE: due dagli esempi del catalogo e quattro scelti per contrasto.

python priority.py kev.json CVE-2021-44228 CVE-2023-4863 CVE-2024-3400 CVE-2023-44487 CVE-2023-38545 CVE-2024-3094

Output dell'esecuzione di riferimento:

| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |
|---|---|---|---|---|
| CVE-2021-44228 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-4863 | 8.8 | yes | 0.99979 | 0.99980 |
| CVE-2024-3400 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-44487 | 7.5 | yes | 0.99999 | 0.99998 |
| CVE-2023-38545 | 9.8 | no | 0.78689 | 0.99591 |
| CVE-2024-3094 | 10.0 | no | 0.90900 | 0.99808 |

Lo script non compila la colonna dell'esposizione, perché il tuo inventario lo conosci solo tu. L'esecuzione di riferimento l'ha compilata così, e ogni riga indica cosa ha coperto il controllo:

• CVE-2021-44228: find per log4j-core*.jar nel profilo utente e nel repository non ha restituito nulla. Risultato: no.
• CVE-2023-4863: una ricerca di libwebp* in /mingw64, /usr e nel profilo utente non ha restituito nulla. Risultato: no.
• CVE-2023-38545: curl --version riporta 8.12.1. L'intervallo NVD per la libcurl interessata va da 7.69.0 fino a 8.4.0 escluso. Risultato: no, per la libcurl upstream. Vedi l'avvertenza qui sotto.
• CVE-2024-3094: xz --version riporta 5.6.4. NVD indica come interessate le versioni 5.6.0 e 5.6.1. Risultato: no.
• CVE-2024-3400 e CVE-2023-44487: non controllati su questa macchina.

La colonna dell'esposizione è quella che si sbaglia più spesso. Le distribuzioni Linux e i vendor fanno spesso il backport delle correzioni, quindi il solo numero di versione può ingannare. Controlla il bollettino di sicurezza del vendor per la tua build prima di chiudere una riga come sicura.

#Passo 6: leggi la tabella

Metti le righe in ordine di patch con la regola della sezione precedente. Se CVE-2021-44228, CVE-2023-4863 o CVE-2024-3400 fossero raggiungibili nella tua rete, sarebbero le prime patch della settimana, qualunque cosa dica il resto dell'elenco.

CVE-2023-44487 ha un punteggio CVSS più basso di CVE-2023-38545, ma è confermato e il suo punteggio EPSS è 0.99999. In un elenco in cui entrambi sono raggiungibili, viene prima lui. Il 9.8 che CISA non ha confermato scende.

CVE-2024-3094 è il caso che manda in crisi una regola semplice. I dati di CISA non lo elencano, eppure il suo punteggio EPSS è 0.909 e il suo punteggio CVSS è 10.0. Su questa macchina la versione non è interessata, quindi la riga si chiude. Su un host con xz 5.6.1, la stessa riga va in cima, perché il punteggio dice che l'attività di sfruttamento è molto probabile e il difetto è critico.

#Errori comuni

• Ordinare solo per CVSS. Il punteggio misura l'impatto e non l'uso. Affiancagli le colonne KEV ed EPSS.
• Trattare KEV come l'elenco completo. Una voce mancante significa che CISA non ha confermato lo sfruttamento. Non significa che il difetto sia innocuo.
• Leggere EPSS come impatto o come prova. EPSS stima l'attività di sfruttamento. Non ti dice che il difetto è nella tua rete.
• Copiare le scadenze federali. La BOD 22-01 è revocata. La BOD 26-04 si applica alle agenzie federali. Fuori da quel perimetro i suoi tempi sono un modello, e i tuoi dovresti fissarli in base al tuo rischio.
• Interrogare l'API in massa. FIRST ha costruito l'API EPSS per le singole ricerche. Per il dataset completo, scarica il CSV giornaliero.
• Dimenticare la data. I punteggi EPSS cambiano ogni giorno e KEV cresce ogni settimana. Scrivi la data accanto a ogni tabella.
• Fidarsi dei numeri di versione senza il bollettino di sicurezza del vendor. Backport e opzioni di build cambiano ciò che è interessato.
• Saltare la colonna dell'esposizione. Una tabella senza dati sugli asset è un'opinione sui difetti, e non un elenco di priorità per i tuoi sistemi.

#Per andare oltre

• Leggi la pagina sulla metodologia EPSS, https://www.first.org/epss/how-it-works, che tratta calibrazione e limiti.
• Usa il CSV giornaliero di EPSS, https://epss.empiricalsecurity.com/epss_scores-current.csv.gz, e uniscilo al file KEV su cveID. Così controlli centinaia di CVE in un solo passaggio.
• Leggi la BOD 26-04 e la sua Tabella 1. La direttiva indica il programma Vulnrichment di CISA come fonte per lo stato KEV, l'automazione dell'exploit e l'impatto tecnico dei CVE.
• Aggiungi due colonne dai tuoi registri: se l'asset è esposto su internet e quanto vale per te. Di solito queste due colonne cambiano l'ordine dell'elenco più dei punteggi.

#Fonti

I dati di questo articolo sono stati letti il 2026-11-08 dalle fonti elencate nei metadati dell'articolo. I conteggi KEV e i punteggi EPSS cambiano nel tempo, quindi controlla la data della tua esecuzione.