VEX: co říká dokument Vulnerability Exploitability eXchange

Co je VEX?

VEX, zkratka pro Vulnerability Exploitability eXchange, je strojově čitelné prohlášení o tom, zda je produkt dotčen konkrétní známou zranitelností. Dodavatel ho zveřejňuje, aby uživatelé produktu věděli, které zranitelnosti vyžadují zásah a které ne. Ve většině organizací tuto práci dodavatele zajišťuje tým pro reakci na bezpečnostní incidenty produktů (PSIRT).

Dokument CISA Minimum Requirements for VEX (duben 2023) ho definuje nezávisle na jakémkoli formátu souboru: VEX dokument je kontejner pro jedno nebo více prohlášení VEX a každé prohlášení uvádí jeden stav pro jednu zranitelnost v jednom nebo více produktech. VEX je navržen tak, aby fungoval se SBOM, databázemi zranitelností a bezpečnostními upozorněními, ale žádné z nich nepotřebuje.

Proč VEX existuje: šum ze SBOM

SBOM uvádí každou komponentu produktu, včetně tranzitivních závislostí. Skener tyto komponenty porovná s bezpečnostními upozorněními a nahlásí každou CVE v každé verzi, kterou najde. Mnoho z těchto nálezů neplatí: zranitelná funkce se nikdy nevolá, volba buildu ji při kompilaci vyřadí nebo konfigurace produktu útok zablokuje. Bez VEX to musí každý zákazník zjišťovat sám, nebo založit požadavek na podporu a zeptat se dodavatele.

VEX přesouvá tuto analýzu ke straně, která ji může provést jednou pro všechny: k dodavateli. Skener zákazníka přečte VEX dokument a potlačí nálezy, které dodavatel označil jako produkt neovlivňující.

VEX je jednou z několika pák. Stránka jak omezit šum zranitelností je řadí podle pořadí, počínaje inventářem, který odpovídá tomu, co dodáváte.

Čtyři stavy VEX

Každé prohlášení VEX nese právě jeden ze čtyř stavů:

Stav	Význam	Dále se vyžaduje
not_affected	Není potřeba žádná náprava ani zmírnění. Zranitelnost uvedené produkty neovlivňuje.	Zdůvodnění nebo prohlášení o dopadu, které vysvětluje proč
affected	Zranitelnost uvedené produkty ovlivňuje a autor doporučuje zásah.	Prohlášení o opatření: co mají uživatelé udělat
fixed	Uvedené verze produktu obsahují opravu.	Nic dalšího
under_investigation	Autor věc prošetřuje a zatím nerozhodl.	Nic dalšího; očekává se změna

Zdůvodnění VEX pro not_affected

Prohlášení not_affected musí uvést důvod. Požadavky CISA říkají, že BY MĚLO použít jedno z pěti zdůvodnění, a pokud tak neučiní, MUSÍ uvést volné textové prohlášení o dopadu. OpenVEX a CSAF používají stejných pět:

• component_not_present: zranitelná komponenta v produktu není obsažena.
• vulnerable_code_not_present: komponenta je obsažena, ale zranitelný kód ne, typicky kvůli tomu, jak byla nakonfigurována nebo sestavena.
• vulnerable_code_not_in_execute_path: zranitelný kód je přítomen, ale produkt ho nikdy nevolá.
• vulnerable_code_cannot_be_controlled_by_adversary: kód je přítomen a používá se, ale útočník ho nemůže ovládnout tak, aby zranitelnost zneužil.
• inline_mitigations_already_exist: zneužití brání vestavěné ochrany, které uživatelé nemohou vypnout.

Zdůvodnění se liší v tom, jaké důkazy potřebují. component_not_present potřebuje přesný záznam toho, co produkt obsahuje. Prostřední tři vyžadují analýzu kódu, například analýzu dosažitelnosti nebo ruční revizi, a právě je zákazníci nejčastěji zpochybňují.

Co prohlášení VEX obsahuje

Minimální požadavky CISA uvádějí tyto prvky:

