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.
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"
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:
- Keine bekannten ausnutzbaren Schwachstellen (bei Marktbereitstellung)
- Schwachstellen behandeln während der gesamten Supportperiode
- Sicherheitsupdates bereitstellen zur Behebung von Schwachstellen
- Aktiv ausgenutzte Schwachstellen melden an ENISA (24 Stunden)
- 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
- SBOM für CRA-Compliance: Vollständiger Leitfaden zur Software Bill of Materials -- VEX ergänzt SBOM -- erfahren Sie, wie Sie die Grundlage zuerst aufbauen.
- CRA-Schwachstellenmeldung: ENISA-Meldeverpflichtungen -- Verstehen Sie die 24h/72h-Meldepflichten für Schwachstellen, die Sie als "Betroffen" einstufen.
- CRA SBOM-Generierung: Tools und Automatisierungsleitfaden -- Automatisieren Sie SBOM- und VEX-Generierung in Ihrer CI/CD-Pipeline.
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
Verwandte Artikel
Sind smarte Kameras wichtige Produkte im Sinne des EU...
Smarte Sicherheitskameras werden im CRA-Anhang III als wichtige Produkte...
9 Min.EU Cybersecurity Act 2: Lieferketten-Verbote,...
Am 20. Januar 2026 schlug die EU vor, den Cybersecurity Act vollständig zu...
9 Min.CRA-Produktklassifizierung: Ist Ihr Produkt Standard,...
Ein praktischer Leitfaden zur Bestimmung Ihrer CRA-Produktkategorie. Enthält...
8 Min.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.