SBOM-Overload: Die softwareseitige Datenflut

Die gesetzliche Pflicht zur Software-Stückliste führt zu einer Flut an CVE-Meldungen. Wie Unternehmen mittels VEX die echten Risiken herausfiltern.

Die Sicherheit von Software-Lieferketten ist längst keine reine Best-Practice-Frage mehr, sondern in der EU gesetzlich verankert. Der Cyber Resilience Act (CRA) verpflichtet Hersteller digitaler Produkte, eine Software-Stückliste (im Fachjargon Software Bill of Materials oder SBOM) zu erstellen und als Teil ihrer technischen Dokumentation bereitzuhalten. Konkret verlangt der CRA dabei mindestens die Top-Level-Abhängigkeiten eines Produkts; eine lückenlose Auflistung sämtlicher transitiven Abhängigkeiten in voller Tiefe schreibt er nicht zwingend vor, auch wenn viele Unternehmen in der Praxis genau das anstreben, um wirklich vorbereitet zu sein.

Eine ähnliche, aber deutlich engere Idee gab es vorher schon in den USA: Die Executive Order 14028 verlangt von Softwareanbietern, die an US-Bundesbehörden verkaufen, im Rahmen der Beschaffung ebenfalls eine SBOM. Wichtig ist der Unterschied: Das ist eine US-Vergaberegel für den Bundesbeschaffungskontext, keine globale, marktweite Pflicht wie der CRA. Wer nicht an US-Behörden verkauft, ist davon schlicht nicht betroffen.

In beiden Fällen wird die SBOM in maschinenlesbaren Formaten wie CycloneDX oder SPDX dokumentiert und listet die im Produkt verwendeten Drittanbieter-Komponenten und Open-Source-Bibliotheken auf.

Der Sinn der Übung und das Problem, das dabei entsteht

Die Idee hinter SBOMs ist simpel: Moderne Softwarearchitekturen sind oft eine Blackbox, und das soll sich ändern. Wenn morgen eine neue kritische Schwachstelle auftaucht, will die IT-Leitung in Minuten wissen, ob die betroffene Bibliothek irgendwo im eigenen Stack steckt, statt tagelang suchen zu müssen.

In der Praxis zeigt sich aber schnell ein Nebeneffekt: Sobald SBOMs flächendeckend erstellt werden, kippt das Problem von „wir wissen nichts“ zu „wir werden erschlagen“. Unternehmen wissen jetzt zwar sehr genau, welche Code-Bausteine aktiv im Einsatz sind, werden aber gleichzeitig mit einer Flut automatisierter Schwachstellenmeldungen überschüttet, die sich kaum noch händisch bewältigen lässt.

Die algorithmische Flut an Common Vulnerabilities and Exposures

Nach der Erstellung einer SBOM folgt normalerweise der automatisierte Abgleich mit Schwachstellendatenbanken wie der National Vulnerability Database oder der GitHub Advisory Database. Findet ein Scanner ein Paket, zu dem ein CVE-Eintrag existiert, schlägt er Alarm, unabhängig davon, ob diese Schwachstelle im konkreten Produkt überhaupt eine Rolle spielt. Bei komplexen Enterprise-Anwendungen mit hunderten Microservices und tausenden Unterbibliotheken kommen so bei jedem Build schnell hunderte oder tausende Warnmeldungen zusammen.

Das Ergebnis: Alarm-Müdigkeit. Jede einzelne Meldung manuell zu prüfen, würde enorme personelle Kapazitäten binden, über die kaum ein Team wirklich verfügt. Das eigentliche Problem liegt tiefer: Klassische Scanner prüfen nur, ob eine fehlerhafte Komponente theoretisch auf der Festplatte liegt. Ob der verwundbare Code im laufenden Betrieb überhaupt geladen, ausgeführt oder über das Netzwerk erreichbar ist, interessiert sie nicht. Und genau diese Lücke ist entscheidend, denn das reine Vorhandensein einer Schwachstelle sagt über das tatsächliche Risiko oft nur wenig aus.

Warum die meisten CVEs in der Praxis ins Leere laufen

Verschiedene Studien und Fallbeispiele aus der Praxis, etwa Vergleiche von reachability-basierten Analysen gegen klassisches Versions-Scanning, zeigen ein ziemlich konsistentes Muster: Ein sehr großer Anteil der in einer SBOM gemeldeten Schwachstellen lässt sich im konkreten Einsatzkontext gar nicht ausnutzen. Manche Fallstudien, etwa bei komplexeren Projekten wie Prometheus, kommen sogar auf Reduktionsraten von 90 Prozent und mehr, wenn man reine Versions-Treffer durch echte Reachability-Analyse ersetzt. Das ist also keine offizielle, einzelne Kennzahl einer bestimmten Behörde, sondern ein wiederkehrender Befund aus mehreren unabhängigen Untersuchungen und Herstellerfallstudien.

Warum bleibt eine dokumentierte Schwachstelle in der Praxis oft wirkungslos? Ein paar typische Gründe:

