Zum Inhalt springen

SBOM-Pflicht durch CRA erzeugt CVE-Flut – VEX als Filtermechanismus gegen Alarm-Müdigkeit

Auf den Punkt: Die CRA-Pflicht zur SBOM-Erstellung produziert eine kaum bewältigbare CVE-Meldungsflut, die sich laut Praxisstudien durch VEX-gestützte Reachability-Analysen um bis zu 90 Prozent reduzieren lässt.

Der EU Cyber Resilience Act verpflichtet Hersteller digitaler Produkte zur Erstellung einer Software-Stückliste (SBOM), was in der Praxis zu einer kaum noch händisch beherrschbaren Menge automatisierter Schwachstellenmeldungen führt. Der Vulnerability Exploitability eXchange (VEX) soll helfen, aus dieser Flut die tatsächlich relevanten Risiken herauszufiltern.

Der Cyber Resilience Act (CRA) schreibt Herstellern digitaler Produkte vor, eine Software Bill of Materials (SBOM) als Teil der technischen Dokumentation vorzuhalten. Verlangt werden dabei mindestens die Top-Level-Abhängigkeiten eines Produkts; eine vollständige Auflistung sämtlicher transitiven Abhängigkeiten in voller Tiefe ist nicht zwingend vorgeschrieben, wird von vielen Unternehmen aber dennoch angestrebt. Eine ähnliche, deutlich engere Regelung existiert bereits in den USA: Die Executive Order 14028 verlangt eine SBOM von Softwareanbietern, die an US-Bundesbehörden verkaufen – eine reine Vergaberegel im Beschaffungskontext, keine marktweite Pflicht wie der CRA. In beiden Fällen wird die SBOM in maschinenlesbaren Formaten wie CycloneDX oder SPDX dokumentiert und listet Drittanbieter-Komponenten sowie Open-Source-Bibliotheken auf.

Sobald SBOMs flächendeckend erstellt werden, kippt das ursprüngliche Transparenzproblem in ein Überlastungsproblem: Der automatisierte Abgleich mit Schwachstellendatenbanken wie der National Vulnerability Database oder der GitHub Advisory Database erzeugt bei jedem Build hunderte bis tausende Warnmeldungen, sobald ein Scanner ein Paket mit zugehörigem CVE-Eintrag findet – unabhängig davon, ob die Schwachstelle im konkreten Produkt überhaupt relevant ist. Klassische Scanner prüfen dabei lediglich, ob eine fehlerhafte Komponente auf der Festplatte liegt, nicht aber, ob der verwundbare Code im laufenden Betrieb geladen, ausgeführt oder über das Netzwerk erreichbar ist.

Für CISOs bedeutet dies ein konkretes Priorisierungsproblem: Jede einzelne CVE-Meldung manuell zu prüfen, bindet Personalkapazitäten, über die die meisten Sicherheitsteams nicht verfügen. Fallstudien zu reachability-basierten Analysen, etwa bei Projekten wie Prometheus, zeigen Reduktionsraten von 90 Prozent und mehr, wenn reine Versions-Treffer durch eine echte Erreichbarkeitsanalyse ersetzt werden. Ein Großteil der in einer SBOM gemeldeten Schwachstellen lässt sich demnach im konkreten Einsatzkontext gar nicht ausnutzen.

Als Gegenmaßnahme zur reinen CVE-Flut dient der Vulnerability Exploitability eXchange (VEX), ein Format, mit dem Hersteller den Ausnutzungsstatus einer Schwachstelle für ein konkretes Produkt dokumentieren – etwa ob eine gemeldete Lücke tatsächlich betroffen, nicht betroffen oder bereits durch Kompensationsmaßnahmen abgesichert ist. Für Sicherheitsverantwortliche liegt der praktische Nutzen darin, Scan-Ergebnisse mit VEX-Angaben anzureichern und so die Zahl der tatsächlich zu bearbeitenden Meldungen deutlich zu reduzieren, statt jede CVE isoliert und ohne Kontextbezug abzuarbeiten.


Quelle: www.it-daily.net · Erschienen 3. August 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.8.3.

Share on:
Schlagwörter: