VEX: che cosa dice un documento Vulnerability Exploitability eXchange

Che cos'è VEX?

VEX, abbreviazione di Vulnerability Exploitability eXchange, è una dichiarazione leggibile da una macchina che indica se un prodotto è interessato da una specifica vulnerabilità nota. Un fornitore la pubblica affinché chi usa il prodotto sappia quali vulnerabilità richiedono un intervento e quali no. Nella maggior parte delle organizzazioni questo lavoro del fornitore spetta al product security incident response team (PSIRT).

I Minimum Requirements for VEX di CISA (aprile 2023) lo definiscono indipendentemente da qualsiasi formato di file: un documento VEX è un contenitore di una o più dichiarazioni VEX, e ogni dichiarazione assegna uno stato a una vulnerabilità in uno o più prodotti. VEX è progettato per funzionare con SBOM, database di vulnerabilità e advisory di sicurezza, ma non ha bisogno di nessuno di essi.

Perché esiste VEX: il rumore delle SBOM

Una SBOM elenca tutti i componenti di un prodotto, comprese le dipendenze transitive. Uno scanner confronta questi componenti con gli advisory e riporta ogni CVE in ogni versione che trova. Molti di questi risultati non sono pertinenti: la funzione vulnerabile non viene mai chiamata, un'opzione di build la esclude dalla compilazione o la configurazione del prodotto blocca l'attacco. Senza VEX, ogni cliente deve capirlo da solo, oppure aprire un ticket di assistenza per chiederlo al fornitore.

VEX sposta questa analisi sulla parte che può svolgerla una sola volta, per tutti: il fornitore. Lo scanner del cliente legge il documento VEX e sopprime i risultati che il fornitore ha contrassegnato come non pertinenti per il prodotto.

I quattro stati VEX

Ogni dichiarazione VEX riporta esattamente uno di questi quattro stati:

Stato	Significato	Richiesto inoltre
not_affected	Non è necessaria alcuna correzione o mitigazione. La vulnerabilità non riguarda i prodotti elencati.	Una giustificazione, o un impact statement che spieghi il motivo
affected	La vulnerabilità riguarda i prodotti elencati e l'autore raccomanda un intervento.	Un action statement: che cosa dovrebbero fare gli utenti
fixed	Le versioni di prodotto elencate contengono una correzione.	Niente di più
under_investigation	L'autore sta indagando e non ha ancora deciso.	Niente di più; è previsto che cambi

Giustificazioni VEX per not_affected

Una dichiarazione not_affected deve spiegare il perché. I requisiti di CISA stabiliscono che DOVREBBE usare una di cinque giustificazioni e che, in caso contrario, DEVE fornire un impact statement in testo libero. OpenVEX e CSAF usano le stesse cinque:

• component_not_present: il componente vulnerabile non è incluso nel prodotto.
• vulnerable_code_not_present: il componente è incluso, ma il codice vulnerabile no, di solito per il modo in cui è stato configurato o compilato.
• vulnerable_code_not_in_execute_path: il codice vulnerabile è presente, ma il prodotto non lo chiama mai.
• vulnerable_code_cannot_be_controlled_by_adversary: il codice è presente e usato, ma un attaccante non può controllarlo per sfruttare la vulnerabilità.
• inline_mitigations_already_exist: protezioni integrate che gli utenti non possono disattivare impediscono lo sfruttamento.

Le giustificazioni differiscono per le evidenze che richiedono. component_not_present richiede un registro accurato di ciò che il prodotto contiene. Le tre centrali richiedono un'analisi del codice, come l'analisi di raggiungibilità o una revisione manuale, e sono quelle che i clienti mettono più spesso in discussione.

Che cosa contiene una dichiarazione VEX

I requisiti minimi di CISA elencano questi elementi:

