VEX in der Praxis: Schwachstellen-Rauschen senken und Compliance-Meldungen bedienen (2026)
| Interlynk
Die meisten CVEs, die gegen Ihr SBOM abgeglichen werden, treffen nicht zu. VEX ist, wie Sie das maschinenlesbar und für Regulierungsbehörden belastbar festhalten. So operationalisieren Sie es 2026.
Überblick
Ein SBOM liefert Ihnen eine genaue Liste dessen, was in Ihrer Software steckt. Gleichen Sie diese Liste gegen eine Schwachstellendatenbank ab, erhalten Sie eine zweite, meist deutlich längere Liste mit jeder CVE, die jemals mit diesen Komponenten in Verbindung gebracht wurde. Die meisten Einträge dieser zweiten Liste treffen auf Ihr Produkt nicht zu. Die verwundbare Funktion wird nie aufgerufen. Der betroffene Codepfad ist nicht erreichbar. Eine Gegenmaßnahme ist bereits vorhanden.
VEX, der Vulnerability Exploitability eXchange, ist die Art und Weise, wie Sie diese Unterscheidung in einer Form festhalten, die eine Maschine lesen und eine Regulierungsbehörde akzeptieren kann. Es ist die Schicht, die aus einer rohen Trefferliste eine belastbare Aussage darüber macht, welche Schwachstellen tatsächlich zählen.
Die Idee ist nicht neu, aber 2026 ist das Jahr, in dem sie für viele Teams keine Option mehr ist. Eine OpenSSF-Bestandsaufnahme vom Januar 2026 nannte VEX eher „ein Versprechen" als „eine Praxis" und merkte an, dass die Einführung uneinheitlich bleibt. Gleichzeitig hat der EU Cyber Resilience Act die Schwachstellenbehandlung zu einer gesetzlichen Pflicht gemacht, und große Abnehmer wie Cisco verlangen VEX inzwischen vertraglich von ihren Zulieferern. Die Lücke zwischen dem Nutzen von VEX und seiner geringen Operationalisierung ist die Chance. Dies ist eine Anleitung, sie zu schließen.
Das Rauschproblem
Beginnen wir mit dem Maßstab. Jedes Jahr werden rund 40.000 neue CVEs veröffentlicht. Eine einzige weit verbreitete Bibliothek kann Hunderte Warnungen auslösen, die sich als harmlos erweisen. Die OpenSSF-Bestandsaufnahme verweist auf Microsofts Erfahrung mit einer gängigen Bibliothek, bei der Schwachstellen in einer Abhängigkeit wie curl Hunderte unnötiger Support-Tickets erzeugten, von denen keines eine echte Gefährdung widerspiegelte.
Das ist die tägliche Realität beim Abgleich von Schwachstellen-Scans gegen ein SBOM. Das Inventar stimmt, der Abgleich stimmt, und die Ausgabe besteht trotzdem größtenteils aus Fehlalarmen, weil eine CVE an einer Komponente hängt, nicht an der Art, wie Ihr Produkt diese Komponente nutzt. Ein Team, das jeden Treffer von Hand prüft, skaliert nicht über eine Handvoll Produkte hinaus. Ein Team, das die Liste ganz ignoriert, lernt nichts aus ihr.
VEX existiert, um diesen Zielkonflikt aufzulösen. Statt dieselbe Nicht-Schwachstelle bei jedem Scan erneut zu prüfen, legen Sie ihren Status einmal in einem maschinenlesbaren Dokument fest, und jedes nachgelagerte Tool und jeder Kunde kann diese Aussage automatisch anwenden.
Was VEX aussagt
Eine VEX-Aussage beantwortet für ein bestimmtes Produkt und eine bestimmte Schwachstelle genau eine Frage: Betrifft sie Sie tatsächlich? CISA definiert vier Statuswerte.
Nicht betroffen (not affected). Keine Behebung erforderlich, weil die Schwachstelle das Produkt in der ausgelieferten Form nicht betrifft.
Betroffen (affected). Die Schwachstelle betrifft das Produkt, und der Autor empfiehlt Maßnahmen.
Behoben (fixed). Das veröffentlichte Produkt enthält die Behebung bereits.
In Prüfung (under investigation). Der Autor ist noch zu keinem Ergebnis gekommen.
Der Wert des Formats liegt im ersten und im letzten dieser Werte. „Nicht betroffen" unterdrückt das Rauschen, und „in Prüfung" ist ein ehrlicher, nachverfolgbarer Platzhalter während einer laufenden Bewertung. Beide sind für einen nachgelagerten Konsumenten weit nützlicher als Schweigen.
Begründungen für „Nicht betroffen"
Ein bloßes „nicht betroffen" ist eine Aussage ohne Beleg, und ein ernsthafter Konsument wird ihr nicht vertrauen. Ein glaubwürdiges VEX-Programm untermauert den Status mit einer der fünf von CISA definierten Begründungen:
Komponente nicht vorhanden. Der Scanner hat etwas abgeglichen, das im Build gar nicht enthalten ist.
Verwundbarer Code nicht vorhanden. Die Komponente ist enthalten, der konkrete verwundbare Code jedoch nicht.
Verwundbarer Code nicht im Ausführungspfad. Die Abhängigkeit ist vorhanden, die verwundbare Funktion wird aber nie erreicht.
Verwundbarer Code durch einen Angreifer nicht kontrollierbar. Eingabevektoren erreichen die Schwachstelle nicht.
Inline-Gegenmaßnahmen bereits vorhanden. Der Code ist erreichbar, aber etwas anderes verhindert den Exploit.
Jede dieser Begründungen ist eine andere Art von Aussage, und die Disziplin, die sie erzwingen, ist der Punkt. Sie zwingen die Person, die das VEX schreibt, strukturiert zu benennen, was sie geprüft und was sie geschlussfolgert hat. Genau hier scheitern VEX-Programme am häufigsten, denn eine Begründung ist nur so gut wie der Beleg, der sie stützt, und dieser Beleg muss irgendwoher kommen.
Die Formatlandschaft
VEX ist ein Konzept mit mehreren konkreten Kodierungen, und die Wahl zwischen ihnen hat echte Folgen.
CSAF ist der OASIS-Standard, weit verbreitet bei großen Anbietern und auf die Richtung des EU CRA abgestimmt. Es ist mächtig und ausdrucksstark. Es ist aber auch komplex zu erzeugen und ohne spezialisierte Werkzeuge zu validieren, weshalb die OpenSSF-Bestandsaufnahme es als Ziel für hochwertige Produktion empfiehlt, nicht als Einstiegspunkt für die meisten Teams.
OpenVEX ist das OpenSSF-Projekt, das auf Einfachheit ausgelegt ist. Es setzt auf Zuverlässigkeit statt auf Beratungsfunktionen, unterstützt in-toto-Attestierung und bietet stabile Bibliotheken in Go, Docker und anderen Ökosystemen, was die Einstiegshürde für kleinere Teams senkt. Es ist die pragmatische Wahl für den Anfang.
CycloneDX unterstützt VEX und kann den Schwachstellenstatus in ein SBOM einbetten. Dieser Komfort hat einen Haken, den man verstehen sollte. Ein SBOM ist eine Momentaufnahme zur Build-Zeit, während sich VEX bei jeder neuen Statusinformation ändert, sodass das Einbetten des einen in das andere eine Lebenszyklus-Diskrepanz erzeugt, die die Dokumentation nicht vollständig auflöst.
SPDX 3.0 enthält inzwischen eine vollständige VEX-Umsetzung, die so gestaltet ist, dass sie mit den anderen Formaten verlustfrei hin- und zurückkonvertiert.
Für die meisten Teams ist der praktische Weg, mit OpenVEX wegen seiner Werkzeuge zu beginnen und dort zu CSAF zu wechseln, wo eine Regulierungsbehörde oder ein großer Kunde es erwartet. Die wichtige Entscheidung ist nicht, welches Format gewinnt. Es geht darum, VEX in einem Format zu erzeugen, das Ihre Konsumenten tatsächlich aufnehmen können, und die VEX-Dokumente vom SBOM getrennt zu halten, damit jedes seinem eigenen Aktualisierungszyklus folgen kann.
Wer VEX erstellt, und wann
VEX wird von demjenigen verfasst, der am besten beurteilen kann, ob eine Schwachstelle ausnutzbar ist. In der Regel ist das der Zulieferer der betroffenen Komponente oder der Anbieter des fertigen Produkts.
In der Praxis ist die Liste derer, die das gut machen, kurz. Red Hat, OpenSUSE und Microsoft veröffentlichen CSAF-VEX. Cisco stellt es über APIs bereit und bewegt sich in Richtung CSAF-Exporte. Chainguard pflegt einen OpenVEX-Feed. Die meisten Open-Source-Maintainer veröffentlichen nichts, weil sie wenig Anreiz dazu sehen, was bedeutet, dass ein Konsument von Open-Source-Komponenten oft selbst VEX für Abhängigkeiten erzeugen muss, deren Maintainer das nie tun werden.
Das Timing ist die andere Hälfte. Ein Schwachstellenstatus ist keine einmalige Erklärung. Er beginnt als „in Prüfung", wird nach der Analyse zu „betroffen" oder „nicht betroffen" und kann nach einem Release zu „behoben" werden. Ein VEX-Programm muss den Status als etwas behandeln, das sich über die Lebensdauer eines Produkts verändert, neu festgelegt, wenn die Analyse abgeschlossen ist und Releases ausgeliefert werden. Das ist der Lebenszyklus-Punkt, über den der Einbetten-ins-SBOM-Ansatz stolpert, und der Grund, warum VEX besser als lebendiger Strom von Aussagen verwaltet wird, der an Produkte und Versionen gebunden ist.
VEX und regulatorische Meldungen
Der Compliance-Fall ist es, der VEX vom Nice-to-have zur Notwendigkeit treibt.
Nach dem EU Cyber Resilience Act ist die Schwachstellenbehandlung eine gesetzliche Pflicht, und Hersteller müssen aktiv ausgenutzte Schwachstellen innerhalb enger Fristen melden. Die Frage, die eine Regulierungsbehörde oder ein CSIRT in diesem Moment wirklich stellt, lautet, ob eine bestimmte Schwachstelle in Ihrem Produkt ausnutzbar ist und welche Produkte und Versionen betroffen sind. Genau diese Frage soll VEX beantworten. Ein gepflegter Satz von VEX-Aussagen ist die Grundlage dafür, dass ein Hersteller mit Belegen feststellen kann, dass eine neu offengelegte CVE in einer gebündelten Komponente in einem ausgelieferten Gerät ausnutzbar ist oder nicht, statt diese Analyse unter einer 72-Stunden-Uhr zu rekonstruieren. Die enge Abstimmung von CSAF auf den CRA ist der Grund, warum große Anbieter dafür darauf standardisieren.
Die Medizingeräteseite verläuft parallel. Die FDA-Erwartungen nach Section 524B umfassen die Fähigkeit, den Status von Schwachstellen in einem vermarkteten Gerät über dessen Lebensdauer zu bewerten und zu kommunizieren. VEX ist der Mechanismus für diese Kommunikation: eine strukturierte Möglichkeit, einem Krankenhaus mitzuteilen, dass eine beunruhigend wirkende CVE im SBOM des Geräts nicht zutrifft, und warum.
In beiden Regelwerken belegt das SBOM, was im Produkt steckt, und VEX belegt, was ausnutzbar ist. Regulierungsbehörden erwarten zunehmend beides, und das Zweite ist schwerer vorzutäuschen.
Wo VEX im großen Maßstab versagt
VEX ehrlich zu operationalisieren bedeutet, zu benennen, was noch nicht funktioniert, denn die Lücken bestimmen, wie Sie bauen.
Für Auffindbarkeit und Verteilung gibt es keinen gemeinsamen Standard. Es gibt kein universelles Nachschlagesystem, das zu einer Komponente die zugehörigen VEX-Aussagen liefert, sodass Dokumente über Anbieterseiten, APIs und Feeds verstreut sind. Vertrauen ist uneinheitlich, und in der Praxis vertrauen viele Teams einer VEX-Datei aufgrund des Orts, an dem sie gehostet wird, statt aufgrund einer kryptografischen Signatur. Signaturstandards reifen noch.
Das tiefste Problem ist der Abgleich von Bezeichnern. VEX-Automatisierung hängt davon ab, eine Aussage über eine Komponente zuverlässig mit der Komponente in Ihrem SBOM zu verbinden, und diese Verbindung läuft über Bezeichner wie PURL, CPE und kryptografische Hashes. Diesen Schemata fehlen gemeinsame Konventionen und vertrauenswürdige Zuordnungsinstanzen, sodass eine VEX-Aussage, die an einen Bezeichner geknüpft ist, dieselbe Komponente unter einem anderen Bezeichner möglicherweise nie trifft. Wenn die Bezeichner nicht übereinstimmen, scheitert die Automatisierung stillschweigend, und Sie sind zurück bei der manuellen Prüfung.
Dieser letzte Punkt hat eine direkte Folge dafür, wie VEX gebaut werden sollte. VEX ist nur so automatisierbar wie das SBOM, an das es sich hängt. Trägt das zugrunde liegende SBOM vage oder fehlende Komponentenbezeichner, wird kein noch so gutes VEX-Werkzeug die Aussagen korrekt zuordnen. Genaue Bezeichner im SBOM sind die Voraussetzung dafür, dass VEX überhaupt funktioniert.
VEX operationalisieren
Fügt man die Teile zusammen, hat ein operatives VEX-Programm eine klare Form.
Es beginnt mit einem genauen SBOM, denn VEX-Aussagen müssen an reale Komponenten mit realen Bezeichnern binden. Genau dieser Teil scheitert am häufigsten bei eingebetteter und Firmware-Software, wo Komponenten als eingebundener Quellcode, statische Bibliotheken und SDKs ohne saubere Paketbezeichner ankommen. Interlynks lynkctl erzeugt build-bewusste SBOMs, die diese Komponenten mit präzisen Bezeichnern erfassen, was den nachgelagerten VEX-Abgleich verlässlich statt näherungsweise macht.
Von dort aus lebt der Schwachstellen- und VEX-Workflow in der Interlynk-Plattform. Sie nimmt SBOMs und CBOMs auf, bewertet sie, führt eine Risikobewertung der Komponenten gegen Schwachstellendaten durch und verwaltet VEX-Aussagen, sodass eine einmal getroffene „nicht betroffen"-Entscheidung konsistent angewendet wird und dieselbe CVE bei jedem künftigen Scan unterdrückt. Sie verfolgt den Status über die Lebensdauer eines Produkts, statt ihn zur Build-Zeit einzufrieren, und benachrichtigt Beteiligte, wenn etwas, das ruhig war, ausnutzbar wird. Die Plattform scannt oder entdeckt Software nicht selbst. Sie arbeitet mit dem SBOM und CBOM, das ihr übergeben wird, was die Generierungs- und Bewertungsschichten sauber getrennt hält.
Die Form eines funktionierenden Programms lautet also: genaue SBOMs erzeugen, gegen Schwachstellendaten abgleichen, die Ausnutzbarkeit als VEX mit echten Begründungen festhalten, diese Aussagen aktuell halten und in die Meldungen einspeisen, die Ihre Regulierungsbehörden und Kunden verlangen.
Fazit
VEX ist der Unterschied zwischen einer Schwachstellenliste, die Menschen alarmiert, und einer, die sie informiert. Das Konzept steht, die Formate existieren, und der Compliance-Druck ist inzwischen real genug, dass Warten ein eigenes Risiko ist.
Noch nicht geklärt ist die operative Schicht: VEX aus echten Belegen zu erzeugen, es an genaue Bezeichner zu knüpfen, es aktuell zu halten und in einer Form zu verteilen, der Konsumenten vertrauen. Das ist die Arbeit, die sich 2026 lohnt. Standards definieren, wie eine gute Ausnutzbarkeitsaussage aussieht. Genaue SBOMs und ein disziplinierter Arbeitsablauf sind es, die Sie eine solche Aussage im großen Maßstab erzeugen lassen.
Quellen
OpenSSF, „Signal in the Noise: An Industry-Wide Perspective on the State of VEX", Januar 2026
CISA, „Vulnerability Exploitability eXchange (VEX)" – Überblick und Statusbegründungen
CISA, „Minimum Requirements for Vulnerability Exploitability eXchange (VEX)", April 2023
Über Interlynk. Interlynk hilft Teams, SBOMs entlang der Software-Lieferkette zu erzeugen, zu verwalten und zu operationalisieren. lynkctl erzeugt build-bewusste SBOMs für eingebettete und Firmware-Software und erfasst eingebundene, statische und SDK-Komponenten mit präzisen Bezeichnern. Die Interlynk-Plattform nimmt SBOMs und CBOMs auf, bewertet sie auf Vollständigkeit und Qualität, führt Risikobewertungen von Komponenten durch, verwaltet VEX-Aussagen und benachrichtigt Teams, wenn sich die Gefährdung ändert.
Demo buchen · Kostenlos starten
Dieser Artikel dient der Information und stellt keine Rechts- oder Compliance-Beratung dar. Regulatorische Pflichten und Standards entwickeln sich weiter; prüfen Sie die aktuellen Anforderungen anhand der Primärquellen und mit Ihrer eigenen Rechtsberatung.