KEV batte CVSS: il framework che i CISO usano quando i punteggi mentono

Il 31 agosto 2026 la prioritizzazione delle vulnerabilità ha un framework decisionale ufficiale: CISA BOD 26-04 imposta quattro variabili di scoring, mentre nel settore privato si afferma la regola gerarchica KEV prima, EPSS poi, CVSS per ultimo. Il caso Langflow CVE-2026-55255—con CVSS 6.1 per CISA e 9.9 per KEVIntel—dimostra che la divergenza non è eccezione ma sistema, e che seguire solo il punteggio più alto o il più basso è un errore di sicurezza.

BOD 26-04: dalla teoria del punteggio unico al framework multi-variabile

Il Binding Operational Directive 26-04, emesso da CISA, rompe con la logica del CVSS come metro unico. Le quattro variabili ufficiali—Asset Exposure, KEV Status, Exploit Automation, Technical Impact—introducono un criterio decisionale dove la severità tecnica è solo uno dei fattori. La svolta è operativa: le federal civilian agencies devono ora integrare segnali eterogenei, non sommarli arbitrariamente.

Il documento non è vincolante per il settore privato, ma funge da segnale normativo. Quando un ente federale statunitense ridefinisce i criteri di aggiornamento obbligatorio, il mercato enterprise segue—specie su vendor con contratti governativi. Il BOD 26-04 legittima ciò che i CISO avanzati già praticavano: il CVSS descrive il potenziale impatto di un difetto, non il rischio per l'organizzazione specifica.

Langflow: il caso studio di una divergenza che non è errore

La vulnerabilità CVE-2026-55255 nell'AI agent platform Langflow è il campione perfetto della disallineazione sistemica. CISA assegna CVSS 6.1; KEVIntel e CIRCL calcolano 9.9 per lo stesso identificatore. La spiegazione tecnica—documentata nell'advisory GitHub GHSA-qrpv-q767-xqq2—sta nel campo "scope" del CVSS v3.1: l'IDOR consente attraversamento di boundary tenant in ambienti multi-tenant, un impatto che il calcolatore standard può sottovalutare se il vendor non dichiara esplicitamente la separazione come confine di sicurezza.

Il fix rilasciato in Langflow 1.9.1 aggiunge validazione ownership nella funzione get_flow_by_id_or_endpoint_name. La modifica è chirurgica ma rivelatrice: il difetto non era tecnicamente complesso da correggere, ma la sua classificazione sì. Un team vulnerability management che patchesse per CVSS decrescente avrebbe ritardato Langflow rispetto a una RCE con punteggio più alto ma senza exploitation in-the-wild.

Perché i tre segnali si contraddicono di sistema

Il problema non è che uno dei tre punteggi è "giusto" e gli altri sbagliati. CVSS, EPSS e KEV misurano dimensioni ortogonali: il primo la gravità tecnica massima teorica, il secondo la probabilità statistica di exploitation nel prossimo 30 giorni, il terzo la conferma empirica di exploitation attiva. La loro divergenza è prevedibile, anzi strutturale: catturano fenomeni diversi con metodologie diverse.

"CVSS, EPSS, and CISA KEV each carry a useful but incomplete signal. Static metadata like these cannot describe whether a vulnerability is safely protected in a development environment or exposed in an application absorbing 30,000 attacks a month." — Contrast Security, AppSec Overflow 2026

I dati runtime di Contrast Security, pur essendo proprietari e non verificabili indipendentemente, convergono su un quadro critico: il tempo medio di remediation per vulnerabilità critiche in custom code è 92 giorni, mentre la weaponization può avvenire in ore. Il divario tra velocità d'attacco e velocità di difesa rende la prioritizzazione corretta—non la più veloce, ma quella giusta—l'unico fattore controllabile.

Cosa fare adesso

Per i team vulnerability management, il framework si traduce in quattro azioni prioritarie:

1. Adottare la gerarchia KEV > EPSS > CVSS come default decisionale, non come opzione tra pari. Quando i tre segnali convergono, la scelta è ovvia; quando divergono, il tiebreaker è exploitation confermata.

2. Mappare l'esposizione effettiva dell'asset prima di applicare qualsiasi punteggio. Dr. Joye Purser, Global Field CISO di Cohesity, enuncia il criterio esplicito: "active exploitation first, then exploit likelihood, then technical severity, with adjustments for asset exposure, business criticality, compensating controls, and the potential consequences of compromise". La stessa vulnerabilità in un identity system esposto supera per priorità una RCE in asset isolato.

3. Fissare target di remediation differenziati per classe di rischio: 24-72 ore per critiche internet-exposed con exploitation nota, con consapevolezza che questo richiede tradeoff organizzativi sui mid-sized enterprise.

4. Trattare le discrepanze di scoring come dati, non come anomalie da ignorare. Il caso Langflow (6.1 vs 9.9) va documentato internamente come esempio di scope sottovalutato, non come "errore" di un singolo vendor.

Ryan Dewhurst di KEVIntel quantifica il problema di volume: circa 200 CVE al giorno rendono impossibile patchare tutto. L'accelerazione dell'exploitation tramite AI—"attackers move faster using AI to reverse engineer patches"—comprime ulteriormente la finestra. La prioritizzazione non è più un miglioramento del processo: è il processo.

FAQ

Perché CISA e KEVIntel danno CVSS diversi per la stessa CVE?
Perché il campo "scope" del CVSS v3.1 dipende dalla dichiarazione del vendor sui confini di sicurezza. Se Langflow non dichiara esplicitamente la separazione tenant come boundary protetto, il calcolatore assegna punteggio minore. La divergenza è legittima, non un errore di calcolo.

BOD 26-04 mi obbliga se non sono un'agenzia federale USA?
No, si applica alle federal civilian agencies. È tuttavia segnale operativo per il settore privato, specialmente per vendor con business governativo o per audit che ne verificano l'adozione come best practice.

EPSS alto ma KEV assente e CVSS basso: cosa fare?
Il framework KEV>EPSS>CVSS suggerisce EPSS prima di CVSS in assenza di exploitation confermata, ma il dossier non fornisce casi studio su questa specifica combinazione. La fonte non specifica come gestire questa classe limite.

Fonti

• https://www.helpnetsecurity.com/2026/08/31/joye-purser-cohesity-kev-epss-cvss-conflicts/
• https://nhimg.org/articles/cve-prioritization-needs-kev-and-epss-not-cvss-alone/
• https://www.techtimes.com/articles/319918/20260708/cisa-adds-first-ai-agent-platform-kev-sets-thursday-deadline-4-cves.htm
• https://www.01net.it/ai-is-breaking-the-find-and-fix-model-for-application-security-new-contrast-research-finds/
• https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
• https://www.techtimes.com/go?u=https%3A%2F%2Fhelpx.adobe.com%2Fsecurity%2Fproducts%2Fcoldfusion%2Fapsb26-68.html&aid=319918
• https://github.com/langflow-ai/langflow/security/advisories/GHSA-qrpv-q767-xqq2
• https://www.helpnetsecurity.com/2026/07/30/ryan-dewhurst-kevintel-known-exploited-vulnerabilities/

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti