SBOM und Dependency-Scanning: Open-Source-Komponenten im Griff, bevor der CRA greift

Edouard Jacques

Managing Director, Cyber Culture

Als im Dezember 2021 die Lücke Log4Shell in der Java-Bibliothek Log4j bekannt wurde, stellten sich viele Entwicklungsleiter dieselbe Frage: In welchen unserer Produkte steckt diese Bibliothek, direkt oder als Abhängigkeit einer Abhängigkeit? Wer eine aktuelle Software-Stückliste hatte, eine SBOM (Software Bill of Materials), konnte das schnell beantworten. Alle anderen suchten tagelang in Repositories und Build-Servern. Dieser Artikel zeigt, was der Cyber Resilience Act und das BSI zur SBOM verlangen, wie Sie Stücklisten im Build erzeugen und wie daraus ein laufendes Schwachstellenmanagement für Ihre Komponenten wird.

Wen das Thema betrifft

Verpflichtend wird die SBOM für Hersteller von Produkten mit digitalen Elementen, also Software und Geräte mit Software, die in der EU in Verkehr gebracht werden. Das schließt viele Maschinenbauer, Gerätehersteller und Softwarehäuser im Mittelstand ein. Ob Ihr Produkt darunter fällt, klärt unser Überblick zum Cyber Resilience Act.

Aber auch wer nur für den Eigenbedarf entwickelt, profitiert von derselben Technik, weil ISO 27001 mit Control A.8.8 ein Management technischer Schwachstellen verlangt und eingebundene Bibliotheken dazugehören. Und wer Software einkauft, kann SBOMs von seinen Lieferanten fordern.

Was der CRA konkret verlangt

Die Verordnung (EU) 2024/2847 ist an mehreren Stellen für Komponenten relevant. In Anhang I Teil II Nummer 1 steht die Pflicht, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten enthält. Veröffentlichen müssen Sie die SBOM nicht. Sie gehört aber zur technischen Dokumentation, und die Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern. Ein bestimmtes Format schreibt der CRA bisher (Stand Oktober 2026) nicht vor, die Kommission kann Format und Inhalte jedoch per Durchführungsrechtsakt festlegen.

Daneben stehen Pflichten, die ohne funktionierendes Dependency-Scanning kaum zu erfüllen sind:

• Produkte dürfen laut Anhang I Teil I nur ohne bekannte ausnutzbare Schwachstellen auf den Markt kommen. Vor jedem Release braucht es also eine Prüfung.
• Hersteller müssen beim Einbau fremder Komponenten, ausdrücklich auch quelloffener, die gebotene Sorgfalt walten lassen (Artikel 13 Absatz 5).
• Wer eine Schwachstelle in einer eingebundenen Komponente findet, meldet sie dem Hersteller oder Maintainer der Komponente und teilt gegebenenfalls die eigene Korrektur (Artikel 13 Absatz 6).
• Schwachstellen müssen über den gesamten Unterstützungszeitraum behandelt werden, der in der Regel mindestens fünf Jahre beträgt.

Zum Zeitplan: Seit dem 11. September 2026 gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen. Eine Frühwarnung muss innerhalb von 24 Stunden über die einheitliche Meldeplattform an das zuständige CSIRT und die ENISA gehen, eine ausführlichere Meldung innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist. Die übrigen Herstellerpflichten gelten ab dem 11. Dezember 2027. Wer 24 Stunden Zeit hat, kann nicht erst anfangen zu suchen, wo die betroffene Komponente überall eingebaut ist.

Was das BSI unter einer guten SBOM versteht

Konkreter als der CRA ist die Technische Richtlinie BSI TR-03183, deren Teil 2 die SBOM beschreibt. Die aktuelle Version 2.1.0 vom August 2025 verlangt eine Datei im JSON- oder XML-Format nach CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Beide Formate sind offen und international normiert: CycloneDX als ECMA-424, SPDX in Version 2.2.1 als ISO/IEC 5962:2021.

Inhaltlich geht die TR über das Minimum des CRA hinaus. Abhängigkeiten müssen für alle ausgelieferten Komponenten rekursiv aufgelöst werden, nicht nur auf der obersten Ebene. Pro Komponente gehören unter anderem Ersteller, Name, Version, Dateiname, Abhängigkeiten, Lizenzen und ein Hashwert der auslieferbaren Datei hinein. Die SBOM soll die Informationen enthalten, die beim Build tatsächlich vorliegen.

Ein Punkt überrascht viele: Schwachstelleninformationen gehören ausdrücklich nicht in die SBOM. Die Stückliste einer Version ist statisch, die Bewertung von Schwachstellen ändert sich laufend. Dafür sieht das BSI Sicherheitshinweise im Format CSAF oder VEX-Dokumente vor (Vulnerability Exploitability eXchange), die angeben, ob ein Produkt von einer bestimmten Lücke betroffen ist.