• Metadati del documento: un ID del documento, una versione che aumenta a ogni modifica, l'autore (una persona o un'organizzazione, non uno strumento) e quando è stato emesso per la prima volta e aggiornato per l'ultima.
• Dettagli del prodotto: uno o più identificatori di prodotto, idealmente gli stessi usati dalla SBOM del prodotto, come un package URL (purl). Una dichiarazione può anche indicare il sottocomponente che contiene la vulnerabilità.
• Dettagli della vulnerabilità: un ID di vulnerabilità per dichiarazione, di solito una CVE, e una descrizione o un link a una descrizione.
• Stato, con la giustificazione, l'impact statement o l'action statement che richiede.
• Metadati della dichiarazione: un ID, una versione e i timestamp della dichiarazione stessa.

Un esempio di documento VEX

Questo documento OpenVEX dice che un prodotto, example-api 3.2.0, distribuisce una versione vulnerabile di log4j-core ma non è interessato da Log4Shell, perché la classe vulnerabile viene rimossa durante la build:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

Il prodotto e il suo sottocomponente sono identificati da package URL, così uno scanner può confrontarli con i componenti della SBOM del prodotto. La stessa dichiarazione in CycloneDX o CSAF riporta gli stessi fatti con una struttura diversa.

Formati VEX: OpenVEX, CycloneDX VEX e CSAF VEX

VEX è un insieme di requisiti, non un formato di file. CISA indica tre formati che possono contenerlo, e non sono intercambiabili:

	OpenVEX	CycloneDX VEX	CSAF VEX
Che cos'è	Un piccolo formato JSON creato solo per VEX	La sezione vulnerabilities di un documento CycloneDX	Il profilo csaf_vex dello standard di advisory CSAF
Standard	Specifica aperta, v0.2.0	ECMA-424 (CycloneDX 1.6 e successivi)	OASIS Standard (CSAF 2.0, 2022)
Stati	I quattro stati VEX	I propri stati di analisi: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Elenchi di stato del prodotto: known_not_affected, known_affected, fixed, under_investigation
Giustificazioni	Le cinque giustificazioni CISA	Nove proprie, come code_not_reachable e requires_configuration	Le cinque giustificazioni CISA, come flag
Adatto ai team che	Vogliono il file VEX più piccolo possibile	Distribuiscono già SBOM CycloneDX	Pubblicano già advisory di sicurezza CSAF
Letto da Trivy	Sì	Sì, per le scansioni di SBOM	Sì
Letto da Grype	Sì	Non indicato	Sì

OpenVEX è il più leggero: un documento con un autore, un timestamp, una versione e un elenco di dichiarazioni. La sua specifica tratta VEX come una sequenza di dichiarazioni, ciascuna delle quali sostituisce o integra quelle precedenti.

CycloneDX VEX usa la stessa struttura vulnerabilities che CycloneDX usa per tutto il resto, con un oggetto analysis che contiene uno stato, una giustificazione, valori di risposta come update o will_not_fix e dettagli in testo libero. I dati VEX possono stare all'interno della SBOM o in un documento CycloneDX separato che punta alla SBOM con BOM-Link. Tenga presente che il suo vocabolario di giustificazioni non è quello di CISA, quindi la conversione da o verso OpenVEX o CSAF richiede una mappatura. Veda CycloneDX vs SPDX per il lato SBOM.

CSAF VEX è un documento CSAF completo con categoria csaf_vex. Richiede un product tree, una CVE o un altro ID, note e, per ogni prodotto, un impact statement (se non interessato) o una correzione (se interessato). È più pesante di OpenVEX, ma è adatto alle organizzazioni che distribuiscono già advisory CSAF tramite un provider CSAF.

VEX vs VDR

Un Vulnerability Disclosure Report (VDR) elenca le vulnerabilità che riguardano effettivamente un prodotto, insieme alla loro analisi e correzione. NIST SP 800-161 raccomanda i VDR come pratica per la supply chain, e CycloneDX supporta sia VEX sia VDR. La differenza, secondo gli esempi di CycloneDX:

