VEX: wat een Vulnerability Exploitability eXchange-document zegt

Wat is VEX?

VEX, kort voor Vulnerability Exploitability eXchange, is een machineleesbare verklaring over de vraag of een product wordt getroffen door een specifieke bekende kwetsbaarheid. Een leverancier publiceert die zodat de gebruikers van het product weten welke kwetsbaarheden actie vragen en welke niet. In de meeste organisaties ligt dat werk bij het product security incident response team (PSIRT).

De Minimum Requirements for VEX van CISA (april 2023) definiëren het los van een bestandsformaat: een VEX-document is een container voor een of meer VEX-verklaringen, en elke verklaring geeft één status voor één kwetsbaarheid in een of meer producten. VEX is ontworpen om samen te werken met SBOM's, kwetsbaarheidsdatabases en security advisories, maar heeft geen daarvan nodig.

Waarom VEX bestaat: SBOM-ruis

Een SBOM vermeldt elk component in een product, inclusief transitieve afhankelijkheden. Een scanner vergelijkt die componenten met advisories en rapporteert elke CVE in elke versie die hij vindt. Veel van die bevindingen zijn niet van toepassing: de kwetsbare functie wordt nooit aangeroepen, een buildoptie compileert hem weg, of de configuratie van het product blokkeert de aanval. Zonder VEX moet elke klant dat zelf uitzoeken, of een supportticket bij de leverancier indienen.

VEX verplaatst die analyse naar de partij die hem één keer voor iedereen kan doen: de leverancier. De scanner van de klant leest het VEX-document en onderdrukt de bevindingen die de leverancier heeft gemarkeerd als niet van invloed op het product.

De vier VEX-statussen

Elke VEX-verklaring heeft precies een van de vier statussen:

Status	Betekenis	Ook vereist
not_affected	Er is geen herstel of mitigatie nodig. De kwetsbaarheid raakt de vermelde producten niet.	Een justificatie, of een impactverklaring die uitlegt waarom
affected	De kwetsbaarheid raakt de vermelde producten, en de auteur raadt actie aan.	Een actieverklaring: wat gebruikers moeten doen
fixed	De vermelde productversies bevatten een fix.	Niets extra's
under_investigation	De auteur doet onderzoek en heeft nog geen besluit genomen.	Niets extra's; zal naar verwachting veranderen

VEX-justificaties voor not_affected

Een not_affected-verklaring moet zeggen waarom. Volgens de eisen van CISA hoort die een van de vijf justificaties te gebruiken (SHOULD), en moet die anders een impactverklaring in vrije tekst geven (MUST). OpenVEX en CSAF gebruiken dezelfde vijf:

• component_not_present: het kwetsbare component zit niet in het product.
• vulnerable_code_not_present: het component zit erin, maar de kwetsbare code niet, meestal door de manier waarop het is geconfigureerd of gebouwd.
• vulnerable_code_not_in_execute_path: de kwetsbare code is aanwezig, maar het product roept die nooit aan.
• vulnerable_code_cannot_be_controlled_by_adversary: de code is aanwezig en wordt gebruikt, maar een aanvaller kan die niet aansturen om de kwetsbaarheid te misbruiken.
• inline_mitigations_already_exist: ingebouwde beschermingen die gebruikers niet kunnen uitschakelen, voorkomen misbruik.

De justificaties verschillen in het bewijs dat ze nodig hebben. component_not_present vraagt om een nauwkeurig record van wat het product bevat. De middelste drie vragen om codeanalyse, zoals reachability-analyse of een handmatige beoordeling, en dat zijn de justificaties die klanten het vaakst in twijfel trekken.

Wat een VEX-verklaring bevat

De minimumeisen van CISA noemen deze elementen:

• Documentmetadata: een document-ID, een versie die bij elke wijziging oploopt, de auteur (een persoon of organisatie, geen tool), en wanneer het document voor het eerst is uitgegeven en voor het laatst is bijgewerkt.
• Productgegevens: een of meer product-identifiers, bij voorkeur dezelfde die de SBOM van het product gebruikt, zoals een package-URL (purl). Een verklaring kan ook het subcomponent noemen dat de kwetsbaarheid bevat.
• Kwetsbaarheidsgegevens: één kwetsbaarheids-ID per verklaring, meestal een CVE, en een beschrijving of een link daarnaar.
• Status, met de justificatie, impactverklaring of actieverklaring die daarbij hoort.
• Metadata van de verklaring: een ID, een versie en timestamps voor de verklaring zelf.

Een voorbeeld van een VEX-document

Dit OpenVEX-document zegt dat een product, example-api 3.2.0, een kwetsbare versie van log4j-core bevat maar niet wordt getroffen door Log4Shell, omdat de kwetsbare klasse tijdens de build wordt verwijderd:

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

Het product en zijn subcomponent worden geïdentificeerd met package-URL's, zodat een scanner ze kan matchen met de componenten in de SBOM van het product. Dezelfde verklaring in CycloneDX of CSAF bevat dezelfde feiten in een andere structuur.

VEX-formaten: OpenVEX, CycloneDX VEX en CSAF VEX

VEX is een set eisen, geen bestandsformaat. CISA noemt drie formaten die het kunnen bevatten, en die zijn niet uitwisselbaar:

	OpenVEX	CycloneDX VEX	CSAF VEX
Wat het is	Een klein JSON-formaat dat alleen voor VEX is gemaakt	De sectie vulnerabilities van een CycloneDX-document	Het profiel csaf_vex van de CSAF-advisorystandaard
Standaard	Open specificatie, v0.2.0	ECMA-424 (CycloneDX 1.6 en later)	OASIS Standard (CSAF 2.0, 2022)
Statussen	De vier VEX-statussen	Eigen analysestatussen: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Lijsten met productstatussen: known_not_affected, known_affected, fixed, under_investigation
Justificaties	De vijf CISA-justificaties	Negen eigen justificaties, zoals code_not_reachable en requires_configuration	De vijf CISA-justificaties, als flags
Past bij teams die	Het kleinst mogelijke VEX-bestand willen	Al CycloneDX-SBOM's leveren	Al CSAF security advisories publiceren
Gelezen door Trivy	Ja	Ja, voor SBOM-scans	Ja
Gelezen door Grype	Ja	Niet vermeld	Ja

OpenVEX is het lichtst: een document met een auteur, een timestamp, een versie en een lijst verklaringen. De specificatie behandelt VEX als een reeks verklaringen, waarbij elke verklaring de vorige overschrijft of aanvult.

CycloneDX VEX gebruikt dezelfde vulnerabilities-structuur die CycloneDX voor al het andere gebruikt, met een analysis-object dat een status, een justificatie, responswaarden zoals update of will_not_fix en toelichting in vrije tekst bevat. De VEX-gegevens kunnen in de SBOM staan of in een apart CycloneDX-document dat met BOM-Link naar de SBOM verwijst. Let op: de justificaties zijn niet die van CISA, dus voor conversie van of naar OpenVEX of CSAF is een mapping nodig. Zie CycloneDX vs SPDX voor de SBOM-kant.

CSAF VEX is een volledig CSAF-document met de categorie csaf_vex. Het vereist een product tree, een CVE of ander ID, notities, en per product een impactverklaring (indien niet getroffen) of een herstelmaatregel (indien getroffen). Het is zwaarder dan OpenVEX, maar past bij organisaties die al CSAF-advisories via een CSAF-provider verspreiden.

VEX vs VDR

Een Vulnerability Disclosure Report (VDR) vermeldt de kwetsbaarheden die een product wel raken, samen met de analyse en het herstel ervan. NIST SP 800-161 beveelt VDR's aan als praktijk voor de softwareketen, en CycloneDX ondersteunt beide. Het verschil, volgens de CycloneDX-voorbeelden:

• VDR zegt welke kwetsbaarheden het product raken. Het kan ook kwetsbaarheden dekken die in uw eigen code zijn gevonden en nergens anders zijn gepubliceerd.
• VEX is vooral een negatieve verklaring: welke bekende kwetsbaarheden het product niet raken, en waarom. Het dekt alleen bekende kwetsbaarheden.

Veel leveranciers publiceren beide: de VDR beantwoordt "wat moet ik oplossen", de VEX beantwoordt "wat kan ik negeren".

Hoe scanners VEX verwerken

Een VEX-document bespaart alleen werk als de tools van de klant het lezen. Twee veelgebruikte open-sourcescanners doen dat:

• Trivy accepteert VEX via zijn --vex-optie (gemarkeerd als experimenteel) vanuit een lokaal bestand, een VEX-repository, een OCI-attestatie of een verwijzing in de SBOM. Het leest OpenVEX, CycloneDX VEX voor SBOM-scans en CSAF VEX, en rapporteert kwetsbaarheden die als not_affected zijn gemarkeerd, niet meer.
• Grype accepteert OpenVEX en CSAF VEX via --vex. Het verplaatst not_affected- en fixed-matches naar een lijst met genegeerde resultaten, zichtbaar met --show-suppressed, en kan optioneel affected- en under_investigation-verklaringen aan de resultaten toevoegen.

Matching hangt af van identifiers. Noemt de VEX het product met een andere identifier dan de SBOM gebruikt, dan kan de scanner ze niet koppelen en blijft de bevinding staan.

Wie VEX publiceert

VEX komt meestal van de leverancier: de softwareleverancier, de open-sourcedistributie of de apparaatfabrikant die het product levert. Binnen de leverancier is het een PSIRT-taak, onderdeel van dezelfde levenscyclus van kwetsbaarheidsbeheer die advisories en fixes oplevert. Red Hat publiceert bijvoorbeeld CSAF VEX-documenten in een aparte map van zijn CSAF-feed, naast zijn advisories. Zie de PSIRT-rol voor wat PSIRT-engineers dagelijks doen.

Klanten schrijven ook VEX voor eigen gebruik, om triagebeslissingen over het product van een leverancier vast te leggen zodat hun scanner die niet opnieuw meldt. Regelgeving zoals de EU Cyber Resilience Act vraagt fabrikanten kwetsbaarheden af te handelen in de componenten die ze leveren, en VEX is een manier om gebruikers te vertellen welke van toepassing zijn.

VEX actueel houden

• Statussen veranderen. Een verklaring begint meestal als under_investigation en eindigt als not_affected, of als affected en daarna fixed. Publiceer elke wijziging; CISA vereist dat de versie elke keer oploopt.
• Nieuwe releases vragen om nieuwe verklaringen. Een not_affected-oordeel voor 3.2.0 zegt niets over 3.3.0. Controleer het opnieuw wanneer het component, de versie ervan of de buildconfiguratie verandert.
• Houd VEX gescheiden van de SBOM. De SBOM beschrijft een release en blijft ongewijzigd. VEX blijft na de release veranderen, dus als u het als apart document publiceert, hoeft u geen SBOM's opnieuw uit te geven.
• Publiceer waar tools kijken. Naast de SBOM, als attestatie op de containerimage of in uw advisoryfeed, en vermeld de locatie in uw disclosure policy. Zie coordinated vulnerability disclosure.

Beperkingen van VEX

• Het is een bewering, geen bewijs. Een not_affected-verklaring is de beoordeling van de auteur. CISA raadt aan de identiteit van de auteur cryptografisch aan het document te koppelen, maar de meeste afnemers vertrouwen VEX nog steeds omdat ze de leverancier vertrouwen.
• Stilte betekent niets. VEX impliceert geen standaardstatus. Een kwetsbaarheid zonder verklaring is onbekend, niet onaangetast.
• Formaten komen niet één op één overeen. CycloneDX gebruikt andere statussen en justificaties dan OpenVEX en CSAF, dus bij conversies gaat detail verloren.
• Het is maar zo goed als de inventaris. Zeggen dat een component niet aanwezig is, vereist dat u precies weet wat het product bevat, inclusief transitieve afhankelijkheden en alles wat de build buiten de pakketbeheerder om heeft gedownload.

