Was ist VEX? Sagen, dass eine Schwachstelle Sie nicht betrifft

Lassen Sie einen beliebigen Scanner über eine SBOM laufen, und er meldet Dutzende bekannter Schwachstellen. Die meisten spielen für dieses Produkt keine Rolle: Die verwundbare Funktion wird nie aufgerufen, die Funktion ist abgeschaltet, die Komponente wird nur beim Build verwendet. VEX, der Vulnerability Exploitability eXchange, ist der standardisierte Weg, das zu sagen, in einer Form, die Werkzeuge und Kunden lesen können.

Eine VEX-Aussage ist eine einfache Feststellung: dieses Produkt, diese Schwachstelle, dieser Status, mit der Begründung oder der Maßnahme, die dazugehört.

Warum das wichtig ist

Ohne VEX erhält jeder Kunde, der Ihr Produkt scannt, dieselbe lange Liste und stellt Ihnen einzeln dieselben Fragen. Mit VEX antworten Sie einmal, in einer Datei, die seine Werkzeuge automatisch anwenden: Befunde, die Sie als das Produkt nicht betreffend bewertet haben, verschwinden aus seinen Berichten, mit Ihrer Begründung.

Für einen Hersteller unter dem Cyber Resilience Act ist VEX außerdem ein Nachweis. Anhang I verlangt, dass Sie die Schwachstellen Ihrer Produkte ermitteln und behandeln und ohne bekannte ausnutzbare Schwachstellen ausliefern. Eine datierte Aufzeichnung, warum jede verbleibende Schwachstelle nicht ausgenutzt werden kann, ist genau das, was eine Prüferin oder eine Marktüberwachungsbehörde sehen will. Sie erspart Ihrem Team auch, bei der nächsten Version dieselbe Analyse noch einmal zu machen.

Die vier Status

Die von der US-Behörde CISA einberufene VEX-Arbeitsgruppe hat vier Status festgelegt, die jedes Format verwendet:

Status	Bedeutung	Was dazugehören muss
Not affected (nicht betroffen)	Das Produkt ist von der Schwachstelle nicht betroffen	Eine Begründung oder eine Beschreibung der Auswirkung, die erklärt, warum
Affected (betroffen)	Das Produkt ist betroffen	Eine Maßnahmenbeschreibung: was Nutzer tun sollten
Fixed (behoben)	Diese Versionen enthalten die Korrektur	Nichts weiter
Under investigation (in Untersuchung)	Der Status ist noch nicht bekannt	Nichts weiter; aktualisieren Sie ihn, sobald Sie es wissen

Ein VEX-Dokument unterstellt nie einen Status: Eine Schwachstelle, die es nicht nennt, ist schlicht nicht abgedeckt.

Die fünf Begründungen für „nicht betroffen“

Das Begründungsdokument der CISA nennt fünf:

Komponente nicht vorhanden: Die verwundbare Komponente ist gar nicht im Produkt (der Scanner hat das falsche Paket erkannt, oder es ist nur ein Build-Werkzeug).
Verwundbarer Code nicht vorhanden: Die Komponente ist da, aber der verwundbare Code wurde nicht übernommen, etwa ein herauskompiliertes Modul.
Verwundbarer Code kann vom Angreifer nicht gesteuert werden: Der Code läuft, aber ein Angreifer kann ihn nicht mit der nötigen Eingabe erreichen.
Verwundbarer Code nicht im Ausführungspfad: Der Code ist vorhanden, aber das Produkt führt ihn nie aus.
Inline-Gegenmaßnahmen sind bereits vorhanden: Das Produkt enthält Schutzmechanismen, die eine Ausnutzung verhindern.

Die ersten beiden und „nicht im Ausführungspfad“ sind meist am leichtesten zu belegen: Ein Abhängigkeitsgraph oder eine Erreichbarkeitsanalyse kann zeigen, dass der verwundbare Code fehlt oder nie aufgerufen wird. Die anderen beiden brauchen eine sorgfältige Argumentation und eine Erläuterung in Ihren eigenen Worten; die CISA warnt, dass ein Angreifer die Ausführung auf Code umlenken kann, den Sie für unerreichbar hielten.

Die Formate

VEX ist ein Konzept mit mehreren Umsetzungen. Alle erfüllen die Mindestanforderungen der CISA:

