VEX für CRA-Compliance: Leitfaden zum Vulnerability Exploitability eXchange

Wie Sie VEX-Dokumente für die CRA-Compliance nutzen. Umfasst VEX-Formate, Statustypen, Integration mit SBOM und praktische Beispiele zur Kommunikation der Schwachstellen-Anwendbarkeit.

CRA Evidence-Team
Autor
14. Januar 2026
Aktualisiert 25. Februar 2026, 00:00:00 UTC
10 Min. Lesezeit
VEX für CRA-Compliance: Leitfaden zum Vulnerability Exploitability eXchange
In this article

Nicht jede Schwachstelle in Ihrer SBOM betrifft Ihr Produkt. VEX (Vulnerability Exploitability eXchange) ermöglicht es Ihnen zu kommunizieren, welche Schwachstellen tatsächlich auf Ihr spezifisches Produkt und Ihren Kontext zutreffen. Für die CRA-Compliance hilft VEX dabei nachzuweisen, dass Sie Schwachstellen bewertet und die relevanten behoben haben.

Dieser Leitfaden erklärt, wie Sie VEX effektiv einsetzen.

Info: VEX (Vulnerability Exploitability eXchange) ermöglicht es Ihnen zu kommunizieren, welche Schwachstellen in Ihrer SBOM tatsächlich Ihr Produkt betreffen -- und welche nicht. Es ist wesentlich für die Erfüllung der CRA-Anforderung "keine bekannten ausnutzbaren Schwachstellen".

Zusammenfassung

  • VEX = maschinenlesbare Aussage über Schwachstellen-Anwendbarkeit
  • Beantwortet: "Betrifft CVE-XXXX MEIN Produkt?"
  • Vier Status: Nicht betroffen, Betroffen, Behoben, In Untersuchung
  • Ergänzt SBOM: SBOM listet Komponenten, VEX bewertet Schwachstellen
  • CycloneDX VEX und CSAF VEX sind die Hauptformate
  • Wesentlich für die CRA-Anforderung "keine bekannten ausnutzbaren Schwachstellen"

VEX-Status-Ablauf — Nicht betroffen, Unter Untersuchung, Betroffen, Behoben

Was ist VEX?

Das Problem, das VEX löst

Wenn Sie eine SBOM scannen, erhalten Sie eine Liste von Schwachstellen in Komponenten:

SBOM-SCAN-ERGEBNISSE (Typisch):

Komponente: openssl 1.1.1k
  - CVE-2021-3711 (Kritisch)
  - CVE-2021-3712 (Hoch)
  - CVE-2022-0778 (Hoch)

Komponente: zlib 1.2.11
  - CVE-2018-25032 (Hoch)

Komponente: libxml2 2.9.10
  - CVE-2021-3517 (Hoch)
  - CVE-2021-3518 (Hoch)
  - CVE-2022-23308 (Mittel)

GESAMT: 8 Schwachstellen gefunden

ABER MOMENT...
- Betreffen alle diese tatsächlich Ihr Produkt?
- Wird der anfällige Codepfad verwendet?
- Haben Sie einige bereits mitigiert?
- Sind einige in Ihrem Kontext nicht ausnutzbar?

VEX beantwortet diese Fragen.

VEX-Definition

VEX (Vulnerability Exploitability eXchange) ist ein standardisiertes Format zur Kommunikation von:

  • Ob eine Schwachstelle ein bestimmtes Produkt betrifft
  • Warum oder warum nicht
  • Welche Maßnahmen (falls erforderlich) nötig sind
  • Aktueller Status der Bewertung

VEX-Statustypen

VEX-STATUSOPTIONEN

NICHT BETROFFEN (NOT AFFECTED):
"Diese Schwachstelle betrifft unser Produkt nicht"
- Anfälliger Code nicht vorhanden
- Anfällige Funktion wird nicht aufgerufen
- Plattform nicht zutreffend
- Durch Konfiguration mitigiert

