VEX: Was ein Vulnerability-Exploitability-eXchange-Dokument aussagt

Was ist VEX?

VEX, kurz für Vulnerability Exploitability eXchange, ist eine maschinenlesbare Aussage darüber, ob ein Produkt von einer bestimmten bekannten Schwachstelle betroffen ist. Ein Lieferant veröffentlicht sie, damit die Nutzer des Produkts wissen, welche Schwachstellen Handeln erfordern und welche nicht. In den meisten Organisationen liegt diese Aufgabe beim Product Security Incident Response Team (PSIRT).

Die Minimum Requirements for VEX von CISA (April 2023) definieren es unabhängig von einem Dateiformat: Ein VEX-Dokument ist ein Container für eine oder mehrere VEX-Aussagen, und jede Aussage gibt einen Status für eine Schwachstelle in einem oder mehreren Produkten an. VEX ist für das Zusammenspiel mit SBOMs, Schwachstellendatenbanken und Sicherheits-Advisories ausgelegt, braucht aber nichts davon.

Warum es VEX gibt: SBOM-Rauschen

Eine SBOM listet jede Komponente eines Produkts auf, einschließlich transitiver Abhängigkeiten. Ein Scanner gleicht diese Komponenten mit Advisories ab und meldet jede CVE in jeder gefundenen Version. Viele dieser Befunde treffen nicht zu: Die verwundbare Funktion wird nie aufgerufen, eine Build-Option kompiliert sie heraus, oder die Konfiguration des Produkts blockiert den Angriff. Ohne VEX muss jeder Kunde das allein herausfinden oder ein Support-Ticket beim Lieferanten eröffnen.

VEX verlagert diese Analyse zu der Partei, die sie einmal für alle erledigen kann: dem Lieferanten. Der Scanner des Kunden liest das VEX-Dokument und unterdrückt die Befunde, die der Lieferant als für das Produkt nicht relevant markiert hat.

Die vier VEX-Status

Jede VEX-Aussage trägt genau einen von vier Status:

Status	Bedeutung	Zusätzlich erforderlich
not_affected	Keine Behebung oder Abhilfemaßnahme erforderlich. Die Schwachstelle betrifft die aufgeführten Produkte nicht.	Eine Begründung oder ein Impact Statement, das erklärt, warum
affected	Die Schwachstelle betrifft die aufgeführten Produkte, und der Autor empfiehlt Maßnahmen.	Ein Action Statement: was Nutzer tun sollten
fixed	Die aufgeführten Produktversionen enthalten einen Fix.	Nichts weiter
under_investigation	Der Autor untersucht den Fall und hat noch nicht entschieden.	Nichts weiter; eine Änderung wird erwartet

VEX-Begründungen für not_affected

Eine not_affected-Aussage muss sagen, warum. Nach den Anforderungen von CISA SOLLTE sie eine von fünf Begründungen verwenden und MUSS andernfalls ein Impact Statement im Freitext angeben. OpenVEX und CSAF nutzen dieselben fünf:

• component_not_present: Die verwundbare Komponente ist nicht im Produkt enthalten.
• vulnerable_code_not_present: Die Komponente ist enthalten, der verwundbare Code aber nicht, meist aufgrund der Konfiguration oder des Builds.
• vulnerable_code_not_in_execute_path: Der verwundbare Code ist vorhanden, aber das Produkt ruft ihn nie auf.
• vulnerable_code_cannot_be_controlled_by_adversary: Der Code ist vorhanden und wird genutzt, aber ein Angreifer kann ihn nicht so steuern, dass er die Schwachstelle ausnutzt.
• inline_mitigations_already_exist: Eingebaute Schutzmaßnahmen, die Nutzer nicht deaktivieren können, verhindern die Ausnutzung.

Die Begründungen unterscheiden sich darin, welche Belege sie brauchen. component_not_present braucht eine genaue Aufzeichnung dessen, was das Produkt enthält. Die mittleren drei brauchen eine Codeanalyse, etwa eine Erreichbarkeitsanalyse oder ein manuelles Review, und werden von Kunden am häufigsten hinterfragt.

Was eine VEX-Aussage enthält

Die Mindestanforderungen von CISA nennen diese Elemente:

• Dokument-Metadaten: eine Dokument-ID, eine Version, die mit jeder Änderung steigt, den Autor (eine Person oder Organisation, kein Tool) und wann es zuerst herausgegeben und zuletzt aktualisiert wurde.
• Produktdetails: eine oder mehrere Produktkennungen, idealerweise dieselben, die die SBOM des Produkts nutzt, etwa eine Package-URL (purl). Eine Aussage kann außerdem die Unterkomponente nennen, die die Schwachstelle trägt.
• Schwachstellendetails: eine Schwachstellen-ID pro Aussage, meist eine CVE, und eine Beschreibung oder ein Link darauf.
• Status, mit der jeweils erforderlichen Begründung, dem Impact Statement oder Action Statement.
• Aussage-Metadaten: eine ID, eine Version und Zeitstempel für die Aussage selbst.

Ein Beispiel für ein VEX-Dokument

Dieses OpenVEX-Dokument besagt, dass ein Produkt, example-api 3.2.0, eine verwundbare Version von log4j-core ausliefert, aber nicht von Log4Shell betroffen ist, weil die verwundbare Klasse beim Build entfernt wird:

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

Das Produkt und seine Unterkomponente sind über Package-URLs identifiziert, sodass ein Scanner sie mit den Komponenten in der SBOM des Produkts abgleichen kann. Dieselbe Aussage in CycloneDX oder CSAF enthält dieselben Fakten in anderer Struktur.

VEX-Formate: OpenVEX, CycloneDX VEX und CSAF VEX

VEX ist eine Sammlung von Anforderungen, kein Dateiformat. CISA nennt drei Formate, die es transportieren können, und sie sind nicht austauschbar:

	OpenVEX	CycloneDX VEX	CSAF VEX
Was es ist	Ein kleines JSON-Format, das nur für VEX gemacht ist	Der Abschnitt vulnerabilities eines CycloneDX-Dokuments	Das Profil csaf_vex des CSAF-Advisory-Standards
Standard	Offene Spezifikation, v0.2.0	ECMA-424 (CycloneDX 1.6 und höher)	OASIS Standard (CSAF 2.0, 2022)
Status	Die vier VEX-Status	Eigene Analysezustände: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Produktstatus-Listen: known_not_affected, known_affected, fixed, under_investigation
Begründungen	Die fünf CISA-Begründungen	Neun eigene, etwa code_not_reachable und requires_configuration	Die fünf CISA-Begründungen, als Flags
Passt zu Teams, die	die kleinstmögliche VEX-Datei wollen	bereits CycloneDX-SBOMs ausliefern	bereits CSAF-Sicherheits-Advisories veröffentlichen
Von Trivy gelesen	Ja	Ja, bei SBOM-Scans	Ja
Von Grype gelesen	Ja	Nicht aufgeführt	Ja

OpenVEX ist am schlanksten: ein Dokument mit Autor, Zeitstempel, Version und einer Liste von Aussagen. Seine Spezifikation behandelt VEX als Abfolge von Aussagen, von denen jede die vorherigen überschreibt oder ergänzt.

CycloneDX VEX nutzt dieselbe vulnerabilities-Struktur, die CycloneDX für alles andere verwendet, mit einem analysis-Objekt, das einen Zustand, eine Begründung, Antwortwerte wie update oder will_not_fix und Freitext-Details enthält. Die VEX-Daten können in der SBOM oder in einem separaten CycloneDX-Dokument liegen, das per BOM-Link auf die SBOM verweist. Beachten Sie, dass sein Begründungsvokabular nicht das von CISA ist, die Konvertierung von oder nach OpenVEX oder CSAF also eine Zuordnung braucht. Zur SBOM-Seite siehe CycloneDX vs. SPDX.

CSAF VEX ist ein vollständiges CSAF-Dokument mit der Kategorie csaf_vex. Es verlangt einen Produktbaum, eine CVE oder andere ID, Notizen und für jedes Produkt ein Impact Statement (wenn nicht betroffen) oder eine Behebung (wenn betroffen). Es ist schwergewichtiger als OpenVEX, passt aber zu Organisationen, die bereits CSAF-Advisories über einen CSAF-Provider verteilen.

VEX vs. VDR

Ein Vulnerability Disclosure Report (VDR) listet die Schwachstellen auf, die ein Produkt betreffen, zusammen mit ihrer Analyse und Behebung. NIST SP 800-161 empfiehlt VDRs als Praxis für die Lieferkette, und CycloneDX unterstützt beides. Den Unterschied beschreiben die CycloneDX-Beispiele so:

• VDR sagt, welche Schwachstellen das Produkt betreffen. Es kann Schwachstellen abdecken, die in Ihrem eigenen Code gefunden und nirgendwo sonst veröffentlicht wurden.
• VEX ist vor allem eine negative Aussage: welche bekannten Schwachstellen das Produkt nicht betreffen und warum. Es deckt nur bekannte Schwachstellen ab.

Viele Lieferanten veröffentlichen beides: Das VDR beantwortet „Was muss ich beheben?“, das VEX beantwortet „Was kann ich ignorieren?“.

Wie Scanner VEX verarbeiten

Ein VEX-Dokument spart nur Arbeit, wenn die Tools des Kunden es lesen. Zwei weit verbreitete Open-Source-Scanner tun das:

• Trivy nimmt VEX über seine --vex-Option (als experimentell markiert) aus einer lokalen Datei, einem VEX-Repository, einer OCI-Attestierung oder einer Referenz in der SBOM entgegen. Es liest OpenVEX, CycloneDX VEX bei SBOM-Scans und CSAF VEX und meldet Schwachstellen, die als not_affected markiert sind, nicht mehr.
• Grype nimmt OpenVEX und CSAF VEX über --vex entgegen. Es verschiebt not_affected- und fixed-Treffer auf eine Ignorierliste, die mit --show-suppressed angezeigt wird, und kann optional affected- und under_investigation-Aussagen zu den Ergebnissen hinzufügen.

Der Abgleich hängt von den Kennungen ab. Wenn das VEX das Produkt mit einer anderen Kennung benennt als die SBOM, kann der Scanner sie nicht verbinden, und der Befund bleibt bestehen.

Wer VEX veröffentlicht

VEX kommt meist vom Lieferanten: dem Anbieter, der Open-Source-Distribution oder dem Gerätehersteller, der das Produkt ausliefert. Beim Lieferanten ist es eine PSIRT-Aufgabe, Teil desselben Lebenszyklus des Schwachstellenmanagements, der Advisories und Fixes hervorbringt. Red Hat zum Beispiel veröffentlicht CSAF-VEX-Dokumente in einem eigenen Verzeichnis seines CSAF-Feeds, neben seinen Advisories. Was PSIRT-Ingenieure im Alltag tun, lesen Sie unter PSIRT-Rolle.

Auch Kunden schreiben VEX für den eigenen Gebrauch und halten darin Triage-Entscheidungen zu einem Produkt eines Lieferanten fest, damit ihr Scanner sie nicht mehr meldet. Vorschriften wie der EU Cyber Resilience Act verlangen von Herstellern, Schwachstellen in den ausgelieferten Komponenten zu behandeln, und VEX ist ein Weg, Nutzern mitzuteilen, welche davon zutreffen.

VEX aktuell halten

• Status ändern sich. Eine Aussage beginnt meist als under_investigation und endet als not_affected oder als affected und dann fixed. Veröffentlichen Sie jede Änderung; CISA verlangt, dass die Version jedes Mal steigt.
• Neue Releases brauchen neue Aussagen. Ein not_affected-Urteil für 3.2.0 sagt nichts über 3.3.0 aus. Prüfen Sie es erneut, wenn sich die Komponente, ihre Version oder die Build-Konfiguration ändert.
• Halten Sie VEX von der SBOM getrennt. Die SBOM beschreibt ein Release und bleibt unverändert. VEX ändert sich auch nach dem Release weiter, und als eigenes Dokument vermeidet es, dass SBOMs neu herausgegeben werden müssen.
• Veröffentlichen Sie dort, wo Tools suchen. Neben der SBOM, als Attestierung am Container-Image oder in Ihrem Advisory-Feed, und nennen Sie den Ort in Ihrer Offenlegungsrichtlinie. Siehe koordinierte Offenlegung von Schwachstellen.

Grenzen von VEX