CSAF VEX: ein Profil des OASIS Common Security Advisory Framework 2.0, auch ein ISO-Standard (ISO/IEC 20153:2025). Es ist das bevorzugte Format, um Sicherheitshinweise mit Produktbäumen und Abhilfen zu veröffentlichen; viele große Hersteller und nationale CERTs, darunter das BSI, nutzen es.
CycloneDX VEX: der Schwachstellenabschnitt eines CycloneDX-Dokuments, mit einem analysis-Block pro Schwachstelle. Er kann in der SBOM stehen oder in einer separaten Datei, die auf sie verweist. CycloneDX verwendet eigene, feiner abgestufte Namen für Zustände und Begründungen, die sich grob auf die der CISA abbilden lassen.
OpenVEX: ein minimales JSON-LD-Format, gepflegt von der OpenSSF, unabhängig von einem SBOM-Format, mit Werkzeugen wie vexctl zum Erstellen und Anwenden von Dokumenten. Distributionen wie Ubuntu veröffentlichen ihre VEX-Daten darin.
SPDX 3.0 drückt VEX über Beziehungen in seinem Sicherheitsprofil aus.

Ein Beispiel

Hier ein OpenVEX-Dokument, das sagt, dass Version 4.2.0 eines Gateways von einer Schwachstelle in einer mitgelieferten Bibliothek nicht betroffen ist, weil der verwundbare Code nie erzeugt wird:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://acme.example/vex/gateway-4.2.0-2026-11-08",
  "author": "Acme Devices Security <security@acme.example>",
  "timestamp": "2026-11-08T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-45296" },
      "products": [
        {
          "@id": "pkg:generic/acme/gateway@4.2.0",
          "subcomponents": [{ "@id": "pkg:npm/path-to-regexp@0.1.7" }]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "No route of the gateway has two parameters in one path segment (such as /:a-:b), so the backtracking regular expression is never generated."
    }
  ]
}

Das Dokument hat einen Autor, einen Zeitstempel und eine Versionsnummer, die bei jeder Änderung einer Aussage steigt. Jede Aussage nennt die Schwachstelle, das Produkt (und die Komponente darin), den Status und den Grund. Die Erläuterung (impact_statement) kann in jeder Sprache stehen; Englisch wird von den meisten Kunden und Werkzeugen verstanden.

Gute Praxis

Seien Sie beim Produkt genau: Eine VEX-Aussage deckt die Versionen ab, die sie nennt, nichts sonst. Verwenden Sie Package URLs.
Erklären, nicht nur etikettieren: Ein Begründungscode allein überzeugt niemanden. Fügen Sie eine kurze Beschreibung der Auswirkung hinzu, die ein Kunde versteht.
Halten Sie es aktuell: Eine neue Version kann die Antwort ändern. Bewerten Sie neu, wenn sich der Code ändert, der eine Komponente aufruft, und veröffentlichen Sie eine neue Version des Dokuments.
Verbergen Sie kein echtes Risiko: „Nicht betroffen“ ist eine Aussage, die Sie vielleicht verteidigen müssen. Im Zweifel sagen Sie „in Untersuchung“ oder „betroffen“ mit einer Abhilfe.
Veröffentlichen Sie es neben Ihren Hinweisen und verweisen Sie von Ihrer Sicherheitsseite darauf. Maschinenlesbare Hinweise (CSAF) und VEX zusammen helfen, die Pflicht des CRA zur Information der Nutzer über behobene Schwachstellen zu erfüllen.

VEX und die Meldeuhr

Eine VEX-Aussage ist keine Meldung an die Behörden. Wird eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt, gilt die 24-Stunden-Uhr des CRA, egal was Ihr VEX über andere Versionen sagt. Aber VEX hilft Ihnen, schnell zu entscheiden: Wenn Sie bereits wissen, dass der verwundbare Code einer Komponente nicht in Ihrem Ausführungspfad liegt, wissen Sie in Minuten, dass das Produkt nicht betroffen ist. Siehe die Meldeuhr.

Wie Provetry hilft

Für jede in einer Version gefundene Schwachstelle halten Sie eine VEX-Bewertung fest (Status, Begründung und Erläuterung); sie wird auf spätere Versionen mit derselben Komponente übertragen, und Provetry weist darauf hin, wenn Ihre CI später einen Aufruf der verwundbaren Funktion findet. Sein CI-Schritt schlägt „nicht betroffen“ vor, wenn ein verwundbares Paket nie geladen oder eine verwundbare Funktion nie aufgerufen wird, mit dem Nachweis (Funktionsebene für npm, PyPI und Java in den Tarifen Pro und Consultant). Jede Version lässt sich mit einem OpenVEX-Dokument herunterladen, und in den kostenpflichtigen Tarifen veröffentlicht eine öffentliche Seite Ihre CSAF-Hinweise und einen VEX-Feed der Schwachstellen, die Sie in unterstützten Versionen abgeschlossen haben (nicht betroffen oder behoben).