Wichtig für die Einordnung: Das BSI bezeichnet die TR als Hilfestellung ohne verbindlichen Charakter. Sie begründet keine Konformitätsvermutung und soll durch harmonisierte europäische Normen ersetzt werden, sobald diese vorliegen. Als derzeit präziseste deutsche Vorgabe ist sie trotzdem der sinnvollste Maßstab.

SBOMs im Build erzeugen

Eine SBOM entsteht in der Build-Pipeline, bei jedem Release automatisch und versioniert neben dem ausgelieferten Artefakt. Für gängige Ökosysteme gibt es frei verfügbare Werkzeuge, etwa die CycloneDX-Plugins für Maven, Gradle oder npm oder Werkzeuge wie Syft und Trivy, die auch Container-Images auswerten.

Die Lücken liegen selten im Werkzeug, sondern in der Codebasis. Typische Stolpersteine:

• Fehlende Lockfiles, sodass die tatsächlich verwendete Version einer Bibliothek erst beim Build feststeht.
• In das eigene Repository kopierter Fremdcode, den kein Paketmanager kennt.
• C- und C++-Projekte ohne Paketverwaltung, bei denen Bibliotheken von Hand eingebunden wurden.
• Firmware mit Binärkomponenten von Chip- oder Modulherstellern, für die der Lieferant selbst keine Stückliste liefert.

Bewahren Sie die SBOM jeder ausgelieferten Version so lange auf, wie die Version unterstützt wird. Nur dann können Sie bei einer neuen Lücke für jede Kundeninstallation beantworten, ob sie betroffen ist.

Vom Inventar zum Schwachstellenmanagement

Eine SBOM allein schützt nichts. Den Nutzen bringt der laufende Abgleich. Plattformen wie OWASP Dependency-Track lesen SBOMs ein und gleichen die Komponenten fortlaufend gegen Schwachstellendatenbanken wie die NVD, die GitHub Advisory Database oder OSV ab. Wird morgen eine neue Lücke in einer Bibliothek veröffentlicht, sehen Sie, welche Produktversionen sie enthalten, ohne neu zu bauen.

Nicht jede verwundbare Komponente macht Ihr Produkt angreifbar, etwa wenn die betroffene Funktion gar nicht aufgerufen wird. Diese Bewertung dokumentieren Sie im VEX-Format mit einem Status wie betroffen, nicht betroffen, behoben oder in Prüfung. Das spart Ihnen und Ihren Kunden die Diskussion jedes einzelnen Scanner-Funds.

Für das Release-Gate in der Pipeline gilt dieselbe Lehre wie im klassischen Schwachstellenmanagement. Ein Gate, das bei jedem CVSS-Wert über 7 blockiert, wird schnell umgangen. Blockieren Sie bei nachweislich ausgenutzten oder sehr wahrscheinlich ausgenutzten Lücken in erreichbarem Code und bearbeiten Sie den Rest mit Frist. Wie Sie diese Signale gewichten, beschreibt CVSS reicht nicht.

Die eigentliche Hürde ist die Zuständigkeit

Technisch lässt sich das Thema meist in wenigen Wochen lösen. Schwieriger ist die Frage, wer handelt, wenn eine Bibliothek in zwölf Anwendungen steckt. Bewährt hat sich eine klare Regel: Für jede Anwendung ist das Produktteam verantwortlich, auch für die eingebundenen Komponenten. Eine zentrale Stelle, meist Security oder ein Plattformteam, überwacht gemeinsam genutzte Komponenten, legt Fristen fest und eskaliert.

Für den Einkauf gilt die Umkehrung. Nehmen Sie in Verträge auf, dass Lieferanten mit jedem Release eine SBOM nach TR-03183-2 liefern und Sicherheitshinweise maschinenlesbar bereitstellen. Wer heute Software beschafft, die nach Dezember 2027 noch im Einsatz ist, sollte diese Anforderung jetzt stellen.

Wie SBOM, Dependency-Scanning, Disclosure-Policy und Meldeweg zu einem CRA-tauglichen Prozess zusammenwachsen, beschreibt CRA Readiness: Secure-by-Design und Vulnerability Handling. Den Rahmen für Sicherheitsprüfungen in der Entwicklung insgesamt finden Sie in Secure SDLC: Controls, Gates, Metrics.

Der erste Schritt in Ihrem Unternehmen

Nehmen Sie ein Produkt, am besten das mit dem größten Kundenstamm. Erzeugen Sie aus dem aktuellen Release eine SBOM, laden Sie sie in ein Werkzeug zum Abgleich und prüfen Sie zwei Dinge: Wie viele bekannte Schwachstellen tauchen auf, und welche Pflichtfelder der TR-03183-2 fehlen? Für eine einzelne Pipeline ist das eine Sache von wenigen Tagen. Danach wissen Sie, wie groß der Aufwand für alle Produkte ist und wo die Codebasis nacharbeiten muss.