• Es ist eine Behauptung, kein Beweis. Eine not_affected-Aussage ist die Einschätzung des Autors. CISA empfiehlt, die Identität des Autors kryptografisch an das Dokument zu binden, aber die meisten Nutzer vertrauen VEX weiterhin, weil sie dem Lieferanten vertrauen.
• Schweigen bedeutet nichts. VEX impliziert keinen Standardstatus. Eine Schwachstelle ohne Aussage ist unbekannt, nicht „nicht betroffen“.
• Formate lassen sich nicht eins zu eins abbilden. CycloneDX nutzt andere Zustände und Begründungen als OpenVEX und CSAF, sodass bei Konvertierungen Details verloren gehen.
• Es ist nur so gut wie das Inventar. Um zu sagen, dass eine Komponente nicht vorhanden ist, müssen Sie genau wissen, was das Produkt enthält, einschließlich transitiver Abhängigkeiten und allem, was der Build außerhalb des Paketmanagers heruntergeladen hat.

VEX beginnt mit einer genauen SBOM

Jede VEX-Aussage verweist auf Komponenten, und die am leichtesten zu verteidigende Begründung, component_not_present, stimmt nur, wenn das Inventar vollständig ist. Eine SBOM, die durch nachträgliches Scannen von Lockfiles entsteht, kann Entwicklungsabhängigkeiten auflisten, die nie ausgeliefert werden, und Pakete übersehen, die der Build auf anderem Weg geladen hat.

CRACI führt GitHub-Actions-Builds auf seinen eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus Caches wiederhergestellter Pakete und Abhängigkeiten, die kein Lockfile auflistet. Jede SBOM trägt einen Vollständigkeitsstatus und lässt sich als CycloneDX oder SPDX exportieren. Überwachte SBOMs werden laufend neu bewertet, die Build-Historie zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, und CRACI unterstützt VEX. Siehe SBOM-Generierung und Schwachstellenverfolgung.

VEX: häufig gestellte Fragen

Wofür steht VEX?

VEX steht für Vulnerability Exploitability eXchange. Es ist eine maschinenlesbare Aussage darüber, ob ein Produkt von einer bestimmten bekannten Schwachstelle betroffen ist, veröffentlicht, damit Nutzer wissen, welche gemeldeten Schwachstellen Handeln erfordern.

Was ist der Unterschied zwischen einer SBOM und VEX?

Eine SBOM listet die Komponenten eines Produkts auf. VEX sagt für eine bestimmte Schwachstelle, ob dieses Produkt betroffen ist. Die SBOM ändert sich nach einem Release selten; VEX-Aussagen ändern sich, während der Lieferant untersucht und behebt. Deshalb wird VEX meist als separates Dokument veröffentlicht, das auf das Produkt verweist, statt in die SBOM eingebaut zu werden.

Was sind die vier VEX-Status?

not_affected, affected, fixed und under_investigation. Eine not_affected-Aussage braucht eine Begründung oder ein Impact Statement, und eine affected-Aussage ein Action Statement, das sagt, was Nutzer tun sollten.

Welches VEX-Format sollte ich verwenden?

Nutzen Sie das Format, das Ihre Abnehmer und Tools lesen. OpenVEX ist am kleinsten und funktioniert mit Trivy und Grype. CycloneDX VEX passt zu Teams, die bereits CycloneDX-SBOMs ausliefern. CSAF VEX passt zu Organisationen, die bereits CSAF-Sicherheits-Advisories veröffentlichen, was in Industrie- und Unternehmenssoftware verbreitet ist. Viele Lieferanten konvertieren am Ende zwischen ihnen.

Ist VEX dasselbe wie ein Sicherheits-Advisory?

Nein. Ein Sicherheits-Advisory erklärt eine Schwachstelle, wer betroffen ist und wie sie zu beheben ist, vor allem für Menschen. VEX ist ein enger, maschinenlesbarer Status pro Produkt und Schwachstelle, vor allem für Tools. Beide treten oft gemeinsam auf: Der Standard CSAF hat sowohl ein Profil für Sicherheits-Advisories als auch ein VEX-Profil.

Wer schreibt VEX-Dokumente?

Meist der Lieferant des Produkts, oft dessen Product Security Incident Response Team (PSIRT), weil er weiß, wie das Produkt gebaut und konfiguriert ist. Die Mindestanforderungen von CISA erlauben auch Dritten, VEX zu verfassen, und jedes Dokument muss seinen Autor nennen.

Lesen Schwachstellenscanner VEX?

Mehrere tun das. Trivy akzeptiert OpenVEX, CycloneDX und CSAF VEX über seine Option --vex und verwirft als not_affected markierte Befunde. Grype akzeptiert OpenVEX und CSAF VEX über --vex und verschiebt not_affected- und fixed-Befunde auf eine Ignorierliste.