VEX: separare le vulnerabilità che contano dal rumore della SBOM
VEX, sigla di Vulnerability Exploitability eXchange, è la risposta a un problema che la distinta dei componenti di un software crea proprio mentre ne risolve un altro. La SBOM ha reso possibile sapere cosa c’è dentro un’applicazione, e da quell’elenco di componenti uno strumento automatico ricava subito tutte le vulnerabilità note che li riguardano, spesso centinaia, a volte migliaia. È un risultato prezioso, ma con un effetto collaterale pesante: la grande maggioranza di quelle vulnerabilità non riguarda davvero il prodotto, e il diluvio di allarmi finisce per seppellire i pochi che contano. VEX serve a separare i due insiemi, dicendo, per ciascuna vulnerabilità, se il prodotto ne è effettivamente esposto.
Il malinteso da sciogliere è il cuore della questione. Che una vulnerabilità sia presente in un componente non significa che sia sfruttabile nel prodotto che lo usa. Il codice difettoso potrebbe non essere mai eseguito, la funzione vulnerabile potrebbe non essere raggiungibile, un controllo a monte potrebbe già neutralizzare il problema. Senza un modo per distinguere la presenza dalla sfruttabilità, la SBOM si trasforma da strumento di trasparenza in generatore di rumore, e i team o annegano nei falsi positivi o smettono del tutto di leggere quegli elenchi. VEX nasce per evitare entrambi gli esiti.
Il problema che la SBOM crea risolvendone un altro
Conviene vedere bene il meccanismo che produce il diluvio. Una distinta dei componenti elenca le librerie e i moduli che compongono un software; uno scanner incrocia quell’elenco con i database delle vulnerabilità note e restituisce ogni difetto associato a ciascun componente. È un abbinamento meccanico, che non sa nulla di come quel componente è usato nel prodotto: segnala tutto ciò che, in teoria, potrebbe riguardarlo. Per un’applicazione reale, fatta di decine o centinaia di dipendenze, il risultato è una lista lunghissima.
Il guaio è che quella lista mescola, senza distinguerli, i pochi difetti realmente pericolosi e la massa di quelli che non hanno alcun effetto pratico in quel contesto. È lo stesso problema che affligge tante fonti di allarme in sicurezza: un rapporto segnale-rumore così basso da rendere il segnale invisibile. La gestione delle vulnerabilità diventa così un lavoro di smistamento a tappeto, in cui correggere ciò che non serve sottrae tempo a ciò che conta, e l’adozione stessa degli SBOM rischia di produrre più fatica che sicurezza.
Esposto non vuol dire sfruttabile
La distinzione su cui poggia tutto è quella tra presenza ed esposizione. Una vulnerabilità presente in una libreria è un fatto verificabile incrociando la distinta con i database; la sua sfruttabilità nel prodotto è un’altra cosa, e dipende dal contesto. La domanda giusta non è se il componente difettoso sia incluso, ma se il codice vulnerabile sia effettivamente raggiungibile durante l’esecuzione, se un attaccante possa controllarne l’ingresso, se esista già una mitigazione che chiude la strada all’attacco.
A queste domande non può rispondere chi sta a valle e si limita a incrociare elenchi, perché non conosce le viscere del software. Può rispondere chi quel software lo conosce dal di dentro: il suo produttore in primo luogo, ma anche un integratore o un fornitore di sicurezza che ne analizzi la raggiungibilità del codice. È qui che VEX inserisce la propria logica: spostare il giudizio sulla sfruttabilità a chi è in grado di darlo, e renderlo comunicabile in modo che chi sta a valle possa usarlo per dare priorità invece di rincorrere ogni segnalazione.
VEX dice lo stato, e perché
In concreto, VEX è una forma di avviso di sicurezza che dichiara, per ogni vulnerabilità e per un dato prodotto, uno tra quattro stati: non interessato, interessato, già corretto, oppure sotto indagine. Il valore più utile è il primo, perché è quello che spegne il rumore: dire che il prodotto non è interessato da una vulnerabilità presente in un suo componente è ciò che permette di cancellarla dalla lista delle cose di cui preoccuparsi. Proprio per questo non può essere un’affermazione gratuita, e le giustificazioni dello stato codificate dalla CISA impongono di motivarla con una tra cinque categorie: il componente vulnerabile non è incluso nel prodotto, oppure è incluso ma il codice difettoso non è presente perché escluso in fase di build o configurazione, oppure quel codice non si trova mai nel percorso di esecuzione, oppure non può essere controllato da un avversario, oppure è già in atto una mitigazione integrata che ne neutralizza lo sfruttamento. In alternativa alla giustificazione codificata, lo stesso requisito ammette una motivazione discorsiva.
Il punto decisivo è che tutto questo è leggibile da una macchina. Un documento VEX non è una nota discorsiva da interpretare a mano, ma un’asserzione strutturata che gli strumenti del consumatore possono elaborare automaticamente, sopprimendo le vulnerabilità dichiarate non sfruttabili e facendo emergere quelle che restano. Le linee guida minime sempre della CISA fissano cosa un VEX deve contenere per assolvere a questa funzione, dall’identificazione del prodotto e della vulnerabilità fino allo stato e alla sua motivazione.
Chi lo emette è chi conosce il codice
Vale la pena insistere su questa divisione del lavoro, perché è ciò che rende VEX diverso da un ennesimo strumento di scansione. Chi conosce il funzionamento del software, tipicamente il suo produttore ma anche un integratore o un analista che ne studi il comportamento, si fa carico di dichiarare la sfruttabilità; il consumatore, a valle, smette di indovinare e usa quella dichiarazione per concentrare gli sforzi dove servono. È un patto efficiente, ma che funziona a una condizione: che i produttori pubblichino davvero i propri VEX. Senza quel passo, la conoscenza resta dove non può essere usata, e il consumatore torna ad annegare.
Formati e governo: CISA, CSAF, CycloneDX, OpenVEX
VEX non è un singolo formato, ma un concetto che diverse specifiche realizzano. Lo si può esprimere con il CSAF, lo standard OASIS per gli avvisi di sicurezza che ne prevede un profilo dedicato e che nel maggio 2025 è stato ratificato come standard internazionale ISO/IEC 20153; lo si può incorporare direttamente in una SBOM in formato CycloneDX, così che la distinta dei componenti porti con sé anche il giudizio sulla loro sfruttabilità; oppure lo si può produrre con OpenVEX, un’implementazione minimale e interoperabile, indipendente dal formato della distinta e allineata ai requisiti minimi definiti dalla CISA. Il concetto è nato nel processo multistakeholder della NTIA sulla trasparenza dei componenti software, poi confluito nei gruppi di lavoro della CISA, ed è proprio questo lavoro di standardizzazione che permette a VEX di funzionare su scala: senza un linguaggio comune, le asserzioni di un produttore non sarebbero leggibili dagli strumenti di un altro.
Messo nel quadro più ampio, VEX completa la trasparenza della catena di fornitura del software. La distinta dei componenti dice cosa c’è dentro, la firma e la prova di provenienza dicono chi lo ha prodotto e che non è stato manomesso, e VEX dice quali, tra i difetti noti di ciò che c’è dentro, contano davvero. Senza questo terzo pezzo, gli obblighi di trasparenza che hanno spinto la diffusione delle SBOM rischiano di consegnare alle organizzazioni più rumore che sicurezza. Con VEX, la stessa distinta smette di essere un elenco che genera lavoro e diventa un’indicazione di rischio che lo riduce, restituendo alla trasparenza il significato che dovrebbe avere: non sapere tutto, ma sapere cosa conta.
