VEX erklärt: Welche Schwachstellen sind wirklich relevant?

Durch den vermehrten Einsatz von Dritt-Software-Komponenten und die steigende Anzahl an täglichen neuen Schwachstellen führt kein Weg mehr an der systematischen Analyse von Schwachstellen vorbei. Wer sich bereits mit den bekannten CVE-Datenbanken beschäftigt hat, weiß, dass die Flut an gefundenen CVEs oft nur bedingt hilfreich ist. Nicht jede gemeldete Schwachstelle stellt tatsächlich ein Risiko dar, oftmals sind diese nicht relevant für das eingesetzte Produkt, die Konfiguration oder den Nutzungskontext. Hier kommt der VEX-Standard (Vulnerability Exploitability eXchange) ins Spiel.

Was ist VEX?

VEX ist ein maschinenlesbares Format, das beschreibt, ob und wie ein Softwareprodukt von einer bestimmten Schwachstelle betroffen ist. Statt sich auf allgemeine CVE-Beschreibungen zu verlassen, erlaubt VEX eine produktspezifische Einschätzung. Das VEX-Dokument wird in der Regel von Softwareherstellern oder Softwareanbietern erstellt. Also von den Unternehmen, welche die betroffene Software entwickeln, vertreiben oder in andere Produkte integriert haben. Der VEX-Standard wurde im Rahmen der Common Security Advisory Framework (CASF)-Initiative entwickelt. Das Ziel ist es nicht festzustellen, ob eine Schwachstelle vorhanden ist, sondern ob diese bekannte Schwachstelle in dem Produkt tatsächlich ausnutzbar ist.

Spezifikation und Inhalt von VEX

Es gibt leider nicht die eine VEX-Spezifikationen. Aktuell gibt es verschiedene Spezifikationen, welche genutzt werden können. Die bekanntesten sind CSAF Vex, CycloneDX VEX und OpenVEX. Daneben gibt es noch Herstellerindividuelle Formate (z.B. von Microsoft). Die folgende Tabelle beschreibt die verschiedenen Spezifikationen.

Meistens wird die VEX-Datei als JSON oder XML verwendet.

Inhalt einer VEX-Datei

Unabhängig on der Spezifikation soll der Inhalt einer VEX-Datei die Möglichkeit geben die Frage zu beantworten, ob eine spezifische Schwachstelle (CVE) für das konkrete Produkt relevant ist oder eben nicht. Daher ist der folgenden Inhalt in allen Spezifikationen zu finden.

• Produkt- und Komponenteninformationen – welches Produkt in welcher Version ist betroffen?
• Referenz zu einer konkreten CVE-ID
• Statusangabe zur Schwachstelle – z. B. not_affected, affected, fixed, under_investigation
• Begründung für die Statusangabe und zusätzliche Informationen zur Remediation
• Zeitstempel und Metadaten

Die CycloneDX VEX Spezifikation lässt sich optimal in SBOMs basierend auf dem CycloneDX Standard integrieren. Hier findest du ein Beispiel im JSON-Format.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata" : {
    "timestamp" : "2022-03-03T00:00:00Z",
    "component" : {
      "name" : "ABC",
      "type" : "application",
      "bom-ref" : "product-ABC"
    }
  },
  "vulnerabilities": [
    {
      "id": "CVE-2021-44228",
      "source": {
        "name": "NVD",
        "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
      },
      "ratings": [
        {
          "source": {
            "name": "NVD",
            "url": "https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H&version=3.1"
          },
          "score": 10.0,
          "severity": "critical",
          "method": "CVSSv31",
          "vector": "AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
        }
      ],
      "analysis": {
        "state": "exploitable",
        "response": ["will_not_fix", "update"],
        "detail": "Versions of Product ABC are affected by the vulnerability. Customers are advised to upgrade to the latest release."
      },
      "affects": [
        {
          "ref": "product-ABC",
          "versions": [
            {
              "version": "2.4",
              "status": "affected"
            },
            {
              "version": "2.6",
              "status": "affected"
            },
            {
              "range": "vers:generic/>=2.9|<=4.1",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ]
}

Integration von VEX in bestehende Prozesse

VEX (Vulnerability Exploitability eXchange) lässt sich ideal mit anderen Sicherheitsartefakten kombinieren, wie beispielsweise der SBOM (Software Bill of Material). Zum Teil sind in der SBOM auch bereits die entsprechenden Informationen zu den Schwachstellen vorhanden. Hierbei muss jedoch beachtet werden, dass der Cyber Resilience Act es explizit verbietet, die SBOM mit VEX Informationen anzureichen. Was der Cyber Resilience Act konkret dazu sagt, kannst du hier nachlesen. Die folgende Liste zeigt, in welchen Prozessen oder Einsatzbereichen sich die Informationen der VEX besonders gut integrieren lassen.

VEX funktioniert am besten im Zusammenspiel mit anderen Sicherheitsartefakten – allen voran der ### SBOM (Software Bill of Materials). Beispielhafte Integrationspunkte:

• SCA-Tools können VEX-Dateien auswerten und automatisch Schwachstellen ausschließen, die für das konkrete Produkt nicht relevant sind. SCA-Tools können jedoch auch VEX-Dateien exportieren.
• CI/CD-Pipelines lassen sich so erweitern, dass sie VEX-Informationen prüfen und Builds bei tatsächlich kritischen CVEs stoppen – während sie bei harmlosen Schwachstellen ohne Verzug weiterlaufen.
• Security Dashboards profitieren von dem zusätzlichen Kontext und ermöglichen eine risikobasierte Priorisierung, die echte Bedrohungen schneller sichtbar macht.

VEX wird bereits von etablierten Formaten wie CycloneDX unterstützt und fügt sich damit nahtlos in moderne Toolchains ein.

Herausforderungen bei der Einführung

Trotz der klaren Vorteile sind bei der praktischen Einführung von VEX noch einige Punkte zu beachten:

• Erstellung der VEX-Daten: Wer liefert die Informationen – der Softwarehersteller, Open-Source-Maintainer oder ein externer Dienstleister?
• Verlässlichkeit der Angaben: Nicht alle VEX-Informationen sind automatisch vertrauenswürdig. Eine unabhängige Verifikation bleibt in vielen Fällen sinnvoll.
• Tooling und Support: Noch unterstützen nicht alle SCA-Tools oder SBOM-Generatoren den VEX-Standard vollständig, was die Integration erschweren kann.

Fazit

VEX ist ein vielversprechender Baustein für moderne Security-Prozesse – gerade in einer Zeit, in der die Anzahl gemeldeter Schwachstellen rasant steigt und Unternehmen unter hohem Handlungsdruck stehen. Durch die Kombination mit SBOMs, CI/CD-Pipelines und SCA-Tools schafft VEX die nötige Transparenz, um Schwachstellen nicht nur zu erkennen, sondern auch realistisch bewerten zu können.

Dabei ersetzt VEX nicht die Nutzung von Schwachstellendatenbanken wie der NVD oder CVE.org – vielmehr ergänzt es diese um eine entscheidende Komponente: den konkreten Kontext. Während CVE-Datenbanken Schwachstellen beschreiben, liefert VEX die Einschätzung, ob eine Schwachstelle für ein bestimmtes Produkt tatsächlich ausnutzbar ist. Genau diese Kontextinformation ist im Alltag oft entscheidend, um zwischen kritischen und vernachlässigbaren Risiken zu unterscheiden.

Zwar gibt es aktuell noch Herausforderungen bei der Einführung – etwa bei der Tool-Unterstützung oder der Frage nach der Quelle der VEX-Daten –, doch der Nutzen überwiegt deutlich: Unternehmen gewinnen an Effizienz, reduzieren unnötige Aufwände im Schwachstellenmanagement und können Risiken gezielter priorisieren.

Wer sich heute mit VEX beschäftigt, legt den Grundstein für ein risikobasiertes Schwachstellenmanagement von morgen – und bringt sich frühzeitig in eine gute Position, auch regulatorische Anforderungen wie den Cyber Resilience Act souverän zu erfüllen.