VEX

VEX steht für „Vulnerability Exploitability eXchange“. Ein VEX-Dokument beantwortet für eine bestimmte Schwachstelle und ein bestimmtes Produkt genau eine Frage: Ist dieses Produkt betroffen?

Der Anlass dafür ist ein praktisches Problem. Der Abgleich einer Software-Stückliste (SBOM) mit Schwachstellendatenbanken liefert regelmäßig lange Trefferlisten. Ein großer Teil davon geht ins Leere, weil die verwundbare Funktion in Ihrem Produkt gar nicht erreichbar ist. Ohne dokumentierte Einordnung wird jede dieser Fundstellen erneut geprüft, bei jedem Scan, von jedem Kunden.

Die vier Statuswerte

• nicht betroffen bedeutet, dass die Schwachstelle sich auf dieses Produkt nicht auswirkt. Dieser Status verlangt eine Begründung, etwa dass der verwundbare Code nie ausgeführt wird oder durch die Konfiguration abgeschirmt ist.
• betroffen heißt, dass die Schwachstelle sich auswirkt; üblicherweise steht dabei ein Hinweis auf Gegenmaßnahmen.
• behoben zeigt an, dass eine Version mit Korrektur bereitsteht.
• in Prüfung sagt, dass die Bewertung noch läuft. Auch das ist eine ehrliche und nützliche Aussage.

Der interessanteste Wert ist der erste. „Nicht betroffen“ mit nachvollziehbarer Begründung ist die Aussage, die auf beiden Seiten der Lieferkette den meisten Aufwand einspart.

Die Begründung ist der eigentliche Inhalt

Ein „nicht betroffen“ ohne Begründung ist wertlos. Der Empfänger kann nicht unterscheiden, ob Sie sorgfältig geprüft haben oder die Schwachstelle nur nicht bearbeiten wollen. Deshalb sind fünf standardisierte Begründungen üblich:

• Komponente nicht enthalten: Die verwundbare Teilkomponente steckt gar nicht im Produkt, obwohl ein oberflächlicher Abgleich das nahelegte.
• Verwundbarer Code nicht enthalten: Die Komponente ist enthalten, der betroffene Codeteil aber nicht, etwa weil der Build ungenutzte Module entfernt.
• Verwundbarer Code nicht im Ausführungspfad: Der Code liegt vor, wird aber von Ihrem Produkt nie erreicht.
• Verwundbarer Code nicht durch Angreifer steuerbar: Er wird ausgeführt, aber ein Angreifer kann die dafür nötigen Eingaben nicht beeinflussen.
• Gegenmaßnahmen bereits wirksam: Die Ausnutzung ist durch bestehende Schutzmechanismen im Produkt bereits verhindert.

Die dritte Begründung ist die häufigste und zugleich die anspruchsvollste: Sie setzt eine Erreichbarkeitsanalyse voraus. Wer sie angibt, sollte nachvollziehbar festhalten, worauf sie beruht. Im Zweifel ist genau das die Aussage, die später geprüft wird.

Was in ein VEX-Dokument gehört

Unabhängig vom Format braucht jede Aussage vier Angaben, damit sie maschinell verwertbar ist:

• eine eindeutige Kennung des Produkts und seiner Version, idealerweise dieselbe, die auch die Software-Stückliste (SBOM) verwendet
• die Schwachstelle, üblicherweise über die CVE-Kennung
• den Status und, bei „nicht betroffen“, die Begründung
• einen Zeitstempel, denn jede Aussage gilt nur für einen Stand

Der letzte Punkt wird regelmäßig unterschätzt. Ein VEX-Dokument ist eine Momentaufnahme: Ändert sich die Produktversion oder die Erkenntnislage, muss die Aussage nachgezogen werden. Ein veraltetes „nicht betroffen“ ist schlimmer als gar keine Aussage.

Formate

VEX ist ein Konzept, kein einzelnes Dateiformat. Verbreitet sind drei Umsetzungen: als Erweiterung von CycloneDX, als Profil des CSAF-Standards für Sicherheitshinweise und als schlankes eigenständiges Format namens OpenVEX. Welches passt, hängt davon ab, womit Ihre Werkzeuge und Ihre Abnehmer arbeiten.

Warum sich der Aufwand rechnet

VEX verschiebt Arbeit von der Reaktion in die Dokumentation. Statt bei jeder prominenten Schwachstelle dieselbe Analyse zu wiederholen und dieselben Kundenanfragen einzeln zu beantworten, wird die Bewertung einmal festgehalten und maschinenlesbar weitergegeben.

Der Nebeneffekt ist für den Cyber Resilience Act (CRA) unmittelbar relevant: Es entsteht eine belegte Historie, welche Schwachstelle wann wie bewertet wurde. Genau diese Nachvollziehbarkeit erwarten Marktüberwachungsbehörden, wenn sie die Behandlung von Schwachstellen prüfen.