VEX: hvad et Vulnerability Exploitability eXchange-dokument siger

Hvad er VEX?

VEX, en forkortelse for Vulnerability Exploitability eXchange, er en maskinlæsbar erklæring om, hvorvidt et produkt er berørt af en bestemt kendt sårbarhed. En leverandør offentliggør den, så de, der bruger produktet, ved, hvilke sårbarheder der kræver handling, og hvilke der ikke gør. I de fleste organisationer ligger det arbejde hos leverandørens product security incident response team (PSIRT).

CISA's Minimum Requirements for VEX (april 2023) definerer det uafhængigt af ethvert filformat: Et VEX-dokument er en beholder for en eller flere VEX-erklæringer, og hver erklæring giver én status for én sårbarhed i et eller flere produkter. VEX er designet til at arbejde sammen med SBOM'er, sårbarhedsdatabaser og sikkerhedsadvisories, men kræver ingen af dem.

Derfor findes VEX: støj fra SBOM'er

En SBOM angiver hver komponent i et produkt, inklusive transitive afhængigheder. En scanner matcher de komponenter mod advisories og rapporterer hver CVE i hver version, den finder. Mange af de fund er ikke relevante: Den sårbare funktion bliver aldrig kaldt, en build-indstilling udelader den ved kompilering, eller produktets konfiguration blokerer angrebet. Uden VEX må hver kunde selv finde ud af det eller oprette en supportsag og spørge leverandøren.

VEX flytter den analyse til den part, der kan lave den én gang for alle kunder: leverandøren. Kundens scanner læser VEX-dokumentet og undertrykker de fund, leverandøren har markeret som ikke relevante for produktet.

De fire VEX-statusser

Hver VEX-erklæring har præcis én af fire statusser:

Status	Betydning	Kræver også
not_affected	Der kræves ingen rettelse eller afhjælpende foranstaltning. Sårbarheden berører ikke de angivne produkter.	En begrundelse eller en konsekvenserklæring, der forklarer hvorfor
affected	Sårbarheden berører de angivne produkter, og forfatteren anbefaler handling.	En handlingserklæring: hvad brugerne skal gøre
fixed	De angivne produktversioner indeholder en rettelse.	Intet ekstra
under_investigation	Forfatteren undersøger sagen og har endnu ikke besluttet sig.	Intet ekstra; forventes at ændre sig

VEX-begrundelser for not_affected

En not_affected-erklæring skal sige hvorfor. CISA's krav siger, at den BØR bruge en af fem begrundelser og SKAL give en konsekvenserklæring i fritekst, hvis den ikke gør det. OpenVEX og CSAF bruger de samme fem:

• component_not_present: Den sårbare komponent er ikke med i produktet.
• vulnerable_code_not_present: Komponenten er med, men den sårbare kode er ikke med, typisk på grund af den måde, den blev konfigureret eller bygget på.
• vulnerable_code_not_in_execute_path: Den sårbare kode er til stede, men produktet kalder den aldrig.
• vulnerable_code_cannot_be_controlled_by_adversary: Koden er til stede og bliver brugt, men en angriber kan ikke styre den for at udnytte sårbarheden.
• inline_mitigations_already_exist: Indbyggede beskyttelser, som brugerne ikke kan slå fra, forhindrer udnyttelse.

Begrundelserne adskiller sig ved, hvilken dokumentation de kræver. component_not_present kræver en præcis registrering af, hvad produktet indeholder. De tre midterste kræver kodeanalyse, for eksempel reachability-analyse eller en manuel gennemgang, og det er dem, kunderne oftest stiller spørgsmål ved.

Hvad en VEX-erklæring indeholder

CISA's minimumskrav angiver disse elementer:

• Dokumentmetadata: et dokument-id, en version, der stiger ved hver ændring, forfatteren (en person eller organisation, ikke et værktøj), og hvornår det først blev udstedt og sidst opdateret.
• Produktoplysninger: en eller flere produktidentifikatorer, helst de samme identifikatorer, som produktets SBOM bruger, for eksempel en package URL (purl). En erklæring kan også nævne den underkomponent, der indeholder sårbarheden.
• Sårbarhedsoplysninger: ét sårbarheds-id pr. erklæring, som regel en CVE, og en beskrivelse eller et link til en.
• Status, med den begrundelse, konsekvenserklæring eller handlingserklæring, den kræver.
• Erklæringsmetadata: et id, en version og tidsstempler for selve erklæringen.

Et eksempel på et VEX-dokument

Dette OpenVEX-dokument siger, at et produkt, example-api 3.2.0, leverer en sårbar version af log4j-core, men ikke er berørt af Log4Shell, fordi den sårbare klasse fjernes under buildet:

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

Produktet og dets underkomponent er identificeret med package URL'er, så en scanner kan matche dem mod komponenterne i produktets SBOM. Den samme erklæring i CycloneDX eller CSAF indeholder de samme fakta i en anden struktur.

VEX-formater: OpenVEX, CycloneDX VEX og CSAF VEX