BETROFFEN (AFFECTED):
"Diese Schwachstelle betrifft unser Produkt"
- Erfordert Maßnahmen
- Kann empfohlene Mitigationen enthalten
- Zeigt Schweregrad im Kontext an

BEHOBEN (FIXED):
"Diese Schwachstelle wurde behoben"
- In bestimmter Version
- Details zur Behebung bereitgestellt
- Update-Empfehlung

IN UNTERSUCHUNG (UNDER INVESTIGATION):
"Wir bewerten dies noch"
- Status noch nicht bestimmt
- Untersuchung läuft
- Temporärer Status

VEX und CRA-Anforderungen

CRA-Schwachstellenanforderungen

Der CRA verlangt von Herstellern:

  1. Keine bekannten ausnutzbaren Schwachstellen (bei Marktbereitstellung)
  2. Schwachstellen behandeln während der gesamten Supportperiode
  3. Sicherheitsupdates bereitstellen zur Behebung von Schwachstellen
  4. Aktiv ausgenutzte Schwachstellen melden an ENISA (24 Stunden)
  5. Schwerwiegende Schwachstellen melden an ENISA (72 Stunden)

Wie VEX den CRA unterstützt

VEX FÜR CRA-COMPLIANCE

ANFORDERUNG: Keine bekannten ausnutzbaren Schwachstellen

VEX-ROLLE:
- Dokumentation der Schwachstellenbewertung
- Zeigt, welche CVEs bewertet wurden
- Demonstriert "nicht betroffen"-Feststellungen
- Nachweis für Technische Dokumentation

ANFORDERUNG: Schwachstellen behandeln

VEX-ROLLE:
- Verfolgt Statusänderungen bei Schwachstellen
- Dokumentiert "betroffen" → "behoben" Verlauf
- Kommunikation mit Kunden
- Führt Prüfpfad

ANFORDERUNG: Sicherheitsupdates

VEX-ROLLE:
- Dokumentiert, was in jedem Update behoben wurde
- Liefert "behoben in Version X"-Information
- Werkzeug zur Kundenkommunikation

ANFORDERUNG: ENISA-Meldung

VEX-ROLLE:
- Vorbewertung hilft bei Bestimmung der Meldepflicht
- "Betroffen" + "aktiv ausgenutzt" = Meldung
- Dokumentation für Genauigkeit der Meldung

Tipp: CycloneDX hat native VEX-Unterstützung. Wenn Sie bereits CycloneDX-SBOMs generieren, ist das Hinzufügen von VEX-Daten unkompliziert.

VEX-Formate

CycloneDX VEX

CycloneDX enthält VEX-Fähigkeit als Teil des SBOM-Formats:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2021-3711",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_present",
        "detail": "Unser Produkt verwendet OpenSSL, nutzt aber nicht die SM2-Funktionalität, in der diese Schwachstelle existiert. SM2 ist in unserem Build nicht kompiliert."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ]
    },
    {
      "id": "CVE-2022-0778",
      "source": {
        "name": "NVD"
      },
      "analysis": {
        "state": "affected",
        "detail": "Produkt ist beim Parsen nicht vertrauenswürdiger Zertifikate betroffen. Behoben in Version 2.1.0."
      },
      "affects": [
        {
          "ref": "openssl-1.1.1k"
        }
      ],
      "recommendation": "Update auf Produktversion 2.1.0 oder höher"
    }
  ]
}

CSAF VEX

CSAF (Common Security Advisory Framework) bietet ein eigenständiges VEX-Dokumentformat:

{
  "document": {
    "category": "csaf_vex",
    "title": "Produkt-Sicherheitsbewertung für CVE-2021-3711",
    "publisher": {
      "category": "vendor",
      "name": "Beispiel GmbH"
    },
    "tracking": {
      "id": "EX-2024-001",
      "status": "final",
      "version": "1.0.0",
      "current_release_date": "2024-01-15T10:00:00Z"
    }
  },
  "product_tree": {
    "branches": [
      {
        "category": "product_name",
        "name": "Smart Sensor Pro",
        "product": {
          "product_id": "SSP-2.0",
          "name": "Smart Sensor Pro 2.0"
        }
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2021-3711",
      "product_status": {
        "known_not_affected": ["SSP-2.0"]
      },
      "flags": [
        {
          "label": "vulnerable_code_not_present",
          "product_ids": ["SSP-2.0"]
        }
      ],
      "notes": [
        {
          "category": "description",
          "text": "SM2-Funktionalität ist in unserem OpenSSL-Build nicht enthalten."
        }
      ]
    }
  ]
}

OpenVEX

OpenVEX ist ein einfacheres, fokussiertes VEX-Format:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2024-001",
  "author": "Beispiel GmbH Sicherheitsteam",
  "timestamp": "2024-01-15T10:00:00Z",
  "statements": [
    {
      "vulnerability": {
        "@id": "CVE-2021-3711"
      },
      "products": [
        {
          "@id": "pkg:generic/smart-sensor-pro@2.0"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "SM2-Kryptografie-Funktionalität ist nicht in den OpenSSL-Build unseres Produkts kompiliert."
    }
  ]
}

Erstellen von VEX-Aussagen

Bewertungsprozess

VEX-BEWERTUNGSWORKFLOW

SCHRITT 1: SCHWACHSTELLE IDENTIFIZIEREN
- Aus SBOM-Scan-Ergebnissen
- Aus Sicherheitshinweis
- Aus Kundenmeldung
- Aus ENISA-Benachrichtigung

SCHRITT 2: ANWENDBARKEIT ANALYSIEREN
Zu beantwortende Fragen:
- Ist die anfällige Komponente in unserem Produkt?
- Ist die anfällige Version vorhanden?
- Wird der anfällige Codepfad verwendet?
- Ist die Schwachstelle in unserem Kontext ausnutzbar?
- Sind bereits Mitigationen vorhanden?

SCHRITT 3: STATUS BESTIMMEN
Basierend auf Analyse:
- NOT_AFFECTED: Schwachstelle trifft nicht zu
- AFFECTED: Schwachstelle trifft zu, Maßnahme erforderlich
- FIXED: War betroffen, jetzt behoben
- UNDER_INVESTIGATION: Noch in Bewertung

SCHRITT 4: BEGRÜNDUNG DOKUMENTIEREN
Für NOT_AFFECTED, spezifizieren warum:
- vulnerable_code_not_present
- vulnerable_code_cannot_be_controlled_by_adversary
- vulnerable_code_not_in_execute_path
- inline_mitigations_already_exist

SCHRITT 5: VEX-DOKUMENT ERSTELLEN
- Gewähltes Format verwenden
- Alle erforderlichen Felder einschließen
- Dokument versionieren und datieren
- Wenn möglich signieren

Begründungstypen

NOT_AFFECTED BEGRÜNDUNGEN

VULNERABLE_CODE_NOT_PRESENT:
"Der anfällige Code ist in unserem Build nicht enthalten"
Beispiel: OpenSSL ohne SM2-Unterstützung kompiliert

VULNERABLE_CODE_CANNOT_BE_CONTROLLED_BY_ADVERSARY:
"Ein Angreifer kann den anfälligen Code nicht erreichen"
Beispiel: Funktion wird nur mit vertrauenswürdigen internen Daten aufgerufen

VULNERABLE_CODE_NOT_IN_EXECUTE_PATH:
"Die anfällige Funktion wird nie aufgerufen"
Beispiel: Bibliothek enthalten, aber spezifische Funktion ungenutzt

INLINE_MITIGATIONS_ALREADY_EXIST:
"Andere Kontrollen verhindern Ausnutzung"
Beispiel: WAF blockiert Angriffsvektor, Sandboxing begrenzt Auswirkung

Beispielbewertungen

BEISPIEL 1: Nicht betroffen (Code nicht vorhanden)

Schwachstelle: CVE-2021-3711 (OpenSSL SM2 Buffer Overflow)
Komponente: openssl 1.1.1k
Bewertung: Unser Produkt verwendet OpenSSL nur für TLS.
           SM2 ist ein chinesischer Kryptografiestandard, den wir nicht nutzen.
           Unser Build deaktiviert SM2 explizit: ./config no-sm2
Status: NOT_AFFECTED
Begründung: vulnerable_code_not_present

BEISPIEL 2: Nicht betroffen (Nicht im Ausführungspfad)

Schwachstelle: CVE-2022-23308 (libxml2 Use-After-Free)
Komponente: libxml2 2.9.10
Bewertung: Schwachstelle in XPath-Auswertung mit Namespaces.
           Unser Produkt verwendet libxml2 nur für einfaches XML-Parsing.
           Wir nutzen XPath-Funktionalität nie.
Status: NOT_AFFECTED
Begründung: vulnerable_code_not_in_execute_path

BEISPIEL 3: Betroffen

Schwachstelle: CVE-2022-0778 (OpenSSL Endlosschleife)
Komponente: openssl 1.1.1k
Bewertung: Unser Produkt verarbeitet TLS-Zertifikate von
           potenziell nicht vertrauenswürdigen Quellen. Die Schwachstelle
           ermöglicht DoS über bösartiges Zertifikat.
Status: AFFECTED
Empfehlung: Update auf Produktversion 2.1.0 (OpenSSL 1.1.1n)

BEISPIEL 4: Behoben

Schwachstelle: CVE-2022-0778 (OpenSSL Endlosschleife)
Komponente: openssl (war 1.1.1k, jetzt 1.1.1n)
Bewertung: Behoben in Produktversion 2.1.0
Status: FIXED
Behobene Version: 2.1.0

VEX-Workflow für CRA

Kontinuierliche Bewertung

FORTLAUFENDER VEX-PROZESS

TÄGLICH/WÖCHENTLICH:
1. SBOM auf neue Schwachstellen scannen
2. Nach Schweregrad priorisieren
3. Bewertung von hoch/kritisch beginnen

FÜR JEDE SCHWACHSTELLE:
1. Technische Analyse
2. Status bestimmen
3. VEX-Aussage erstellen/aktualisieren
4. Falls AFFECTED: Behebung planen

WENN BEHOBEN:
1. VEX-Status auf FIXED aktualisieren
2. Auf behobene Version verweisen
3. Kunden benachrichtigen
4. Technische Dokumentation aktualisieren

FÜR ENISA-MELDUNG:
1. AFFECTED + aktiv ausgenutzt  Meldung 24 Std.
2. AFFECTED + schwerwiegend  Meldung 72 Std.
3. VEX in Meldungskontext einbeziehen

Integration mit SBOM

SBOM + VEX INTEGRATION

OPTION 1: Eingebettetes VEX (CycloneDX)
- VEX-Daten innerhalb des SBOM-Dokuments
- Einzelne Datei für Komponenten + Schwachstellen
- SBOM bei VEX-Änderungen aktualisieren

OPTION 2: Verlinktes VEX
- Separates VEX-Dokument
- Verweist auf SBOM-Komponenten
- Kann unabhängig aktualisiert werden

OPTION 3: CSAF-Advisories
- Eigenständige Sicherheitshinweise
- Auf Sicherheitsseite veröffentlicht
- Maschinenlesbar für Automatisierung

EMPFEHLUNG FÜR CRA:
- Eingebettetes VEX für Technische Dokumentation (vollständiger Nachweis)
- CSAF-Advisories für Kundenkommunikation veröffentlichen
- Beides pflegen, synchron halten

Kundenkommunikation

VEX FÜR KUNDENKOMMUNIKATION

SZENARIO: Kunde fragt "Betrifft CVE-XXXX Ihr Produkt?"

MIT VEX:
1. VEX-Datenbank auf Schwachstelle prüfen
2. Status sofort bereitstellen
3. Falls NOT_AFFECTED: Begründung teilen
4. Falls AFFECTED: Behebungsanleitung geben
5. Falls UNDER_INVESTIGATION: Zeitplan nennen

VORTEILE:
- Konsistente Antworten im gesamten Support-Team
- Vorbereitete Begründungen
- Schnellere Reaktionszeit
- Nachweisbare Sorgfaltspflicht

VEX in der Technischen Dokumentation

Dokumentationsansatz

TECHNISCHE DOKUMENTATION VEX-ABSCHNITT

ABSCHNITT: Schwachstellenbewertung (VEX)

INHALTE:
1. Beschreibung der VEX-Methodik
2. Aktuelles VEX-Dokument (alle Produkte)
3. Historische VEX-Updates (Prüfpfad)
4. Nachweise für Nicht-betroffen-Begründungen

BEISPIELEINTRAG:
"Zum Stand [Datum] wurden folgende Schwachstellen
für [Produktname] Version [X.Y.Z] bewertet:

Gesamt-CVEs in Komponentenabhängigkeiten: 47
- Nicht betroffen: 41
- Behoben: 4
- In Untersuchung: 2
- Betroffen (mit Mitigation): 0

VEX-Dokument: [Link/Anlage]
Zuletzt aktualisiert: [Datum]"

Nachweis für "Keine bekannten ausnutzbaren Schwachstellen"

CRA-COMPLIANCE-NACHWEIS

BEHAUPTUNG: Produkt hat keine bekannten ausnutzbaren Schwachstellen

NACHWEIS (VEX-basiert):
1. SBOM-Scan-Ergebnisse (datiert)
2. VEX-Bewertung aller Befunde
3. Für jedes "Nicht betroffen": Begründung
4. Für jedes "Behoben": Versionsinformation
5. Für "In Untersuchung": Zeitplan/Status

PRÜFPFAD:
- Wann wurde jede CVE bewertet?
- Wer hat die Bewertung durchgeführt?
- Was war die Begründung?
- Wann wurde der Status aktualisiert?

Tools und Automatisierung

VEX-Generierungstools

VEX-TOOLING-OPTIONEN

SBOM + SCHWACHSTELLEN-MATCHING:
- Grype (Anchore) - generiert VEX
- Trivy - Schwachstellen-Scanning mit VEX-Ausgabe
- OWASP Dependency-Track - VEX-Unterstützung

VEX-ERSTELLUNG:
- CycloneDX CLI - VEX erstellen/validieren
- CSAF-Tools - CSAF-VEX-Dokumente erstellen
- OpenVEX-Tools - einfache VEX-Erstellung

AUTOMATISIERUNG:
- CI/CD-Integration für Scanning
- Automatischer "in Untersuchung"-Status
- Manuelle Überprüfung für finalen Status

Automatisierungsstrategie

VEX-AUTOMATISIERUNGSANSATZ

AUTOMATISIERT:
- SBOM-Scanning auf neue CVEs
- Initialer "in Untersuchung"-Status
- Benachrichtigung an Sicherheitsteam
- Grundlegende Anwendbarkeitsprüfungen

SEMI-AUTOMATISIERT:
- Vorschläge zur Codepfad-Analyse
- Historischer Musterabgleich
- Statusabfrage ähnlicher Produkte

MANUELL (Erforderlich):
- Finale Statusbestimmung
- Begründung verfassen
- Kundengerichtete Kommunikation
- ENISA-Meldeentscheidungen

Häufige Herausforderungen

Herausforderung: CVE-Volumen

Problem: SBOM-Scans liefern Hunderte von CVEs.

Lösungen:

  • Nach Schweregrad priorisieren (Kritisch/Hoch zuerst)
  • Automatisierung für initiale Triage nutzen
  • Begründungsvorlagen für häufige Muster erstellen
  • Auf Komponenten konzentrieren, die Sie kontrollieren

Herausforderung: Schwierigkeit der technischen Analyse

Problem: Schwer zu bestimmen, ob anfälliger Code verwendet wird.

Lösungen:

  • Mit Entwicklungsteam zusammenarbeiten
  • Statische Analyse-Tools verwenden
  • Unsicherheit angemessen dokumentieren
  • Konservativer Ansatz: Im Zweifel als betroffen behandeln

Herausforderung: VEX aktuell halten

Problem: Schwachstellenstatus ändert sich im Laufe der Zeit.

Lösungen:

  • SBOM-Re-Scanning automatisieren
  • Geplante VEX-Überprüfungen
  • Trigger-basierte Updates (neue CVE, neue Version)
  • VEX-Dokumente versionieren

VEX-Checkliste

VEX-IMPLEMENTIERUNGS-CHECKLISTE

EINRICHTUNG:
[ ] VEX-Format wählen (CycloneDX VEX empfohlen)
[ ] Bewertungsprozess definieren
[ ] Verantwortlichkeit zuweisen
[ ] Tooling einrichten

ERSTBEWERTUNG:
[ ] SBOM auf Schwachstellen scannen
[ ] Nach Schweregrad priorisieren
[ ] Jede Schwachstelle bewerten
[ ] Begründungen dokumentieren

FORTLAUFENDER PROZESS:
[ ] Regelmäßiger SBOM-Re-Scan-Zeitplan
[ ] Neue CVE-Überwachung
[ ] Bewertungs-SLA (z.B. Kritisch: 24 Std.)
[ ] VEX-Dokument-Updates

DOKUMENTATION:
[ ] VEX in Technischer Dokumentation enthalten
[ ] Versionshistorie gepflegt
[ ] Begründungen detailliert
[ ] Kundengerichtete Veröffentlichung

INTEGRATION:
[ ] Mit SBOM verknüpft
[ ] Kundenkommunikationsprozess
[ ] ENISA-Meldeworkflow
[ ] Release-Notes aktualisieren

Wichtige Ressourcen

VEX-RESSOURCEN

STANDARDS:
CycloneDX VEX: https://cyclonedx.org/capabilities/vex/
CSAF: https://docs.oasis-open.org/csaf/
OpenVEX: https://openvex.dev

LEITFÄDEN:
CISA VEX Status Justifications
NTIA VEX Minimum Elements

TOOLS:
Grype: https://github.com/anchore/grype
Trivy: https://aquasecurity.github.io/trivy/
CycloneDX CLI: https://github.com/CycloneDX/cyclonedx-cli

Wie CRA Evidence hilft

CRA Evidence bietet umfassende VEX-Unterstützung:

  • Integriertes VEX: VEX zusammen mit SBOM verwalten
  • Bewertungsworkflow: Strukturierte Schwachstellenanalyse
  • Statusverfolgung: Änderungen im Zeitverlauf verfolgen
  • Begründungsvorlagen: Häufige Muster vorinstalliert
  • Integration in Technische Dokumentation: VEX in Compliance-Dokumentation
  • Kundenportal: VEX-Status mit Kunden teilen

Starten Sie Ihre CRA-Compliance bei app.craevidence.com.

Verwandte Artikel


Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich an einen qualifizierten Rechtsberater.

In diesem Artikel behandelte Themen

Diesen Artikel teilen

Verwandte Artikel

Does the CRA apply to your product?

Beantworte 6 einfache Fragen, um herauszufinden, ob dein Produkt unter den Geltungsbereich des EU Cyber Resilience Act fällt. Erhalte dein Ergebnis in weniger als 2 Minuten.

Bereit für CRA-Konformität?

Beginnen Sie mit der Verwaltung Ihrer SBOMs und Konformitätsdokumentation mit CRA Evidence.