VEX begint met een nauwkeurige SBOM

Elke VEX-verklaring verwijst naar componenten, en de makkelijkst te verdedigen justificatie, component_not_present, klopt alleen als de inventaris volledig is. Een SBOM die achteraf is gegenereerd door lockfiles te scannen, kan ontwikkelafhankelijkheden vermelden die nooit worden geleverd en pakketten missen die de build op een andere manier heeft opgehaald.

CRACI draait GitHub Actions-builds op zijn eigen runners en legt de pakketten vast die elke job daadwerkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Elke SBOM heeft een volledigheidsstatus en wordt geëxporteerd als CycloneDX of SPDX. Gemonitorde SBOM's worden doorlopend opnieuw beoordeeld, de buildhistorie toont welke eerdere builds een kwetsbare afhankelijkheid bevatten, en CRACI ondersteunt VEX. Zie SBOM-generatie en het volgen van kwetsbaarheden.

VEX: veelgestelde vragen

Waar staat VEX voor?

VEX staat voor Vulnerability Exploitability eXchange. Het is een machineleesbare verklaring over de vraag of een product wordt getroffen door een specifieke bekende kwetsbaarheid, gepubliceerd zodat gebruikers weten welke gemelde kwetsbaarheden actie vragen.

Wat is het verschil tussen een SBOM en VEX?

Een SBOM vermeldt de componenten in een product. VEX zegt voor een bepaalde kwetsbaarheid of dat product is getroffen. De SBOM verandert zelden na een release; VEX-verklaringen veranderen terwijl de leverancier onderzoek doet en problemen oplost. Daarom wordt VEX meestal gepubliceerd als apart document dat naar het product verwijst, in plaats van in de SBOM te worden opgenomen.

Wat zijn de vier VEX-statussen?

not_affected, affected, fixed en under_investigation. Een not_affected-verklaring heeft een justificatie of impactverklaring nodig, en een affected-verklaring heeft een actieverklaring nodig die zegt wat gebruikers moeten doen.

Welk VEX-formaat moet ik gebruiken?

Gebruik het formaat dat uw afnemers en tools lezen. OpenVEX is het kleinst en werkt met Trivy en Grype. CycloneDX VEX past bij teams die al CycloneDX-SBOM's leveren. CSAF VEX past bij organisaties die al CSAF security advisories publiceren, wat gebruikelijk is bij industriële en enterprise-software. Veel leveranciers converteren uiteindelijk tussen de formaten.

Is VEX hetzelfde als een security advisory?

Nee. Een security advisory legt uit wat een kwetsbaarheid is, wie is getroffen en hoe die kan worden opgelost, vooral voor mensen. VEX is een beknopte, machineleesbare status per product en kwetsbaarheid, vooral voor tools. De twee gaan vaak samen: de CSAF-standaard heeft zowel een security-advisoryprofiel als een VEX-profiel.

Wie schrijft VEX-documenten?

Meestal de leverancier van het product, vaak het product security incident response team (PSIRT), omdat die weet hoe het product is gebouwd en geconfigureerd. De minimumeisen van CISA staan ook toe dat derden VEX opstellen, en elk document moet de auteur noemen.

Lezen kwetsbaarheidsscanners VEX?

Een aantal wel. Trivy accepteert OpenVEX, CycloneDX en CSAF VEX via zijn --vex-optie en laat bevindingen weg die als not_affected zijn gemarkeerd. Grype accepteert OpenVEX en CSAF VEX via --vex en verplaatst not_affected- en fixed-bevindingen naar een lijst met genegeerde resultaten.