• Metadata dokumentu: ID dokumentu, verze, která se s každou změnou zvyšuje, autor (osoba nebo organizace, nikoli nástroj) a kdy byl dokument poprvé vydán a naposledy aktualizován.
• Údaje o produktu: jeden nebo více identifikátorů produktu, ideálně stejné identifikátory, jaké používá SBOM produktu, například package URL (purl). Prohlášení může také jmenovat podkomponentu, která zranitelnost nese.
• Údaje o zranitelnosti: jedno ID zranitelnosti na prohlášení, obvykle CVE, a popis nebo odkaz na něj.
• Stav se zdůvodněním, prohlášením o dopadu nebo prohlášením o opatření, které vyžaduje.
• Metadata prohlášení: ID, verze a časová razítka samotného prohlášení.

Ukázkový VEX dokument

Tento dokument OpenVEX říká, že produkt example-api 3.2.0 obsahuje zranitelnou verzi log4j-core, ale Log4Shell ho neovlivňuje, protože se zranitelná třída během buildu odstraňuje:

{
  "@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."
    }
  ]
}

Produkt i jeho podkomponenta jsou identifikovány pomocí package URL, takže je skener může porovnat s komponentami v SBOM produktu. Stejné prohlášení v CycloneDX nebo CSAF nese stejná fakta v jiné struktuře.

Formáty VEX: OpenVEX, CycloneDX VEX a CSAF VEX

VEX je soubor požadavků, nikoli formát souboru. CISA jmenuje tři formáty, které ho mohou nést, a nejsou zaměnitelné:

	OpenVEX	CycloneDX VEX	CSAF VEX
Co to je	Malý formát JSON vytvořený jen pro VEX	Sekce vulnerabilities dokumentu CycloneDX	Profil csaf_vex standardu bezpečnostních upozornění CSAF
Standard	Otevřená specifikace, v0.2.0	ECMA-424 (CycloneDX 1.6 a novější)	OASIS Standard (CSAF 2.0, 2022)
Stavy	Čtyři stavy VEX	Vlastní stavy analýzy: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Seznamy stavů produktu: known_not_affected, known_affected, fixed, under_investigation
Zdůvodnění	Pět zdůvodnění CISA	Devět vlastních, například code_not_reachable a requires_configuration	Pět zdůvodnění CISA, jako příznaky
Hodí se pro týmy, které	Chtějí co nejmenší soubor VEX	Už dodávají SBOM ve formátu CycloneDX	Už zveřejňují bezpečnostní upozornění CSAF
Čte Trivy	Ano	Ano, u skenů SBOM	Ano
Čte Grype	Ano	Neuvedeno	Ano

OpenVEX je nejlehčí: dokument s autorem, časovým razítkem, verzí a seznamem prohlášení. Jeho specifikace chápe VEX jako posloupnost prohlášení, z nichž každé přepisuje nebo doplňuje ta předchozí.

CycloneDX VEX používá stejnou strukturu vulnerabilities, jakou CycloneDX používá pro vše ostatní, s objektem analysis, který obsahuje stav, zdůvodnění, hodnoty reakce jako update nebo will_not_fix a volný textový popis. Data VEX mohou být uvnitř SBOM nebo v samostatném dokumentu CycloneDX, který na SBOM odkazuje pomocí BOM-Link. Pozor: jeho slovník zdůvodnění není slovníkem CISA, takže převod do OpenVEX nebo CSAF či z nich vyžaduje mapování. Stranu SBOM popisuje CycloneDX vs SPDX.

CSAF VEX je plnohodnotný dokument CSAF s kategorií csaf_vex. Vyžaduje strom produktů, CVE nebo jiné ID, poznámky a pro každý produkt prohlášení o dopadu (pokud není dotčen) nebo nápravu (pokud dotčen je). Je těžší než OpenVEX, ale hodí se organizacím, které už distribuují bezpečnostní upozornění CSAF prostřednictvím poskytovatele CSAF.

VEX vs VDR

