VEX: vad ett Vulnerability Exploitability eXchange-dokument säger

Vad är VEX?

VEX, kort för Vulnerability Exploitability eXchange, är ett maskinläsbart uttalande om huruvida en produkt berörs av en specifik känd sårbarhet. En leverantör publicerar det så att de som använder produkten vet vilka sårbarheter som kräver åtgärd och vilka som inte gör det. I de flesta organisationer ligger det arbetet hos incidentteamet för produktsäkerhet (PSIRT).

CISA:s Minimum Requirements for VEX (april 2023) definierar det oberoende av filformat: ett VEX-dokument är en behållare för ett eller flera VEX-uttalanden, och varje uttalande ger en status för en sårbarhet i en eller flera produkter. VEX är utformat för att fungera med SBOM:er, sårbarhetsdatabaser och säkerhetsmeddelanden, men behöver inget av dem.

Varför VEX finns: bruset i SBOM:er

En SBOM listar varje komponent i en produkt, inklusive transitiva beroenden. En skanner matchar komponenterna mot säkerhetsmeddelanden och rapporterar varje CVE i varje version den hittar. Många av de fynden gäller inte: den sårbara funktionen anropas aldrig, ett byggalternativ kompilerar bort den, eller produktens konfiguration blockerar attacken. Utan VEX måste varje kund reda ut det själv, eller skapa ett supportärende och fråga leverantören.

VEX flyttar den analysen till den part som kan göra den en gång, för alla: leverantören. Kundens skanner läser VEX-dokumentet och undertrycker fynden som leverantören har markerat som att de inte berör produkten.

De fyra VEX-statusarna

Varje VEX-uttalande har exakt en av fyra statusar:

Status	Betydelse	Krävs också
not_affected	Ingen åtgärd eller begränsning krävs. Sårbarheten berör inte de listade produkterna.	En motivering, eller en påverkansbeskrivning som förklarar varför
affected	Sårbarheten berör de listade produkterna, och författaren rekommenderar åtgärd.	En åtgärdsbeskrivning: vad användarna ska göra
fixed	De listade produktversionerna innehåller en åtgärd.	Inget extra
under_investigation	Författaren utreder och har ännu inte bestämt sig.	Inget extra; förväntas ändras

VEX-motiveringar för not_affected

Ett not_affected-uttalande måste ange varför. Enligt CISA:s krav BÖR det använda en av fem motiveringar och MÅSTE ge en påverkansbeskrivning i fritext om det inte gör det. OpenVEX och CSAF använder samma fem:

• component_not_present: den sårbara komponenten ingår inte i produkten.
• vulnerable_code_not_present: komponenten ingår, men den sårbara koden gör det inte, oftast på grund av hur den konfigurerades eller byggdes.
• vulnerable_code_not_in_execute_path: den sårbara koden finns men produkten anropar den aldrig.
• vulnerable_code_cannot_be_controlled_by_adversary: koden finns och används, men en angripare kan inte styra den för att utnyttja sårbarheten.
• inline_mitigations_already_exist: inbyggda skydd som användare inte kan stänga av förhindrar utnyttjande.

Motiveringarna skiljer sig i vilka bevis de kräver. component_not_present kräver en korrekt registrering av vad produkten innehåller. De tre mellersta kräver kodanalys, till exempel reachability-analys eller en manuell granskning, och är de som kunder oftast ifrågasätter.

Vad ett VEX-uttalande innehåller

CISA:s minimikrav listar följande element:

• Dokumentmetadata: ett dokument-id, en version som ökar vid varje ändring, författaren (en person eller organisation, inte ett verktyg) och när det först utfärdades och senast uppdaterades.
• Produktuppgifter: en eller flera produktidentifierare, helst samma identifierare som produktens SBOM använder, till exempel en package URL (purl). Ett uttalande kan också namnge underkomponenten som bär på sårbarheten.
• Sårbarhetsuppgifter: ett sårbarhets-id per uttalande, oftast en CVE, och en beskrivning eller en länk till en.
• Status, med den motivering, påverkansbeskrivning eller åtgärdsbeskrivning som krävs.
• Metadata för uttalandet: ett id, en version och tidsstämplar för själva uttalandet.

Ett exempel på ett VEX-dokument

Det här OpenVEX-dokumentet säger att en produkt, example-api 3.2.0, levereras med en sårbar version av log4j-core men inte berörs av Log4Shell, eftersom den sårbara klassen tas bort 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."
    }
  ]
}

Produkten och dess underkomponent identifieras med package URL:er, så att en skanner kan matcha dem mot komponenterna i produktens SBOM. Samma uttalande i CycloneDX eller CSAF bär samma fakta i en annan struktur.

VEX-format: OpenVEX, CycloneDX VEX och CSAF VEX

VEX är en uppsättning krav, inte ett filformat. CISA namnger tre format som kan bära det, och de är inte utbytbara:

	OpenVEX	CycloneDX VEX	CSAF VEX