• VDR dice quali vulnerabilità riguardano il prodotto. Può coprire vulnerabilità trovate nel Suo codice e mai pubblicate altrove.
• VEX è soprattutto una dichiarazione negativa: quali vulnerabilità note non riguardano il prodotto, e perché. Copre solo le vulnerabilità note.

Molti fornitori pubblicano entrambi: il VDR risponde a "che cosa devo correggere", il VEX a "che cosa posso ignorare".

Come gli scanner usano VEX

Un documento VEX fa risparmiare lavoro solo se gli strumenti del cliente lo leggono. Due scanner open source ampiamente usati lo fanno:

• Trivy acquisisce VEX tramite la sua opzione --vex (contrassegnata come sperimentale) da un file locale, da un repository VEX, da un'attestazione OCI o da un riferimento nella SBOM. Legge OpenVEX, CycloneDX VEX per le scansioni di SBOM e CSAF VEX, e smette di riportare le vulnerabilità contrassegnate come not_affected.
• Grype acquisisce OpenVEX e CSAF VEX tramite --vex. Sposta le corrispondenze not_affected e fixed in un elenco di elementi ignorati, mostrato con --show-suppressed, e può facoltativamente aggiungere ai risultati le dichiarazioni affected e under_investigation.

La corrispondenza dipende dagli identificatori. Se il VEX indica il prodotto con un identificatore diverso da quello usato dalla SBOM, lo scanner non può collegarli e il risultato resta.

Chi pubblica VEX

VEX proviene di solito dal fornitore: il vendor, la distribuzione open source o il produttore del dispositivo che distribuisce il prodotto. All'interno del fornitore è un compito del PSIRT, parte dello stesso ciclo di vita della gestione delle vulnerabilità che produce advisory e correzioni. Red Hat, ad esempio, pubblica documenti CSAF VEX in una directory dedicata del suo feed CSAF, accanto ai propri advisory. Per sapere che cosa fanno ogni giorno gli ingegneri PSIRT, veda il ruolo del PSIRT.

Anche i clienti scrivono VEX per uso proprio, registrando le decisioni di triage sul prodotto di un fornitore affinché il loro scanner smetta di segnalarle. Normative come il Cyber Resilience Act dell'UE chiedono ai fabbricanti di gestire le vulnerabilità nei componenti che distribuiscono, e VEX è un modo per indicare agli utenti quali sono pertinenti.

Mantenere VEX aggiornato

• Gli stati cambiano. Una dichiarazione di solito inizia come under_investigation e termina come not_affected, oppure come affected e poi fixed. Pubblichi ogni modifica; CISA richiede che la versione aumenti ogni volta.
• Le nuove release richiedono nuove dichiarazioni. Un verdetto not_affected per la 3.2.0 non dice nulla sulla 3.3.0. Lo ricontrolli ogni volta che cambiano il componente, la sua versione o la configurazione di build.
• Tenga VEX separato dalla SBOM. La SBOM descrive una release e resta fissa. VEX continua a cambiare dopo il rilascio, quindi pubblicarlo come documento a sé evita di riemettere le SBOM.
• Pubblichi dove gli strumenti guardano. Accanto alla SBOM, come attestazione sull'immagine container o nel Suo feed di advisory, e indichi dove nella Sua policy di divulgazione. Veda la divulgazione coordinata delle vulnerabilità.

I limiti di VEX

• È un'affermazione, non una prova. Una dichiarazione not_affected è la valutazione dell'autore. CISA raccomanda di legare crittograficamente l'identità dell'autore al documento, ma la maggior parte dei destinatari si fida di VEX perché si fida del fornitore.
• Il silenzio non significa nulla. VEX non implica alcuno stato predefinito. Una vulnerabilità senza dichiarazione è sconosciuta, non priva di effetti sul prodotto.
• I formati non corrispondono uno a uno. CycloneDX usa stati e giustificazioni diversi da OpenVEX e CSAF, quindi le conversioni perdono dettagli.
• Vale quanto l'inventario. Dire che un componente non è presente richiede di sapere esattamente che cosa contiene il prodotto, comprese le dipendenze transitive e tutto ciò che la build ha scaricato al di fuori del package manager.