Vulnerability Disclosure Report (VDR) uvádí zranitelnosti, které produkt ovlivňují, spolu s jejich analýzou a nápravou. NIST SP 800-161 doporučuje VDR jako postup v dodavatelském řetězci a CycloneDX podporuje obojí. Rozdíl podle příkladů CycloneDX:

• VDR říká, které zranitelnosti produkt ovlivňují. Může zahrnovat i zranitelnosti nalezené ve vašem vlastním kódu, které nebyly nikde jinde zveřejněny.
• VEX je hlavně negativní prohlášení: které známé zranitelnosti produkt neovlivňují a proč. Pokrývá jen známé zranitelnosti.

Mnoho dodavatelů zveřejňuje obojí: VDR odpovídá na otázku „co musím opravit“, VEX na otázku „co mohu ignorovat“.

Jak skenery VEX používají

VEX dokument ušetří práci jen tehdy, když ho nástroje zákazníka čtou. Dva široce používané open source skenery to umí:

• Trivy přijímá VEX přes svou volbu --vex (označenou jako experimentální) z lokálního souboru, repozitáře VEX, atestace OCI nebo odkazu v SBOM. Čte OpenVEX, CycloneDX VEX u skenů SBOM a CSAF VEX a přestane hlásit zranitelnosti označené not_affected.
• Grype přijímá OpenVEX a CSAF VEX přes --vex. Shody not_affected a fixed přesouvá do seznamu ignorovaných, který zobrazí --show-suppressed, a volitelně může do výsledků přidat prohlášení affected a under_investigation.

Párování závisí na identifikátorech. Pokud VEX jmenuje produkt jiným identifikátorem, než používá SBOM, skener je nedokáže propojit a nález zůstane.

Kdo VEX zveřejňuje

VEX obvykle pochází od dodavatele: výrobce softwaru, open source distribuce nebo výrobce zařízení, který produkt dodává. U dodavatele jde o úkol týmu PSIRT, součást stejného životního cyklu správy zranitelností, z něhož vznikají bezpečnostní upozornění a opravy. Red Hat například zveřejňuje dokumenty CSAF VEX ve vyhrazeném adresáři svého kanálu CSAF vedle svých bezpečnostních upozornění. Co inženýři PSIRT dělají každý den, popisuje stránka role PSIRT.

VEX píší i zákazníci pro vlastní potřebu: zaznamenávají rozhodnutí z triáže o produktu dodavatele, aby je jejich skener přestal hlásit. Předpisy jako EU Cyber Resilience Act požadují, aby výrobci řešili zranitelnosti v komponentách, které dodávají, a VEX je jedním ze způsobů, jak uživatelům sdělit, které z nich platí.

Jak udržovat VEX aktuální

• Stavy se mění. Prohlášení obvykle začíná jako under_investigation a končí jako not_affected, nebo jako affected a pak fixed. Zveřejněte každou změnu; CISA vyžaduje, aby se verze pokaždé zvýšila.
• Nová vydání potřebují nová prohlášení. Verdikt not_affected pro 3.2.0 neříká nic o 3.3.0. Ověřte ho znovu pokaždé, když se změní komponenta, její verze nebo konfigurace buildu.
• Udržujte VEX odděleně od SBOM. SBOM popisuje vydání a zůstává neměnná. VEX se po vydání dál mění, takže když ho zveřejníte jako samostatný dokument, nemusíte znovu vydávat SBOM.
• Zveřejňujte tam, kde nástroje hledají. Vedle SBOM, jako atestaci k image kontejneru nebo ve svém kanálu bezpečnostních upozornění, a ve své politice zveřejňování uveďte kde. Podívejte se na koordinované zveřejňování zranitelností.

Limity VEX