Vad det är	Ett litet JSON-format enbart för VEX	Sektionen vulnerabilities i ett CycloneDX-dokument	Profilen csaf_vex i standarden CSAF för säkerhetsmeddelanden
Standard	Öppen specifikation, v0.2.0	ECMA-424 (CycloneDX 1.6 och senare)	OASIS Standard (CSAF 2.0, 2022)
Statusar	De fyra VEX-statusarna	Egna analystillstånd: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Listor med produktstatus: known_not_affected, known_affected, fixed, under_investigation
Motiveringar	CISA:s fem motiveringar	Nio egna, till exempel code_not_reachable och requires_configuration	CISA:s fem motiveringar, som flaggor
Passar team som	Vill ha minsta möjliga VEX-fil	Redan levererar SBOM:er i CycloneDX	Redan publicerar säkerhetsmeddelanden i CSAF
Läses av Trivy	Ja	Ja, för SBOM-skanningar	Ja
Läses av Grype	Ja	Anges inte	Ja

OpenVEX är det lättaste: ett dokument med en författare, en tidsstämpel, en version och en lista med uttalanden. Dess specifikation behandlar VEX som en sekvens av uttalanden, där varje uttalande åsidosätter eller lägger till i de föregående.

CycloneDX VEX använder samma vulnerabilities-struktur som CycloneDX använder för allt annat, med ett analysis-objekt som innehåller ett tillstånd, en motivering, svarsvärden som update eller will_not_fix och detaljer i fritext. VEX-data kan ligga i SBOM:en eller i ett separat CycloneDX-dokument som pekar in i SBOM:en med BOM-Link. Observera att dess vokabulär för motiveringar inte är CISA:s, så konvertering till eller från OpenVEX eller CSAF kräver en mappning. Se CycloneDX vs SPDX för SBOM-sidan.

CSAF VEX är ett fullständigt CSAF-dokument med kategorin csaf_vex. Det kräver ett produktträd, en CVE eller ett annat id, anteckningar och för varje produkt en påverkansbeskrivning (om den inte berörs) eller en åtgärd (om den berörs). Det är tyngre än OpenVEX, men passar organisationer som redan distribuerar säkerhetsmeddelanden i CSAF via en CSAF-leverantör.

VEX och VDR

En Vulnerability Disclosure Report (VDR) listar de sårbarheter som faktiskt berör en produkt, tillsammans med deras analys och åtgärd. NIST SP 800-161 rekommenderar VDR:er som ett arbetssätt i leveranskedjan, och CycloneDX stöder båda. Skillnaden, enligt CycloneDX-exemplen:

• VDR anger vilka sårbarheter som berör produkten. Den kan täcka sårbarheter som hittats i din egen kod och aldrig publicerats någon annanstans.
• VEX är i huvudsak ett negativt uttalande: vilka kända sårbarheter som inte berör produkten, och varför. Det täcker bara kända sårbarheter.

Många leverantörer publicerar båda: VDR:en besvarar ”vad behöver jag åtgärda”, VEX besvarar ”vad kan jag ignorera”.

Så använder skannrar VEX

Ett VEX-dokument sparar bara arbete om kundens verktyg läser det. Två allmänt använda skannrar med öppen källkod gör det:

• Trivy tar emot VEX via sitt --vex-alternativ (markerat som experimentellt) från en lokal fil, ett VEX-repo, en OCI-attestering eller en referens i SBOM:en. Det läser OpenVEX, CycloneDX VEX för SBOM-skanningar och CSAF VEX, och slutar rapportera sårbarheter som markerats som not_affected.
• Grype tar emot OpenVEX och CSAF VEX via --vex. Det flyttar träffar med not_affected och fixed till en ignorerad lista, som visas med --show-suppressed, och kan som tillval lägga till uttalanden med affected och under_investigation i resultaten.

Matchningen är beroende av identifierare. Om VEX namnger produkten med en annan identifierare än SBOM:en använder kan skannern inte koppla ihop dem, och fyndet ligger kvar.

Vem publicerar VEX

VEX kommer oftast från leverantören: tillverkaren, open source-distributionen eller enhetstillverkaren som levererar produkten. Hos leverantören är det en uppgift för PSIRT, en del av samma livscykel för sårbarhetshantering som ger säkerhetsmeddelanden och åtgärder. Red Hat publicerar till exempel CSAF VEX-dokument i en särskild katalog i sitt CSAF-flöde, bredvid sina säkerhetsmeddelanden. För vad PSIRT-ingenjörer gör i vardagen, se rollen PSIRT.

Kunder skriver också VEX för eget bruk, för att registrera triageringsbeslut om en leverantörs produkt så att deras skanner slutar lyfta dem. Regelverk som EU:s Cyber Resilience Act kräver att tillverkare hanterar sårbarheter i komponenterna de levererar, och VEX är ett sätt att tala om för användare vilka av dem som gäller.

Så håller du VEX aktuellt