VEX er et sæt krav, ikke et filformat. CISA nævner tre formater, der kan bære det, og de kan ikke erstatte hinanden:

	OpenVEX	CycloneDX VEX	CSAF VEX
Hvad det er	Et lille JSON-format lavet kun til VEX	vulnerabilities-sektionen i et CycloneDX-dokument	csaf_vex-profilen i advisory-standarden CSAF
Standard	Åben specifikation, v0.2.0	ECMA-424 (CycloneDX 1.6 og nyere)	OASIS Standard (CSAF 2.0, 2022)
Statusser	De fire VEX-statusser	Egne analysetilstande: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Lister over produktstatus: known_not_affected, known_affected, fixed, under_investigation
Begrundelser	De fem CISA-begrundelser	Ni egne, for eksempel code_not_reachable og requires_configuration	De fem CISA-begrundelser, som flag
Passer til teams, der	Vil have den mindst mulige VEX-fil	Allerede leverer CycloneDX-SBOM'er	Allerede offentliggør CSAF-sikkerhedsadvisories
Læses af Trivy	Ja	Ja, ved SBOM-scanninger	Ja
Læses af Grype	Ja	Ikke angivet	Ja

OpenVEX er det letteste: et dokument med en forfatter, et tidsstempel, en version og en liste over erklæringer. Dets specifikation behandler VEX som en række erklæringer, hvor hver enkelt tilsidesætter eller supplerer de foregående.

CycloneDX VEX bruger den samme vulnerabilities-struktur, som CycloneDX bruger til alt andet, med et analysis-objekt, der indeholder en tilstand, en begrundelse, responsværdier som update eller will_not_fix og detaljer i fritekst. VEX-dataene kan ligge inde i SBOM'en eller i et separat CycloneDX-dokument, der peger ind i SBOM'en med BOM-Link. Bemærk, at dets ordforråd for begrundelser ikke er CISA's, så konvertering til eller fra OpenVEX eller CSAF kræver en mapping. Se CycloneDX vs SPDX for SBOM-siden.

CSAF VEX er et fuldt CSAF-dokument med kategorien csaf_vex. Det kræver et produkttræ, en CVE eller et andet id, noter og for hvert produkt en konsekvenserklæring (hvis ikke berørt) eller en afhjælpning (hvis berørt). Det er tungere end OpenVEX, men passer til organisationer, der allerede distribuerer CSAF-advisories via en CSAF-udbyder.

VEX vs VDR

En Vulnerability Disclosure Report (VDR) angiver de sårbarheder, der faktisk berører et produkt, sammen med deres analyse og afhjælpning. NIST SP 800-161 anbefaler VDR'er som praksis for forsyningskæden, og CycloneDX understøtter begge. Forskellen er ifølge CycloneDX-eksemplerne denne:

• VDR siger, hvilke sårbarheder der berører produktet. Den kan dække sårbarheder fundet i din egen kode, som aldrig er offentliggjort andre steder.
• VEX er primært en negativ erklæring: hvilke kendte sårbarheder der ikke berører produktet, og hvorfor. Den dækker kun kendte sårbarheder.

Mange leverandører offentliggør begge: VDR'en svarer på "hvad skal jeg rette", VEX svarer på "hvad kan jeg ignorere".

Sådan bruger scannere VEX

Et VEX-dokument sparer kun arbejde, hvis kundens værktøjer læser det. To meget brugte open source-scannere gør det:

• Trivy tager VEX via sin --vex-indstilling (markeret som eksperimentel) fra en lokal fil, et VEX-repository, en OCI-attestation eller en reference i SBOM'en. Det læser OpenVEX, CycloneDX VEX ved SBOM-scanninger og CSAF VEX og holder op med at rapportere sårbarheder markeret som not_affected.
• Grype tager OpenVEX og CSAF VEX via --vex. Det flytter not_affected- og fixed-match til en liste over ignorerede, som vises med --show-suppressed, og kan valgfrit tilføje erklæringer med affected og under_investigation til resultaterne.

Matchning afhænger af identifikatorer. Navngiver VEX produktet med en anden identifikator, end SBOM'en bruger, kan scanneren ikke forbinde dem, og fundet bliver stående.

Hvem offentliggør VEX

VEX kommer som regel fra leverandøren: den virksomhed, open source-distribution eller enhedsproducent, der leverer produktet. Hos leverandøren er det en PSIRT-opgave, en del af den samme livscyklus for sårbarhedsstyring, der producerer advisories og rettelser. Red Hat offentliggør for eksempel CSAF VEX-dokumenter i en dedikeret mappe i sit CSAF-feed ved siden af sine advisories. Hvad PSIRT-ingeniører laver i det daglige, kan du se under PSIRT-rollen.

Kunder skriver også VEX til eget brug og registrerer triage-beslutninger om en leverandørs produkt, så deres scanner holder op med at rapportere dem. Lovgivning som EU's Cyber Resilience Act kræver, at producenter håndterer sårbarheder i de komponenter, de leverer, og VEX er én måde at fortælle brugerne, hvilke af dem der gælder.

Sådan holder du VEX opdateret

• Statusser flytter sig. En erklæring starter typisk som under_investigation og ender som not_affected eller som affected og derefter fixed. Offentliggør hver ændring; CISA kræver, at versionen stiger hver gang.
• Nye releases kræver nye erklæringer. En not_affected-vurdering for 3.2.0 siger intet om 3.3.0. Tjek den igen, hver gang komponenten, dens version eller build-konfigurationen ændrer sig.
• Hold VEX adskilt fra SBOM'en. SBOM'en beskriver en release og ligger fast. VEX bliver ved med at ændre sig efter releasen, så når du offentliggør det som sit eget dokument, undgår du at genudstede SBOM'er.
• Offentliggør, hvor værktøjerne kigger. Ved siden af SBOM'en, som en attestation på container-imaget eller i dit advisory-feed, og oplys i din disclosure-politik, hvor. Se koordineret offentliggørelse af sårbarheder.

VEX' begrænsninger

• Det er en påstand, ikke et bevis. En not_affected-erklæring er forfatterens vurdering. CISA anbefaler at knytte forfatterens identitet kryptografisk til dokumentet, men de fleste brugere stoler stadig på VEX, fordi de stoler på leverandøren.
• Tavshed betyder intet. VEX indebærer ingen standardstatus. En sårbarhed uden erklæring er ukendt, og det betyder ikke, at produktet er uberørt.
• Formaterne passer ikke én til én. CycloneDX bruger andre tilstande og begrundelser end OpenVEX og CSAF, så der går detaljer tabt ved konvertering.
• Det er kun så godt som fortegnelsen. At sige, at en komponent ikke er til stede, kræver, at du ved præcis, hvad produktet indeholder, inklusive transitive afhængigheder og alt, hvad buildet downloadede uden om pakkehåndteringen.

VEX starter med en præcis SBOM

Hver VEX-erklæring peger på komponenter, og den letteste begrundelse at forsvare, component_not_present, er kun sand, hvis fortegnelsen er komplet. En SBOM genereret ved at scanne lockfiles bagefter kan angive udviklingsafhængigheder, der aldrig bliver leveret, og overse pakker, buildet hentede på anden vis.

CRACI kører GitHub Actions-builds på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra caches og afhængigheder, som ingen lockfile angiver. Hver SBOM har en fuldstændighedsstatus og kan eksporteres som CycloneDX eller SPDX. Overvågede SBOM'er genvurderes løbende, build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, og CRACI understøtter VEX. Se SBOM-generering og sårbarhedssporing.

VEX: ofte stillede spørgsmål

Hvad står VEX for?

VEX står for Vulnerability Exploitability eXchange. Det er en maskinlæsbar erklæring om, hvorvidt et produkt er berørt af en bestemt kendt sårbarhed, offentliggjort så brugerne ved, hvilke rapporterede sårbarheder der kræver handling.

Hvad er forskellen på en SBOM og VEX?

En SBOM angiver komponenterne i et produkt. VEX siger for en given sårbarhed, om produktet er berørt. SBOM'en ændrer sig sjældent efter en release; VEX-erklæringer ændrer sig, efterhånden som leverandøren undersøger og retter. Derfor offentliggøres VEX som regel som et separat dokument, der henviser til produktet, i stedet for at blive bygget ind i SBOM'en.

Hvad er de fire VEX-statusser?

not_affected, affected, fixed og under_investigation. En not_affected-erklæring kræver en begrundelse eller en konsekvenserklæring, og en affected-erklæring kræver en handlingserklæring, der siger, hvad brugerne skal gøre.

Hvilket VEX-format skal jeg bruge?

Brug det, dine modtagere og værktøjer læser. OpenVEX er det mindste og virker med Trivy og Grype. CycloneDX VEX passer til teams, der allerede leverer CycloneDX-SBOM'er. CSAF VEX passer til organisationer, der allerede offentliggør CSAF-sikkerhedsadvisories, hvilket er almindeligt i industri- og enterprise-software. Mange leverandører ender med at konvertere mellem dem.

Er VEX det samme som en sikkerhedsadvisory?

Nej. En sikkerhedsadvisory forklarer en sårbarhed, hvem der er berørt, og hvordan den rettes, primært for mennesker. VEX er en snæver, maskinlæsbar status pr. produkt og sårbarhed, primært for værktøjer. De to følges ofte ad: Standarden CSAF har både en profil for sikkerhedsadvisories og en VEX-profil.

Hvem skriver VEX-dokumenter?

Som regel produktets leverandør, ofte dets product security incident response team (PSIRT), fordi det ved, hvordan produktet er bygget og konfigureret. CISA's minimumskrav tillader også tredjeparter at skrive VEX, og hvert dokument skal angive sin forfatter.

Læser sårbarhedsscannere VEX?

Flere gør det. Trivy accepterer OpenVEX, CycloneDX og CSAF VEX via sin --vex-indstilling og fjerner fund markeret som not_affected. Grype accepterer OpenVEX og CSAF VEX via --vex og flytter not_affected- og fixed-fund til en liste over ignorerede.