TL; DR
La maggior parte degli elenchi di vulnerabilità ti dice cosa potrebbe andare storto. CISUn catalogo KEV ti dice cosa non funziona in questo momento. Le vulnerabilità note sfruttate (KEV, Known Exploited Vulnerabilities) sono vulnerabilità CVE la cui effettiva sfruttamento è stata confermata. CISA gestisce il catalogo ufficiale e impone tempistiche di risoluzione dei problemi alle agenzie federali tramite la Direttiva Operativa Vincolante 22-01. La maggior parte delle organizzazioni private utilizza lo stesso elenco per filtrare le segnalazioni e identificare ciò che effettivamente deve essere corretto per primo.
CVSS, EPSS e KEV rispondono a tre domande diverse. Il CVSS misura la gravità teorica: quanto grave potrebbe essere la situazione? L'EPSS prevede la probabilità di sfruttamento entro 30 giorni: quanto è probabile che questa vulnerabilità venga presa di mira? Il KEV conferma lo sfruttamento attivo: è attualmente sotto attacco? Una vulnerabilità con un punteggio CVSS moderato, un punteggio EPSS elevato e un tag KEV è più urgente di una vulnerabilità con un punteggio CVSS critico senza prove di sfruttamento. I tre segnali lavorano insieme, non in modo intercambiabile.
Un KEV nella tua dipendenza non è un rischio teorico: ha una scadenza. I KEV spesso coinvolgono componenti, framework, container e altri elementi di terze parti. CI/CD dipendenze che i team ritengono sicure. CVE-2023-4966 (CitrixBleed) è stato confermato sfruttato entro pochi giorni dalla divulgazione. CVE-2024-1086 è stato rilevato dai gruppi ransomware poco dopo la sua inclusione nel catalogo KEV. standard La finestra di risoluzione dei problemi per i KEV esposti a Internet è di 1-3 giorni, non il tipico ciclo di aggiornamento.
Questo articolo tratta i seguenti argomenti: che cosa sono i KEV e in che modo differiscono da CVE, CVSS ed EPSS; come costruire un flusso di lavoro di prioritizzazione attorno a CISUn catalogo; e come Xygeni automatizza la correlazione KEV, l'applicazione delle misure di sicurezza e la correzione in tutto il mondo CI/CD pipeline— compresa una politica di salvaguardia YAML funzionante.
Cosa sono le vulnerabilità note sfruttate (KEV)?
Ogni scanner di vulnerabilità produce risultati classificati in base alla gravità CVSS. Il problema è che il CVSS misura l'impatto teorico, non lo sfruttamento attivo. CISUn catalogo di vulnerabilità note e sfruttate (KEV, Known Exploited Vulnerabilities) risolve un problema diverso e più urgente: elenca le CVE che gli aggressori stanno sfruttando in questo momento, con le relative scadenze per la correzione. Per qualsiasi team che stia cercando di decidere cosa correggere per primo, rappresenta l'indicazione più utile disponibile.
Vulnerabilità note sfruttate (KEV) sono Le vulnerabilità elencate nel CVE sono state confermate come sfruttate in naturaAgenzia statunitense per la sicurezza informatica e delle infrastrutture (CISA) mantiene l'ufficialità Catalogo KEV e impone tempi di bonifica attraverso Direttiva Operativa Vincolante 22-01. Molte organizzazioni private ora utilizzano questo elenco per stabilire le priorità di applicazione delle patch.
Sebbene il CVSS i punteggi misurano potenziale impatto, i KEV rappresentano attivo sfruttamento. In altre parole, trasformano "forse sfruttabile" in "sfruttato", richiedendo SLA più rapidi e processi automatizzati guardrails.
KEV vs CVE vs EPSS
I team di sicurezza spesso confondono questi termini correlati. Comprendere la differenza è fondamentale per una valutazione accurata dei rischi.
| Acronimo | Fonte | Missione |
|---|---|---|
| CVE | NVD | Identificatore univoco per una vulnerabilità divulgata. |
| CVSS | NVD / PRIMO | Misura la gravità teorica (impatto + sfruttabilità). |
| EPS | FIRST.org | Prevede la probabilità di sfruttamento entro 30 giorni. |
| KEV | CISA | Conferma lo sfruttamento nel mondo reale e stabilisce le scadenze per le patch. |
Insieme, questi sistemi formano una gerarchia di rischio: CVSS mostra quanto potrebbe essere grave un evento, EPSS mostra quanto è probabile che si verifichi e le vulnerabilità note sfruttate mostrano cosa sta realmente accadendo.
Ulteriori letture: Punteggio CVSS: come funziona il punteggio CVSS and EPSS vs CVSS: qual è la differenza?
Perché i KEV sono importanti per gli sviluppatori e CISOs
In primo luogo, i KEV evidenziano comportamento dell'attaccante dal vivoIn secondo luogo, spesso coinvolgono componenti di terze parti, framework, contenitori o CI/CD dipendenze, che i team presumono sicure. Di conseguenza, una correzione ritardata può aprire percorsi di spostamento laterale all'interno dell'infrastruttura di build e distribuzione.
Esempi recenti:
- CVE-2024-1086 (Linux nf_tables): aggiunto al catalogo KEV; sfruttato dai gruppi ransomware a metà del 2024.
- CVE-2023-4966 (CitrixBleed): sfruttamento confermato entro pochi giorni dalla divulgazione; cicli di patch di emergenza forzati in tutto il mondo.
Takeaway: I KEV non sono potenziali minacce, sono attivo quelli. Pertanto, tratta ogni vulnerabilità nota sfruttata come "aggiusta-ora", a meno che l'analisi di raggiungibilità non dimostri il contrario.
Come monitorare e dare priorità alle vulnerabilità note sfruttate
Per cominciare, controlla il sito ufficiale CISUn catalogo di vulnerabilità note sfruttate e contrassegnare eventuali corrispondenze all'interno dello scanner di sicurezza. Quindi, utilizzare queste informazioni per decidere quali correzioni devono essere eseguite per prime. Inoltre, combinare Vulnerabilità sfruttate note con Punteggi EPSS per ridurre il rumore e concentrarti sui punti deboli che influiscono realmente sul codice in esecuzione.
Flusso di lavoro passo dopo passo:
- Sincronizza i dati: Estrai gli ultimi aggiornamenti dal CISUn elenco ogni giorno e combinalo con gli altri feed sulle vulnerabilità.
- Risultati dei tag: Etichettare ogni scoperta come "Sfruttata" quando l'ID corrisponde CISUna lista.
- Verifica la raggiungibilità: Verifica se il codice vulnerabile viene effettivamente eseguito all'interno della tua app o build pipeline.
- Valutare la sfruttabilità: Usa il EPS per scoprire quali altri problemi potrebbero presto essere presi di mira.
- Scadenze per la presentazione delle domande:
- Vulnerabilità di Internet: risolvere entro 1-3 giorni.
- Quelli interni: risolvere entro una settimana.
- Codice non in uso: tienilo d'occhio e verificalo spesso.
- Risposte automatiche: Il sistema blocca le unioni non sicure, apre quelle sicure pull requestse registra le eccezioni per garantire che i team non perdano nulla.
Dalla consapevolezza all'azione: automatizzare le correzioni con Xygeni
In pratica, gestire tutto questo manualmente non è scalabile. Pertanto, Xygeni collega le vulnerabilità note sfruttate direttamente al tuo CI/CD flussi di lavoro, trasformando gli avvisi in azioni reali e guidate.
- Correlazione intelligente: Corrispondenze rilevate CVE contro il CISUn elenco e mette in evidenza i problemi "risolvibili subito" all'interno pull requests.
- Raggiungibilità + Sfruttabilità: Conferma se il percorso del codice vulnerabile è in esecuzione e si collega EPS dati per precise priorità.
- Guardrails: Arresta unioni o distribuzioni rischiose quando un difetto sfruttato colpisce file o servizi sensibili.
- Auto-riparazione: Apre PR sicure, verifica la presenza di possibili modifiche interrotte ed esegue test prima dell'unione.
- Registri di controllo: Tiene traccia in modo chiaro di cosa è stato risolto e quando, supportando gli obiettivi di sicurezza interna.
In breve, l'intelligence sulle minacce mostra cosa viene attaccato e Xygeni garantisce che il problema venga risolto in modo rapido, sicuro e automatico.
Esempio di policy Guardrail (YAML)
guardrail:
id: "kev-protection"
description: "Block merges if known exploited vulnerability detected"
conditions:
- match: vulnerability.kev == true
- match: reachability == "reachable"
actions:
- block: merge
- notify: ["slack:#security-alerts", "jira:SEC-OPS"]
- create_pr: true
sla:
critical: 72h
high: 7d
Questa regola si applica nessuna fusione per le vulnerabilità note sfruttate attive, notifica i canali pertinenti e crea automaticamente una PR di correzione, il tutto all'interno del tuo CI/CD guardrails.
Mini caso: prevenire l'impiego di un KEV
- Settimana 1: Una nuova libreria open source passa SAST ma include CVE-2023-4966.
- Settimana 2: La correlazione KEV di Xygeni lo rileva nell'ultimo CISUn aggiornamento.
- Settimana 3: Guardrails interrompere l'unione; la correzione automatica propone una versione corretta.
Risultato: Il team ha evitato di spedire un vulnerabilità nota sfruttata alla produzione e al restauro pipeline flusso all'interno dello stesso sprint.
Xygeni correla le tue CVE aperte con il CISUn catalogo KEV segnala automaticamente le vulnerabilità sfruttate note all'interno pull requests, impone guardrails che blocca le fusioni non sicure e apre PR di correzione con convalida integrata delle modifiche incompatibili.
