VEX in de praktijk: kwetsbaarheidsruis verminderen en compliance-rapportage voeden (2026)
| Interlynk
De meeste CVE's die tegen uw SBOM worden gematcht, zijn niet van toepassing. VEX is hoe u dat vastlegt, in een vorm die machines en toezichthouders kunnen gebruiken. Zo operationaliseert u het in 2026.
Overzicht
Een SBOM geeft u een nauwkeurige lijst van wat er in uw software zit. Matcht u die lijst tegen een kwetsbaarheidsdatabase, dan krijgt u een tweede, meestal veel langere lijst met elke CVE die ooit met die componenten in verband is gebracht. De meeste vermeldingen op die tweede lijst gelden niet voor uw product. De kwetsbare functie wordt nooit aangeroepen. Het getroffen codepad is onbereikbaar. Er is al een mitigatie aanwezig.
VEX, de Vulnerability Exploitability eXchange, is hoe u dat onderscheid vastlegt in een vorm die een machine kan lezen en een toezichthouder kan accepteren. Het is de laag die een ruwe matchlijst omzet in een onderbouwde uitspraak over welke kwetsbaarheden er werkelijk toe doen.
Het idee is niet nieuw, maar 2026 is het jaar waarin het voor veel teams geen optie meer is. Een OpenSSF-evaluatie van januari 2026 noemde VEX eerder "een belofte" dan "een praktijk" en merkte op dat de adoptie inconsistent blijft. Tegelijkertijd heeft de EU Cyber Resilience Act kwetsbaarheidsafhandeling tot een wettelijke verplichting gemaakt, en grote afnemers zoals Cisco eisen VEX inmiddels contractueel van hun leveranciers. De kloof tussen het nut van VEX en de geringe operationalisering ervan is de kans. Dit is een gids om die te dichten.
Het ruisprobleem
Begin bij de schaal. Elk jaar worden er ongeveer 40.000 nieuwe CVE's gepubliceerd. Eén veelgebruikte bibliotheek kan honderden meldingen veroorzaken die uiteindelijk onschadelijk blijken. De OpenSSF-evaluatie verwijst naar de ervaring van Microsoft met een veelvoorkomende bibliotheek, waarbij kwetsbaarheden in een afhankelijkheid zoals curl honderden onnodige supporttickets opleverden, waarvan geen enkele een echte blootstelling weerspiegelde.
Dit is de dagelijkse realiteit van het matchen van kwetsbaarheidsscans tegen een SBOM. De inventaris klopt, de matching klopt, en de uitvoer bestaat toch grotendeels uit valse positieven, omdat een CVE aan een component hangt en niet aan de manier waarop uw product die component gebruikt. Een team dat elke match met de hand triageert, schaalt niet verder dan een handvol producten. Een team dat de lijst volledig negeert, leert er niets van.
VEX bestaat om die afweging te doorbreken. In plaats van dezelfde niet-kwestie bij elke scan opnieuw te triageren, legt u de status één keer vast in een machineleesbaar document, en elk nageschakeld hulpmiddel en elke klant kan die uitspraak automatisch toepassen.
Wat VEX stelt
Een VEX-uitspraak beantwoordt voor een bepaald product en een bepaalde kwetsbaarheid één vraag: raakt dit u daadwerkelijk? CISA definieert vier statuswaarden.
Niet getroffen (not affected). Geen herstel nodig, omdat de kwetsbaarheid het product zoals geleverd niet raakt.
Getroffen (affected). De kwetsbaarheid raakt het product, en de auteur beveelt actie aan.
Hersteld (fixed). Het uitgebrachte product bevat de oplossing al.
In onderzoek (under investigation). De auteur is nog niet tot een conclusie gekomen.
De waarde van het formaat zit in de eerste en de laatste daarvan. "Niet getroffen" onderdrukt de ruis, en "in onderzoek" is een eerlijke, traceerbare tussenstand tijdens een lopende beoordeling. Beide zijn voor een nageschakelde consument veel nuttiger dan stilte.
Rechtvaardigingen voor "Niet getroffen"
Een kale "niet getroffen" is een uitspraak zonder bewijs, en een serieuze consument zal die niet vertrouwen. Een geloofwaardig VEX-programma onderbouwt de status met een van de vijf rechtvaardigingen die CISA definieert:
Component niet aanwezig. De scanner matchte iets dat niet daadwerkelijk in de build zit.
Kwetsbare code niet aanwezig. De component is opgenomen, maar de specifieke kwetsbare code niet.
Kwetsbare code niet in het uitvoeringspad. De afhankelijkheid is aanwezig, maar de kwetsbare functie wordt nooit bereikt.
Kwetsbare code niet te beheersen door een aanvaller. Invoervectoren bereiken de kwetsbaarheid niet.
Inline-mitigaties al aanwezig. De code is bereikbaar, maar iets anders stopt de exploit.
Elk daarvan is een ander soort claim, en de discipline die ze afdwingen is de kern. Ze dwingen de persoon die de VEX schrijft om gestructureerd te benoemen wat is gecontroleerd en wat is geconcludeerd. Juist daar lopen VEX-programma's het vaakst vast, want een rechtvaardiging is slechts zo sterk als het bewijs eronder, en dat bewijs moet ergens vandaan komen.
Het formaatlandschap
VEX is een concept met meerdere concrete coderingen, en de keuze ertussen heeft echte gevolgen.
CSAF is de OASIS-standaard, breed gebruikt door grote leveranciers en afgestemd op de richting van de EU CRA. Het is krachtig en expressief. Het is ook complex om te genereren en te valideren zonder gespecialiseerde tooling, en daarom beveelt de OpenSSF-evaluatie het aan als doel voor productie met hoge betrouwbaarheid, niet als startpunt voor de meeste teams.
OpenVEX is het OpenSSF-project dat op eenvoud is gebouwd. Het kiest betrouwbaarheid boven adviesfuncties, ondersteunt in-toto-attestatie en heeft stabiele bibliotheken in Go, Docker en andere ecosystemen, wat de drempel voor kleinere teams verlaagt. Het is de pragmatische keuze om mee te beginnen.
CycloneDX ondersteunt VEX en kan de kwetsbaarheidsstatus in een SBOM inbedden. Dat gemak heeft een addertje dat de moeite waard is om te begrijpen. Een SBOM is een momentopname op buildmoment, terwijl VEX verandert telkens als er nieuwe statusinformatie verschijnt, zodat het inbedden van het een in het ander een levenscyclusmismatch creëert die de documentatie niet volledig oplost.
SPDX 3.0 bevat nu een volledige VEX-implementatie die is ontworpen om verliesloos heen en weer te converteren met de andere formaten.
Voor de meeste teams is het praktische pad om te beginnen met OpenVEX vanwege de tooling en door te schuiven naar CSAF waar een toezichthouder of een grote klant dat verwacht. De belangrijke beslissing is niet welk formaat wint. Het gaat erom VEX te produceren in een formaat dat uw consumenten daadwerkelijk kunnen opnemen, en de VEX-documenten gescheiden te houden van de SBOM, zodat elk zijn eigen updatecyclus kan volgen.
Wie schrijft VEX, en wanneer
VEX wordt geschreven door wie het best kan beoordelen of een kwetsbaarheid misbruikbaar is. Meestal is dat de leverancier van de getroffen component of de leverancier van het eindproduct.
In de praktijk is de lijst van wie dit goed doet kort. Red Hat, OpenSUSE en Microsoft publiceren CSAF-VEX. Cisco stelt het beschikbaar via API's en beweegt richting CSAF-exports. Chainguard onderhoudt een OpenVEX-feed. De meeste open-source-maintainers publiceren niets, omdat ze er weinig prikkel toe zien, wat betekent dat een consument van open-source-componenten vaak zelf VEX moet produceren voor afhankelijkheden waarvan de maintainers dat nooit zullen doen.
Timing is de andere helft. Een kwetsbaarheidsstatus is geen eenmalige verklaring. Hij begint als "in onderzoek", wordt na analyse "getroffen" of "niet getroffen", en kan na een release "hersteld" worden. Een VEX-programma moet status behandelen als iets dat verandert over de levensduur van een product, opnieuw vastgesteld naarmate de analyse wordt afgerond en releases worden uitgebracht. Dat is het levenscycluspunt waarover de inbedden-in-SBOM-aanpak struikelt, en de reden waarom VEX beter wordt beheerd als een levende stroom van uitspraken die aan producten en versies is gekoppeld.
VEX en regelgevingsrapportage
De compliance-reden is wat VEX van nice-to-have naar noodzaak duwt.
Onder de EU Cyber Resilience Act is kwetsbaarheidsafhandeling een wettelijke verplichting, en fabrikanten moeten actief misbruikte kwetsbaarheden binnen krappe termijnen melden. De vraag die een toezichthouder of een CSIRT op dat moment werkelijk stelt, is of een bepaalde kwetsbaarheid in uw product misbruikbaar is en welke producten en versies getroffen zijn. Precies die vraag is VEX bedoeld te beantwoorden. Een onderhouden set VEX-uitspraken is hoe een fabrikant met bewijs kan verklaren dat een nieuw bekendgemaakte CVE in een gebundelde component in een geleverd apparaat al dan niet misbruikbaar is, in plaats van die analyse onder een klok van 72 uur te reconstrueren. De nauwe afstemming van CSAF op de CRA is waarom grote leveranciers daarvoor op CSAF standaardiseren.
De kant van medische hulpmiddelen loopt parallel. De FDA-verwachtingen onder Section 524B omvatten het vermogen om de status van kwetsbaarheden in een op de markt gebracht apparaat gedurende de levensduur ervan te beoordelen en te communiceren. VEX is het mechanisme voor die communicatie: een gestructureerde manier om een ziekenhuis te vertellen dat een angstaanjagend ogende CVE in de SBOM van het apparaat niet van toepassing is, en waarom.
In beide regimes bewijst de SBOM wat er in het product zit, en VEX bewijst wat misbruikbaar is. Toezichthouders verwachten steeds vaker beide, en het tweede is moeilijker te veinzen.
Waar VEX op schaal vastloopt
VEX eerlijk operationaliseren betekent benoemen wat nog niet werkt, want de hiaten bepalen hoe u bouwt.
Voor vindbaarheid en distributie bestaat geen gemeenschappelijke standaard. Er is geen universeel opzoeksysteem dat voor een component de bijbehorende VEX-uitspraken teruggeeft, zodat documenten verspreid zijn over leverancierssites, API's en feeds. Vertrouwen is ongelijk, en in de praktijk vertrouwen veel teams een VEX-bestand vanwege waar het wordt gehost, niet omdat het cryptografisch is ondertekend. Ondertekeningsstandaarden zijn nog in ontwikkeling.
Het diepste probleem is het matchen van identifiers. VEX-automatisering hangt af van het betrouwbaar verbinden van een uitspraak over een component met de component in uw SBOM, en die verbinding loopt via identifiers zoals PURL, CPE en cryptografische hashes. Die identifierschema's missen gedeelde conventies en vertrouwde mappingautoriteiten, zodat een VEX-uitspraak die aan één identifier is gekoppeld, dezelfde component onder een andere identifier mogelijk nooit matcht. Als de identifiers niet op elkaar aansluiten, faalt de automatisering stilzwijgend, en bent u terug bij handmatige triage.
Dat laatste punt heeft een direct gevolg voor hoe VEX gebouwd moet worden. VEX is slechts zo automatiseerbaar als de SBOM waaraan het hangt. Draagt de onderliggende SBOM vage of ontbrekende componentidentifiers, dan zal geen enkele VEX-tooling de uitspraken correct matchen. Nauwkeurige identifiers in de SBOM zijn de voorwaarde om VEX überhaupt te laten werken.
VEX operationaliseren
Zet de stukken bij elkaar en een operationeel VEX-programma krijgt een heldere vorm.
Het begint met een nauwkeurige SBOM, want VEX-uitspraken moeten binden aan echte componenten met echte identifiers. Juist dat deel loopt het vaakst vast bij embedded en firmware software, waar componenten binnenkomen als ingevoegde broncode, statische bibliotheken en SDK's zonder schone pakketidentifiers. Interlynks lynkctl genereert build-bewuste SBOM's die deze componenten met precieze identifiers vastleggen, wat de nageschakelde VEX-matching betrouwbaar maakt in plaats van bij benadering.
Van daaruit leeft de kwetsbaarheids- en VEX-workflow in het Interlynk-platform. Het neemt SBOM's en CBOM's op, beoordeelt ze, voert een risicobeoordeling van componenten uit tegen kwetsbaarheidsdata en beheert VEX-uitspraken, zodat een eenmaal genomen "niet getroffen"-beslissing consistent wordt toegepast en dezelfde CVE bij elke volgende scan onderdrukt. Het volgt de status gedurende de levensduur van een product in plaats van die op buildmoment te bevriezen, en het stelt belanghebbenden op de hoogte wanneer iets dat rustig was misbruikbaar wordt. Het platform scant of ontdekt software niet zelf. Het werkt met de SBOM en CBOM die het krijgt aangereikt, wat de generatie- en beoordelingslagen netjes gescheiden houdt.
De vorm van een werkend programma is dus: nauwkeurige SBOM's genereren, matchen tegen kwetsbaarheidsdata, de misbruikbaarheid als VEX met echte rechtvaardigingen vastleggen, die uitspraken actueel houden en ze voeden in de rapportages die uw toezichthouders en klanten vragen.
Conclusie
VEX is het verschil tussen een kwetsbaarheidslijst die mensen alarmeert en een die ze informeert. Het concept staat, de formaten bestaan, en de compliance-druk is inmiddels reëel genoeg dat wachten een eigen risico is.
Nog niet opgelost is de operationele laag: VEX produceren uit echt bewijs, het koppelen aan nauwkeurige identifiers, het actueel houden en het distribueren in een vorm die consumenten vertrouwen. Dat is het werk dat de moeite waard is in 2026. Standaarden bepalen hoe een goede misbruikbaarheidsuitspraak eruitziet. Nauwkeurige SBOM's en een gedisciplineerde workflow zijn wat u er een op schaal laat produceren.
Bronnen
OpenSSF, "Signal in the Noise: An Industry-Wide Perspective on the State of VEX", januari 2026
CISA, "Vulnerability Exploitability eXchange (VEX)" – overzicht en statusrechtvaardigingen
CISA, "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)", april 2023
Over Interlynk. Interlynk helpt teams SBOM's te genereren, te beheren en te operationaliseren in de software-toeleveringsketen. lynkctl genereert build-bewuste SBOM's voor embedded en firmware software en legt ingevoegde, statische en SDK-componenten vast met precieze identifiers. Het Interlynk-platform neemt SBOM's en CBOM's op, beoordeelt ze op volledigheid en kwaliteit, voert risicobeoordelingen van componenten uit, beheert VEX-uitspraken en stelt teams op de hoogte wanneer de blootstelling verandert.
Dit artikel is informatief en vormt geen juridisch of compliance-advies. Wettelijke verplichtingen en standaarden evolueren; verifieer de actuele eisen aan de hand van de primaire bronnen en uw eigen juridisch adviseur.