• Ungenutzter Code: Eine Bibliothek bringt oft dutzende Funktionen mit, von denen die eigene Anwendung nur eine einzige, unkritische nutzt. Der Rest bleibt schlicht inaktiv.
• Wegoptimierter Code: Bei kompilierten Sprachen entfernen moderne Compiler ungenutzte Code-Pfade oft schon beim Build. In der SBOM taucht die Bibliothek dann zwar auf, der verwundbare Codeblock existiert im fertigen Binary aber gar nicht mehr. Bei interpretierten oder dynamisch geladenen Sprachen wie Java mit Reflection, JavaScript oder Python greift dieses Argument allerdings nicht in gleicher Weise, denn dort kann Code auch „ungenutzt“ physisch vorhanden und im Zweifel doch erreichbar bleiben.
• Kompensierende Konfiguration: Viele Schwachstellen brauchen eine ganz bestimmte Einstellung oder ein aktiviertes Protokoll, um überhaupt ausnutzbar zu sein. Ist das im Unternehmen standardmäßig deaktiviert, geht ein Angriffsversuch schlicht ins Leere.
• Netzwerkisolation: Steckt die betroffene Komponente tief im internen Netz ohne Verbindung nach außen, kommt ein externer Angreifer gar nicht erst an sie heran.

VEX: das fehlende Puzzleteil

Um die Lücke zwischen „theoretisch vorhanden“ und „tatsächlich ausnutzbar“ maschinenlesbar zu schließen, wurde der Standard Vulnerability Exploitability Exchange (VEX) entwickelt. VEX ist quasi das Gegenstück zur SBOM: Während die SBOM sagt, was im Produkt drinsteckt, sagt das VEX-Dokument, wie es um die tatsächliche Ausnutzbarkeit einer bestimmten Schwachstelle steht, aus Sicht des Herstellers oder des eigenen Sicherheitsteams.

Ein VEX-Dokument ordnet jeder betroffenen CVE einen von vier Statuswerten zu:

• not_affected: die Lücke ist in diesem Produkt aus technischen Gründen nicht ausnutzbar. Kann für die Triage ignoriert werden.
• affected: die Schwachstelle ist real und stellt ein verifiziertes Risiko dar. Handlungsbedarf.
• fixed: wurde bereits durch Patch oder Workaround behoben.
• under_investigation: wird gerade noch analysiert, finaler Status steht aus.

Wählt man not_affected, verlangt der Standard eine nachvollziehbare technische Begründung. Zu den gängigen Kategorien gehören etwa vulnerable_code_not_present (der fehlerhafte Code ist gar nicht enthalten), vulnerable_code_not_in_execute_path (der Codepfad wird nie ausgeführt) oder inline_mitigations_already_exist (es gibt bereits wirksame Schutzmechanismen im System).

SBOM vs. VEX: wer macht was

Dokument	Kerninhalt	Datenbasis	Nutzen fürs Sicherheitsteam
SBOM	Vollständiges Inventar aller integrierten Komponenten und Lizenzen	Statische Analyse von Paketmanagern und Quellcode	Transparenz über die Lieferkette, Basis für Compliance
VEX	Kontextbezogene Aussage zur realen Ausnutzbarkeit bekannter Schwachstellen	Analyse von Codepfaden und Systemkonfiguration	Filtert Fehlalarme heraus, entlastet Entwicklungsteams

Wie man den SBOM-Overload in den Griff bekommt

Rein manuelles Durchsehen der täglichen CVE-Flut ist wirtschaftlich einfach nicht machbar. Wer das ernst nimmt, kommt um eine automatisierte Triage-Pipeline nicht herum. In der Praxis bewährt sich ein mehrstufiges Vorgehen:

1. EPSS statt reinem CVSS: Statt Prioritäten nur nach dem klassischen CVSS-Score zu vergeben, lohnt sich ein Blick auf das Exploit Prediction Scoring System (EPSS) von FIRST. EPSS berechnet täglich, wie wahrscheinlich es ist, dass eine bestimmte Schwachstelle innerhalb der nächsten 30 Tage tatsächlich aktiv ausgenutzt wird. Meldungen mit niedrigem EPSS-Wert rutschen automatisch nach unten in der Priorität.
2. Hersteller-VEX automatisch einbinden: Scanner lassen sich so konfigurieren, dass sie vor Erstellung eines internen Tickets automatisch nach verfügbaren OpenVEX- oder CSAF-Dokumenten des Herstellers suchen. Steht dort not_affected, kann das Ticket vollautomatisch geschlossen werden.
3. Reachability-Analyse einsetzen: Moderne statische und dynamische Codeanalysen können den Kontrollfluss der Software nachvollziehen und prüfen, ob überhaupt ein Pfad vom externen Endpunkt bis zur fehlerhaften Funktion existiert. Gibt es keinen, kann die Pipeline automatisch ein internes VEX-Statement erzeugen und das Team entlasten.
4. Laufzeit-Monitoring nutzen: Mit Technologien wie eBPF lässt sich im laufenden Betrieb auf Kernel-Ebene beobachten, welche Bibliotheken tatsächlich geladen und ausgeführt werden. Komponenten, die über Monate inaktiv bleiben, können im Schwachstellenmanagement separat und mit geringerer Priorität behandelt werden.

Wer diese Bausteine kombiniert, kann Sicherheitsbudget und Entwicklerzeit auf den kleinen, aber tatsächlich kritischen Teil der Meldungen konzentrieren, der wirklich ein reales Risiko darstellt, statt bei jedem Build erneut in einer Flut von Fehlalarmen zu versinken. Genau dieses Zusammenspiel aus maschinenlesbaren Stücklisten und kontinuierlichen Ausnutzbarkeitsnachweisen macht es überhaupt realistisch, die Anforderungen des Cyber Resilience Act zu erfüllen, ohne dabei die eigene Entwicklungsgeschwindigkeit lahmzulegen.