• Je to tvrzení, ne důkaz. Prohlášení not_affected je hodnocení autora. CISA doporučuje kryptograficky svázat identitu autora s dokumentem, ale většina příjemců VEX stále věří, protože věří dodavateli.
• Mlčení nic neznamená. VEX neimplikuje žádný výchozí stav. Zranitelnost bez prohlášení je neznámá, ne neškodná.
• Formáty si neodpovídají jedna ku jedné. CycloneDX používá jiné stavy a zdůvodnění než OpenVEX a CSAF, takže převody ztrácejí podrobnosti.
• Je jen tak dobrý jako inventář. Tvrdit, že komponenta není přítomna, vyžaduje přesně vědět, co produkt obsahuje, včetně tranzitivních závislostí a všeho, co build stáhl mimo správce balíčků.

VEX začíná přesnou SBOM

Každé prohlášení VEX odkazuje na komponenty a nejsnáze obhajitelné zdůvodnění, component_not_present, platí jen tehdy, když je inventář úplný. SBOM vygenerovaná dodatečným skenováním lockfilů může uvádět vývojové závislosti, které se nikdy nedodávají, a přehlédnout balíčky, které build stáhl jinou cestou.

CRACI spouští buildy GitHub Actions na vlastních runnerech a zaznamenává balíčky, které každý job skutečně stáhl, včetně tranzitivních závislostí, balíčků obnovených z cache a závislostí, které neuvádí žádný lockfile. Každá SBOM nese stav úplnosti a exportuje se ve formátu CycloneDX nebo SPDX. Monitorované SBOM se průběžně znovu vyhodnocují, historie buildů ukazuje, které dřívější buildy obsahovaly zranitelnou závislost, a CRACI podporuje VEX. Podívejte se na generování SBOM a sledování zranitelností.

VEX: časté dotazy

Co znamená zkratka VEX?

VEX znamená Vulnerability Exploitability eXchange. Je to strojově čitelné prohlášení o tom, zda je produkt dotčen konkrétní známou zranitelností, zveřejňované proto, aby uživatelé věděli, které nahlášené zranitelnosti vyžadují zásah.

Jaký je rozdíl mezi SBOM a VEX?

SBOM uvádí komponenty produktu. VEX říká, zda je daný produkt dotčen konkrétní zranitelností. SBOM se po vydání mění jen zřídka; prohlášení VEX se mění, jak dodavatel věc prošetřuje a opravuje. Proto se VEX obvykle zveřejňuje jako samostatný dokument, který na produkt odkazuje, a ne jako součást SBOM.

Jaké jsou čtyři stavy VEX?

not_affected, affected, fixed a under_investigation. Prohlášení not_affected potřebuje zdůvodnění nebo prohlášení o dopadu a prohlášení affected potřebuje prohlášení o opatření, které říká, co mají uživatelé udělat.

Jaký formát VEX mám použít?

Ten, který čtou vaši příjemci a jejich nástroje. OpenVEX je nejmenší a funguje s Trivy a Grype. CycloneDX VEX se hodí týmům, které už dodávají SBOM ve formátu CycloneDX. CSAF VEX se hodí organizacím, které už zveřejňují bezpečnostní upozornění CSAF, což je běžné u průmyslového a podnikového softwaru. Mnoho dodavatelů nakonec mezi nimi převádí.

Je VEX totéž co bezpečnostní upozornění?

Ne. Bezpečnostní upozornění vysvětluje zranitelnost, koho se týká a jak ji opravit, hlavně pro lidi. VEX je úzce vymezený, strojově čitelný stav pro každý produkt a zranitelnost, hlavně pro nástroje. Obojí často putuje spolu: standard CSAF má profil pro bezpečnostní upozornění i profil VEX.

Kdo píše VEX dokumenty?

Obvykle dodavatel produktu, často jeho tým pro reakci na bezpečnostní incidenty produktů (PSIRT), protože ví, jak je produkt sestaven a nakonfigurován. Minimální požadavky CISA dovolují psát VEX i třetím stranám a každý dokument musí uvádět svého autora.

Čtou skenery zranitelností VEX?

Několik ano. Trivy přijímá OpenVEX, CycloneDX a CSAF VEX přes volbu --vex a vyřazuje nálezy označené not_affected. Grype přijímá OpenVEX a CSAF VEX přes --vex a nálezy not_affected a fixed přesouvá do seznamu ignorovaných.