• Statusar ändras. Ett uttalande börjar oftast som under_investigation och slutar som not_affected, eller som affected och sedan fixed. Publicera varje ändring; CISA kräver att versionen ökar varje gång.
• Nya releaser behöver nya uttalanden. Ett not_affected-besked för 3.2.0 säger ingenting om 3.3.0. Kontrollera det på nytt när komponenten, dess version eller byggkonfigurationen ändras.
• Håll VEX åtskilt från SBOM:en. SBOM:en beskriver en release och förblir oförändrad. VEX fortsätter att ändras efter releasen, så om du publicerar det som ett eget dokument slipper du ge ut SBOM:er på nytt.
• Publicera där verktygen letar. Bredvid SBOM:en, som en attestering på containeravbilden eller i ditt flöde av säkerhetsmeddelanden, och ange var i din policy för offentliggörande. Se samordnat offentliggörande av sårbarheter.

Begränsningar i VEX

• Det är ett påstående, inte ett bevis. Ett not_affected-uttalande är författarens bedömning. CISA rekommenderar att författarens identitet knyts till dokumentet kryptografiskt, men de flesta konsumenter litar ändå på VEX för att de litar på leverantören.
• Tystnad betyder ingenting. VEX innebär ingen standardstatus. En sårbarhet utan uttalande är okänd, inte opåverkad.
• Formaten motsvarar inte varandra rakt av. CycloneDX använder andra tillstånd och motiveringar än OpenVEX och CSAF, så konverteringar tappar detaljer.
• Det är bara så bra som förteckningen. Att säga att en komponent inte finns kräver att du vet exakt vad produkten innehåller, inklusive transitiva beroenden och allt som bygget laddade ner utanför pakethanteraren.

VEX börjar med en korrekt SBOM

Varje VEX-uttalande pekar på komponenter, och den motivering som är lättast att försvara, component_not_present, stämmer bara om förteckningen är komplett. En SBOM som genereras genom att skanna lockfiler i efterhand kan lista utvecklingsberoenden som aldrig levereras och missa paket som bygget hämtade på något annat sätt.

CRACI kör GitHub Actions-byggen på sina egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från cachar och beroenden som ingen lockfile listar. Varje SBOM har en fullständighetsstatus och kan exporteras som CycloneDX eller SPDX. Bevakade SBOM:er omvärderas löpande, bygghistoriken visar vilka tidigare byggen som innehöll ett sårbart beroende, och CRACI har stöd för VEX. Se SBOM-generering och sårbarhetsspårning.

VEX: vanliga frågor

Vad står VEX för?

VEX står för Vulnerability Exploitability eXchange. Det är ett maskinläsbart uttalande om huruvida en produkt berörs av en specifik känd sårbarhet, publicerat så att användarna vet vilka rapporterade sårbarheter som kräver åtgärd.

Vad är skillnaden mellan en SBOM och VEX?

En SBOM listar komponenterna i en produkt. VEX anger, för en given sårbarhet, om produkten berörs. SBOM:en ändras sällan efter en release; VEX-uttalanden ändras i takt med att leverantören utreder och åtgärdar. Därför publiceras VEX oftast som ett separat dokument som hänvisar till produkten, i stället för att bakas in i SBOM:en.

Vilka är de fyra VEX-statusarna?

not_affected, affected, fixed och under_investigation. Ett not_affected-uttalande behöver en motivering eller en påverkansbeskrivning, och ett affected-uttalande behöver en åtgärdsbeskrivning som anger vad användarna ska göra.

Vilket VEX-format ska jag använda?

Använd det som dina konsumenter och verktyg läser. OpenVEX är minst och fungerar med Trivy och Grype. CycloneDX VEX passar team som redan levererar SBOM:er i CycloneDX. CSAF VEX passar organisationer som redan publicerar säkerhetsmeddelanden i CSAF, vilket är vanligt för industri- och företagsprogramvara. Många leverantörer slutar med att konvertera mellan dem.

Är VEX samma sak som ett säkerhetsmeddelande?

Nej. Ett säkerhetsmeddelande förklarar en sårbarhet, vilka som berörs och hur den åtgärdas, främst för människor. VEX är en snäv, maskinläsbar status per produkt och sårbarhet, främst för verktyg. De två följs ofta åt: standarden CSAF har både en profil för säkerhetsmeddelanden och en VEX-profil.

Vem skriver VEX-dokument?

Oftast produktens leverantör, ofta dess incidentteam för produktsäkerhet (PSIRT), eftersom det vet hur produkten är byggd och konfigurerad. CISA:s minimikrav tillåter också att tredje parter skriver VEX, och varje dokument måste ange sin författare.

Läser sårbarhetsskannrar VEX?

Flera gör det. Trivy tar emot OpenVEX, CycloneDX och CSAF VEX via sitt alternativ --vex och tar bort fynd som markerats som not_affected. Grype tar emot OpenVEX och CSAF VEX via --vex och flyttar fynd med not_affected och fixed till en ignorerad lista.