VEX: dette sier et Vulnerability Exploitability eXchange-dokument

Hva er VEX?

VEX, kort for Vulnerability Exploitability eXchange, er en maskinlesbar erklæring om hvorvidt et produkt er berørt av en bestemt kjent sårbarhet. En leverandør publiserer den, slik at de som bruker produktet, vet hvilke sårbarheter som krever tiltak, og hvilke som ikke gjør det. I de fleste organisasjoner ligger dette leverandørarbeidet hos product security incident response team (PSIRT).

CISAs Minimum Requirements for VEX (april 2023) definerer det uavhengig av filformat: Et VEX-dokument er en beholder for én eller flere VEX-erklæringer, og hver erklæring gir én status for én sårbarhet i ett eller flere produkter. VEX er laget for å fungere med SBOM-er, sårbarhetsdatabaser og sikkerhetsadvisories, men er ikke avhengig av noen av dem.

Derfor finnes VEX: støy fra SBOM-er

En SBOM lister opp hver komponent i et produkt, inkludert transitive avhengigheter. En skanner matcher disse komponentene mot advisories og rapporterer hver CVE i hver versjon den finner. Mange av disse funnene gjelder ikke: Den sårbare funksjonen blir aldri kalt, et byggealternativ kompilerer den bort, eller konfigurasjonen av produktet blokkerer angrepet. Uten VEX må hver kunde finne ut av dette alene, eller opprette en supportsak og spørre leverandøren.

VEX flytter analysen til den parten som kan gjøre den én gang, for alle: leverandøren. Skanneren til kunden leser VEX-dokumentet og undertrykker funnene leverandøren har angitt at ikke berører produktet.

De fire VEX-statusene

Hver VEX-erklæring har nøyaktig én av fire statuser:

Status	Betydning	Dette kreves også
not_affected	Ingen utbedring eller avbøtende tiltak er nødvendig. Sårbarheten berører ikke de oppførte produktene.	En begrunnelse, eller en konsekvenserklæring som forklarer hvorfor
affected	Sårbarheten berører de oppførte produktene, og forfatteren anbefaler tiltak.	En tiltakserklæring: hva brukerne bør gjøre
fixed	De oppførte produktversjonene inneholder en retting.	Ikke noe mer
under_investigation	Forfatteren undersøker saken og har ennå ikke bestemt seg.	Ikke noe mer; forventes å endre seg

VEX-begrunnelser for not_affected

En not_affected-erklæring må si hvorfor. Ifølge CISAs krav BØR den bruke én av fem begrunnelser, og MÅ gi en konsekvenserklæring i fritekst hvis den ikke gjør det. OpenVEX og CSAF bruker de samme fem:

• component_not_present: Den sårbare komponenten er ikke med i produktet.
• vulnerable_code_not_present: Komponenten er med, men den sårbare koden er det ikke, typisk på grunn av hvordan den ble konfigurert eller bygget.
• vulnerable_code_not_in_execute_path: Den sårbare koden er til stede, men produktet kaller den aldri.
• vulnerable_code_cannot_be_controlled_by_adversary: Koden er til stede og i bruk, men en angriper kan ikke kontrollere den for å utnytte sårbarheten.
• inline_mitigations_already_exist: Innebygde beskyttelser som brukere ikke kan slå av, hindrer utnyttelse.

Begrunnelsene skiller seg i hvilke bevis de krever. component_not_present krever en nøyaktig oversikt over hva produktet inneholder. De tre i midten krever kodeanalyse, for eksempel reachability-analyse eller en manuell gjennomgang, og det er disse kundene oftest stiller spørsmål ved.

Hva en VEX-erklæring inneholder

CISAs minimumskrav lister opp disse elementene:

• Dokumentmetadata: en dokument-ID, en versjon som øker ved hver endring, forfatteren (en person eller organisasjon, ikke et verktøy) og når det først ble utstedt og sist oppdatert.
• Produktdetaljer: én eller flere produktidentifikatorer, helst de samme identifikatorene som SBOM-en til produktet bruker, for eksempel en package URL (purl). En erklæring kan også navngi underkomponenten som har sårbarheten.
• Sårbarhetsdetaljer: én sårbarhets-ID per erklæring, vanligvis en CVE, og en beskrivelse eller en lenke til en.
• Status, med begrunnelsen, konsekvenserklæringen eller tiltakserklæringen den krever.
• Erklæringsmetadata: en ID, en versjon og tidsstempler for selve erklæringen.

Et eksempel på et VEX-dokument

Dette OpenVEX-dokumentet sier at et produkt, example-api 3.2.0, leverer en sårbar versjon av log4j-core, men ikke er berørt av Log4Shell, fordi den sårbare klassen fjernes under bygget:

{
  "@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 underkomponenten identifiseres med package URL-er, så en skanner kan matche dem mot komponentene i SBOM-en til produktet. Den samme erklæringen i CycloneDX eller CSAF inneholder de samme fakta i en annen struktur.

VEX-formater: OpenVEX, CycloneDX VEX og CSAF VEX

VEX er et sett krav, ikke et filformat. CISA nevner tre formater som kan bære det, og de kan ikke byttes ut med hverandre:

	OpenVEX	CycloneDX VEX	CSAF VEX
Hva det er	Et lite JSON-format laget bare for VEX	vulnerabilities-seksjonen i et CycloneDX-dokument	csaf_vex-profilen i advisory-standarden CSAF
Standard	Åpen spesifikasjon, v0.2.0	ECMA-424 (CycloneDX 1.6 og senere)	OASIS Standard (CSAF 2.0, 2022)
Statuser	De fire VEX-statusene	Egne analysetilstander: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Lister over produktstatus: known_not_affected, known_affected, fixed, under_investigation
Begrunnelser	De fem CISA-begrunnelsene	Ni egne, for eksempel code_not_reachable og requires_configuration	De fem CISA-begrunnelsene, som flagg
Passer for team som	Vil ha en så liten VEX-fil som mulig	Allerede leverer CycloneDX-SBOM-er	Allerede publiserer sikkerhetsadvisories i CSAF
Leses av Trivy	Ja	Ja, for SBOM-skanninger	Ja
Leses av Grype	Ja	Ikke oppført	Ja

OpenVEX er det letteste: et dokument med en forfatter, et tidsstempel, en versjon og en liste over erklæringer. Spesifikasjonen behandler VEX som en sekvens av erklæringer, der hver av dem overstyrer eller utfyller de foregående.

CycloneDX VEX bruker den samme vulnerabilities-strukturen som CycloneDX bruker til alt annet, med et analysis-objekt som inneholder en tilstand, en begrunnelse, responsverdier som update eller will_not_fix og detaljer i fritekst. VEX-dataene kan ligge inne i SBOM-en eller i et separat CycloneDX-dokument som peker inn i SBOM-en med BOM-Link. Merk at begrunnelsesvokabularet ikke er det samme som CISAs, så konvertering til eller fra OpenVEX eller CSAF krever en tilordning. Se CycloneDX vs. SPDX for SBOM-siden.

CSAF VEX er et fullstendig CSAF-dokument med kategorien csaf_vex. Det krever et produkttre, en CVE eller annen ID, notater og for hvert produkt en konsekvenserklæring (hvis ikke berørt) eller en utbedring (hvis berørt). Det er tyngre enn OpenVEX, men passer for organisasjoner som allerede distribuerer CSAF-advisories gjennom en CSAF-leverandør.

VEX vs. VDR

En Vulnerability Disclosure Report (VDR) lister opp sårbarhetene som faktisk berører et produkt, sammen med analyse og utbedring. NIST SP 800-161 anbefaler VDR-er som praksis for leverandørkjeden, og CycloneDX støtter begge. Forskjellen, slik CycloneDX-eksemplene forklarer den:

• VDR sier hvilke sårbarheter som berører produktet. Den kan dekke sårbarheter funnet i din egen kode som aldri er publisert andre steder.
• VEX er hovedsakelig en negativ erklæring: hvilke kjente sårbarheter som ikke berører produktet, og hvorfor. Den dekker bare kjente sårbarheter.

Mange leverandører publiserer begge: VDR-en svarer på «hva må jeg rette», VEX svarer på «hva kan jeg ignorere».

Slik bruker skannere VEX

Et VEX-dokument sparer bare arbeid hvis verktøyene til kunden leser det. To mye brukte skannere med åpen kildekode gjør det:

• Trivy tar imot VEX gjennom --vex-alternativet (merket som eksperimentelt) fra en lokal fil, et VEX-repositorium, en OCI-attestasjon eller en referanse i SBOM-en. Det leser OpenVEX, CycloneDX VEX for SBOM-skanninger og CSAF VEX, og slutter å rapportere sårbarheter merket not_affected.
• Grype tar imot OpenVEX og CSAF VEX gjennom --vex. Det flytter treff med not_affected og fixed til en liste over ignorerte funn, som vises med --show-suppressed, og kan eventuelt legge til erklæringer med affected og under_investigation i resultatene.

Matching avhenger av identifikatorer. Hvis VEX navngir produktet med en annen identifikator enn SBOM-en bruker, kan skanneren ikke koble dem sammen, og funnet blir stående.

Hvem publiserer VEX

VEX kommer vanligvis fra leverandøren: selskapet, distribusjonen med åpen kildekode eller enhetsprodusenten som leverer produktet. Hos leverandøren er det en PSIRT-oppgave, en del av den samme livssyklusen for sårbarhetshåndtering som produserer advisories og rettinger. Red Hat publiserer for eksempel CSAF VEX-dokumenter i en egen katalog i CSAF-feeden sin, ved siden av advisoryene. Hva PSIRT-ingeniører gjør til daglig, ser du under PSIRT-rollen.

Kunder skriver også VEX til eget bruk og registrerer triage-beslutninger om en leverandørs produkt, så skanneren deres slutter å flagge dem. Regelverk som EUs Cyber Resilience Act ber produsenter håndtere sårbarheter i komponentene de leverer, og VEX er én måte å fortelle brukere hvilke av dem som gjelder.

Slik holder du VEX oppdatert

• Statuser endrer seg. En erklæring starter typisk som under_investigation og ender som not_affected, eller som affected og deretter fixed. Publiser hver endring; CISA krever at versjonen øker hver gang.
• Nye utgivelser trenger nye erklæringer. En not_affected-vurdering for 3.2.0 sier ingenting om 3.3.0. Sjekk den på nytt når komponenten, versjonen eller byggekonfigurasjonen endres.
• Hold VEX atskilt fra SBOM-en. SBOM-en beskriver en utgivelse og ligger fast. VEX fortsetter å endre seg etter utgivelsen, så å publisere det som et eget dokument gjør at du slipper å utstede SBOM-er på nytt.
• Publiser der verktøyene ser etter. Ved siden av SBOM-en, som en attestasjon på container-imaget eller i advisory-feeden din, og oppgi hvor i policyen for offentliggjøring. Se koordinert offentliggjøring av sårbarheter.

Begrensningene ved VEX

• Det er en påstand, ikke et bevis. En not_affected-erklæring er forfatterens vurdering. CISA anbefaler å knytte forfatterens identitet til dokumentet kryptografisk, men de fleste mottakere stoler fortsatt på VEX fordi de stoler på leverandøren.
• Stillhet betyr ingenting. VEX innebærer ingen standardstatus. En sårbarhet uten erklæring er ukjent, ikke uberørt.
• Formatene kan ikke overføres én til én. CycloneDX bruker andre tilstander og begrunnelser enn OpenVEX og CSAF, så konverteringer mister detaljer.
• Det er bare så godt som oversikten. For å si at en komponent ikke er til stede, må du vite nøyaktig hva produktet inneholder, inkludert transitive avhengigheter og alt bygget lastet ned utenfor pakkebehandleren.

VEX begynner med en nøyaktig SBOM

Hver VEX-erklæring peker på komponenter, og den begrunnelsen som er lettest å forsvare, component_not_present, er bare sann hvis oversikten er fullstendig. En SBOM generert ved å skanne lockfiler i etterkant kan liste opp utviklingsavhengigheter som aldri leveres, og gå glipp av pakker bygget hentet på andre måter.

CRACI kjører GitHub Actions-bygg på sine egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra cacher og avhengigheter som ingen lockfile lister opp. Hver SBOM har en fullstendighetsstatus og kan eksporteres som CycloneDX eller SPDX. Overvåkede SBOM-er vurderes på nytt kontinuerlig, byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, og CRACI støtter VEX. Se SBOM-generering og sårbarhetssporing.

VEX: ofte stilte spørsmål

Hva står VEX for?

VEX står for Vulnerability Exploitability eXchange. Det er en maskinlesbar erklæring om hvorvidt et produkt er berørt av en bestemt kjent sårbarhet, publisert slik at brukere vet hvilke rapporterte sårbarheter som krever tiltak.

Hva er forskjellen på en SBOM og VEX?

En SBOM lister opp komponentene i et produkt. VEX sier, for en gitt sårbarhet, om produktet er berørt. SBOM-en endres sjelden etter en utgivelse; VEX-erklæringer endres etter hvert som leverandøren undersøker og retter. Derfor publiseres VEX vanligvis som et eget dokument som viser til produktet, i stedet for å bakes inn i SBOM-en.

Hva er de fire VEX-statusene?

not_affected, affected, fixed og under_investigation. En not_affected-erklæring krever en begrunnelse eller en konsekvenserklæring, og en affected-erklæring krever en tiltakserklæring som sier hva brukerne bør gjøre.

Hvilket VEX-format bør jeg bruke?

Bruk det mottakerne og verktøyene dine leser. OpenVEX er det minste og fungerer med Trivy og Grype. CycloneDX VEX passer for team som allerede leverer CycloneDX-SBOM-er. CSAF VEX passer for organisasjoner som allerede publiserer sikkerhetsadvisories i CSAF, noe som er vanlig i industri- og bedriftsprogramvare. Mange leverandører ender opp med å konvertere mellom dem.

Er VEX det samme som en sikkerhetsadvisory?

Nei. En sikkerhetsadvisory forklarer en sårbarhet, hvem som er berørt, og hvordan den rettes, hovedsakelig for mennesker. VEX er en smal, maskinlesbar status per produkt og sårbarhet, hovedsakelig for verktøy. De to følger ofte hverandre: CSAF-standarden har både en profil for sikkerhetsadvisories og en VEX-profil.

Hvem skriver VEX-dokumenter?

Vanligvis leverandøren av produktet, ofte product security incident response team (PSIRT), fordi det vet hvordan produktet er bygget og konfigurert. CISAs minimumskrav tillater også at tredjeparter skriver VEX, og hvert dokument må navngi forfatteren.

Leser sårbarhetsskannere VEX?

Flere gjør det. Trivy godtar OpenVEX, CycloneDX og CSAF VEX gjennom --vex-alternativet og fjerner funn merket not_affected. Grype godtar OpenVEX og CSAF VEX gjennom --vex og flytter not_affected- og fixed-funn til en liste over ignorerte funn.