VEX parte da una SBOM accurata

Ogni dichiarazione VEX rimanda a dei componenti, e la giustificazione più facile da difendere, component_not_present, è vera solo se l'inventario è completo. Una SBOM generata scansionando i lockfile a posteriori può elencare dipendenze di sviluppo che non vengono mai distribuite e non vedere i pacchetti che la build ha scaricato in altro modo.

CRACI esegue le build GitHub Actions sui propri runner e registra i pacchetti effettivamente scaricati da ciascun job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache e le dipendenze che nessun lockfile elenca. Ogni SBOM riporta uno stato di completezza e si esporta in CycloneDX o SPDX. Le SBOM monitorate vengono rivalutate di continuo, la cronologia delle build mostra quali build passate contenevano una dipendenza vulnerabile, e CRACI supporta VEX. Veda la generazione di SBOM e il monitoraggio delle vulnerabilità.

VEX: domande frequenti

Che cosa significa VEX?

VEX sta per Vulnerability Exploitability eXchange. È una dichiarazione leggibile da una macchina che indica se un prodotto è interessato da una specifica vulnerabilità nota, pubblicata affinché gli utenti sappiano quali vulnerabilità segnalate richiedono un intervento.

Qual è la differenza tra una SBOM e VEX?

Una SBOM elenca i componenti di un prodotto. VEX dice, per una data vulnerabilità, se quel prodotto è interessato. La SBOM cambia raramente dopo una release; le dichiarazioni VEX cambiano man mano che il fornitore indaga e corregge. Per questo VEX viene di solito pubblicato come documento separato che fa riferimento al prodotto, invece di essere incorporato nella SBOM.

Quali sono i quattro stati VEX?

not_affected, affected, fixed e under_investigation. Una dichiarazione not_affected richiede una giustificazione o un impact statement, e una dichiarazione affected richiede un action statement che indichi che cosa dovrebbero fare gli utenti.

Quale formato VEX dovrei usare?

Usi quello letto dai Suoi destinatari e dai loro strumenti. OpenVEX è il più piccolo e funziona con Trivy e Grype. CycloneDX VEX è adatto ai team che distribuiscono già SBOM CycloneDX. CSAF VEX è adatto alle organizzazioni che pubblicano già advisory di sicurezza CSAF, cosa comune nel software industriale ed enterprise. Molti fornitori finiscono per convertire da uno all'altro.

VEX è la stessa cosa di un advisory di sicurezza?

No. Un advisory di sicurezza spiega una vulnerabilità, chi è interessato e come correggerla, soprattutto per le persone. VEX è uno stato circoscritto e leggibile da una macchina per prodotto e vulnerabilità, soprattutto per gli strumenti. I due spesso viaggiano insieme: lo standard CSAF ha sia un profilo per gli advisory di sicurezza sia un profilo VEX.

Chi scrive i documenti VEX?

Di solito il fornitore del prodotto, spesso il suo product security incident response team (PSIRT), perché sa come il prodotto è compilato e configurato. I requisiti minimi di CISA consentono anche a terze parti di redigere VEX, e ogni documento deve indicare il proprio autore.

Gli scanner di vulnerabilità leggono VEX?

Diversi sì. Trivy accetta OpenVEX, CycloneDX e CSAF VEX tramite la sua opzione --vex ed elimina i risultati contrassegnati come not_affected. Grype accetta OpenVEX e CSAF VEX tramite --vex e sposta i risultati not_affected e fixed in un elenco di elementi ignorati.