SBOM für den Cyber Resilience Act erstellen: Software-Lieferketten jetzt transparent machen

Im Sicherheitsvorfall zählt nicht, ob dein Team irgendwann einmal eine Bibliothek eingesetzt hat, sondern ob du innerhalb kurzer Zeit sagen kannst: „Ist sie in unserem Produkt enthalten, in welcher Version, wo wird sie ausgeliefert und welche Kunden sind betroffen?“ Seit September 2026 gelten erste Meldepflichten des Cyber Resilience Act. Für Hersteller von Produkten mit digitalen Elementen wird damit die Transparenz über eingesetzte Softwarekomponenten zur operativen Pflichtaufgabe.

Eine Software Bill of Materials, kurz SBOM, ist dafür ein zentraler Baustein. Sie ist kein Sicherheitsnachweis und ersetzt weder Code Reviews noch Penetrationstests. Sie schafft aber eine belastbare Inventur der Software-Lieferkette. Das Team erkennt damit Komponenten, Versionen, Abhängigkeiten, Herkunft und gegebenenfalls bekannte Schwachstellen schneller. Genau diese Informationen braucht ihr, wenn eine kritische Sicherheitslücke in einer Open-Source-Bibliothek bekannt wird oder ein Vorfall untersucht werden muss.

Infografik zu SBOM für den Cyber Resilience Act erstellen: Software-Lieferketten jetzt transparent machen (KI-generiert).

Was der Cyber Resilience Act an der Praxis verändert

Der Cyber Resilience Act richtet sich an Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Darunter können Softwareprodukte, vernetzte Geräte, Anwendungen, Bibliotheken und Firmware fallen. Ob ein konkretes Produkt in den Anwendungsbereich fällt und welche Rolle dein Unternehmen einnimmt, muss immer einzeln bewertet werden.

Seit dem 11. September 2026 gelten die Regelungen zur Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle. Die weitergehenden Anforderungen des Cyber Resilience Act werden ab Dezember 2027 relevant. Für Softwareteams bedeutet das: Prozesse, Verantwortlichkeiten und technische Nachweise müssen rechtzeitig stehen, nicht erst dann, wenn ein Vorfall eingetreten ist.

Eine SBOM unterstützt mehrere Anforderungen in der Praxis:

• Sie dokumentiert Komponenten und Abhängigkeiten eines Produkts nachvollziehbar.
• Sie verkürzt die Analysezeit bei neuen Sicherheitsmeldungen.
• Sie liefert Informationen für technische Dokumentation und Risikobewertungen.
• Sie erleichtert die Abstimmung mit Entwicklung, Security, Produktmanagement und Einkauf.
• Sie schafft eine Grundlage für Kundeninformationen und geregelte Sicherheitsupdates.

Wichtig ist die Abgrenzung: Eine SBOM ist nicht automatisch zur Veröffentlichung bestimmt. Sie gehört zunächst in eure technische Dokumentation und Sicherheitsprozesse. Ob, in welcher Form und an wen sie weitergegeben wird, entscheidet ihr nach Produkt, Vertrag, Schutzbedarf und rechtlichen Anforderungen.

Eine SBOM ist mehr als eine Liste von Open-Source-Paketen

Viele Teams starten mit einer Aufstellung von Paketen aus npm, Maven, PyPI oder NuGet. Das ist sinnvoll, reicht aber selten aus. In einem auslieferbaren Produkt stecken oft weitere Bestandteile:

• Direkte und transitive Abhängigkeiten
• Proprietäre Drittanbieterkomponenten
• Betriebssystempakete und Container-Base-Images
• Firmware und Gerätetreiber
• Build-Werkzeuge, sofern sie in das ausgelieferte Artefakt einfließen
• Kopierte Codebestandteile und eingebettete Bibliotheken
• Komponenten aus zugekauften Modulen oder SDKs
• Eigene Module und deren Versionsstand

Entscheidend ist die Frage: Was ist tatsächlich Bestandteil des ausgelieferten Produkts oder einer ausgelieferten Produktversion? Die Antwort lässt sich nicht immer allein aus dem Quellcode ableiten. Besonders Container, Installer, Firmware-Images und manuell integrierte Dateien erfordern eine Analyse des finalen Build-Artefakts.

Eine brauchbare SBOM enthält mindestens eindeutige Angaben zu Komponente, Lieferant oder Autor, Version, Herkunft sowie Beziehungen zwischen Komponenten. Hilfreich sind zudem Prüfsummen, Lizenzinformationen, Paket-URLs und ein Zeitstempel der Erstellung. Je besser Komponenten eindeutig identifiziert sind, desto zuverlässiger funktioniert später der Abgleich mit Schwachstellendaten.

CycloneDX oder SPDX: Welches Format passt?

Für maschinenlesbare SBOMs haben sich insbesondere CycloneDX und SPDX etabliert. Beide Formate können Komponenten und Abhängigkeiten abbilden, setzen aber unterschiedliche Schwerpunkte.

Format	Besonders geeignet für	Praktischer Schwerpunkt
CycloneDX	Anwendungssicherheit, DevSecOps, Schwachstellenmanagement	Komponenten, Abhängigkeiten, Sicherheitskontext
SPDX	Lizenz- und Compliance-Prozesse, Open-Source-Governance	Herkunft, Lizenzen, Software-Stücklisten
Beide Formate	Unternehmen mit mehreren Fachbereichen	Austauschbarkeit und unterschiedliche Empfänger

CycloneDX ist in vielen Security-Tools und CI/CD-Integrationen gut verankert. Es eignet sich daher häufig für Teams, die SBOMs direkt aus Builds erzeugen und gegen Schwachstelleninformationen prüfen wollen. SPDX ist besonders stark, wenn Lizenzmanagement, Herkunftsnachweise und Open-Source-Compliance bereits etablierte Prozesse sind.

Die Entscheidung muss nicht endgültig sein. Manche Unternehmen erzeugen aus demselben Build beide Formate: CycloneDX für Security-Workflows und SPDX für Compliance- oder Lieferantenprozesse. Wichtiger als das Format ist, dass die Daten konsistent, automatisiert erzeugt und eindeutig einer Produktversion zugeordnet werden.

So erstellst du eine SBOM Schritt für Schritt

1. Produkt und Lieferumfang sauber festlegen

Beginne nicht mit einem Scanner, sondern mit dem Produktzuschnitt. Definiert gemeinsam:

• Welche Produktlinien und Versionen gehören zum Geltungsbereich?
• Welche Artefakte werden ausgeliefert, etwa Installer, Container, Pakete oder Firmware?
• Welche Repositories und Build-Pipelines erzeugen diese Artefakte?
• Welche externen Komponenten oder Lieferantenmodule sind enthalten?
• Wer verantwortet die fachliche Freigabe der SBOM?

Ohne diese Abgrenzung entstehen entweder Lücken oder unbrauchbar große Listen. Eine SBOM für ein Git-Repository ist nicht automatisch eine SBOM für ein auslieferbares Produkt.

2. SBOM im Build erzeugen, nicht manuell pflegen

Manuelle Tabellen veralten schnell. Verankert die Erstellung deshalb in der Build-Pipeline. Die SBOM sollte aus dem definierten Release-Build entstehen und als Artefakt gemeinsam mit Paket, Container-Image oder Installer abgelegt werden.

Achtet dabei auf drei Punkte:

• Der Build muss reproduzierbar einem Release zuordenbar sein.
• Die SBOM muss die genaue Produktversion und den Buildzeitpunkt enthalten.
• Änderungen an Abhängigkeiten müssen automatisch eine neue SBOM erzeugen.

Eine gute Regel lautet: Kein Release ohne zugehörige SBOM. Damit wird die Stückliste Teil eurer Lieferkette statt ein Dokument, das nachträglich unter Zeitdruck erstellt wird.

3. Ergebnisse prüfen und Lücken schließen

Automatisch erzeugte SBOMs sind ein Anfang, aber keine Garantie für Vollständigkeit. Prüft Stichproben anhand des finalen Artefakts. Findet das Tool eingebettete JAR-Dateien, statisch gelinkte Bibliotheken, Systempakete und Bestandteile aus mehrstufigen Container-Builds?

Besondere Aufmerksamkeit verdienen Komponenten, die außerhalb üblicher Paketmanager eingebunden werden. Dazu gehören heruntergeladene Archive, kopierte Binärdateien, alte Installationsroutinen und Software aus Lieferantenportalen. Für solche Fälle braucht ihr einen dokumentierten Ergänzungsprozess.

Wenn ihr KI-gestützte Entwicklungswerkzeuge nutzt, sollten auch übernommene Codefragmente überprüfbar bleiben. Unser Beitrag „Vibe Coding im Unternehmen sicher einsetzen: Richtlinien, Tests und Code Reviews“ zeigt, warum technische Kontrollen und klare Verantwortlichkeiten dabei wichtiger sind als bloßes Vertrauen in das Werkzeug.

4. SBOM sicher ablegen und versionieren

Eine SBOM enthält wertvolle technische Informationen über euer Produkt. Legt deshalb fest, wo sie gespeichert wird, wer sie lesen oder verändern darf und wie lange sie aufbewahrt wird. In der Praxis bewährt sich eine zentrale Ablage, die mit Produkt, Version, Release-Datum und zugehörigem Artefakt verknüpft ist.

Speichert nicht nur die aktuelle SBOM. Bei einer später bekannt gewordenen Schwachstelle müsst ihr auch ältere, noch unterstützte Produktversionen bewerten können. Dafür braucht ihr historische Stücklisten und eine eindeutige Zuordnung zum jeweiligen Release.

SBOM in das Schwachstellenmanagement einbinden

Der größte Nutzen entsteht, wenn eine SBOM nicht im Archiv verschwindet. Verknüpft sie mit eurem Prozess für Schwachstellenmanagement. Sobald ein Security Advisory zu einer Komponente erscheint, muss klar sein:

• Welche Produkte und Versionen enthalten die betroffene Komponente?
• Ist die gefährdete Funktion im Produkt tatsächlich erreichbar?
• Welche Kunden oder Installationen könnten betroffen sein?
• Welche Abhilfe ist möglich, etwa Update, Konfigurationsänderung oder Abschaltung?
• Wer entscheidet über Bewertung, Kommunikation und Release eines Fixes?

Eine Versionsgleichheit allein bedeutet noch keine bestätigte Ausnutzbarkeit. Dennoch liefert die SBOM den entscheidenden ersten Filter. Sie reduziert die Suche von „Wo könnte diese Bibliothek überall stecken?“ auf eine konkrete Liste betroffener Releases.

Für den organisatorischen Rahmen lohnt sich ein Blick auf unsere Praxis-Checkliste zur NIS2-Umsetzung für IT-Administratoren. Auch wenn Cyber Resilience Act und NIS2 unterschiedliche Regelwerke sind, überschneiden sich wichtige Arbeitsweisen: Zuständigkeiten, Erkennung, Bewertung, Eskalation und nachvollziehbare Dokumentation.

Einkauf und Lieferanten müssen mitarbeiten

Software-Lieferketten enden nicht am eigenen Repository. Wenn ihr Komponenten, SDKs, Appliances oder vollständige Softwaremodule einkauft, braucht ihr Informationen von euren Lieferanten. Die Einkaufsabteilung sollte daher früh eingebunden werden.

Klärt mit Lieferanten mindestens:

• Ob sie eine maschinenlesbare SBOM bereitstellen können
• Welches Format und welche Detailtiefe verwendet werden
• Wie Sicherheitslücken gemeldet und behoben werden
• Welche unterstützten Versionen und Update-Zeiträume gelten
• Wer im Incident schnell erreichbar ist
• Ob sich die SBOM auf das konkrete Lieferartefakt bezieht

Eine Lieferanten-SBOM ersetzt eure eigene Produkt-SBOM nicht. Ihr müsst weiterhin nachvollziehen können, wie das eingekaufte Modul in eurem Produkt verwendet wird. Sie erleichtert jedoch die Bewertung und verhindert, dass ihr bei einem Vorfall vollständig auf manuelle Rückfragen angewiesen seid.

Incident Response vor dem Ernstfall üben

Eine SBOM zeigt ihren Wert erst unter Zeitdruck. Führt deshalb regelmäßig eine Übung durch: Eine häufig verwendete Bibliothek wird als kritisch gemeldet. Das Team erhält die Aufgabe, innerhalb eines festgelegten Zeitfensters betroffene Produkte, Versionen, Verantwortliche und nächste Schritte zu ermitteln.

Dokumentiert dabei, wo Informationen fehlen. Typische Probleme sind unklare Produktnamen, fehlende transitive Abhängigkeiten, nicht versionierte Lieferantenkomponenten oder unvollständige Freigabeprotokolle. Diese Lücken sind wertvolle Ergebnisse, denn sie zeigen, was ihr vor einem echten Vorfall verbessern müsst.

Auch Security Monitoring bleibt unverzichtbar. Wie sich Erkennung und Bearbeitung im operativen Alltag strukturieren lassen, erläutern wir in „Microsoft Sentinel und Defender XDR lernen: SIEM für den SOC-Alltag“.

Die kompakte Start-Checkliste

• Produktumfang, Releases und Verantwortliche festlegen
• Build-Pipelines und ausgelieferte Artefakte inventarisieren
• CycloneDX, SPDX oder beide Formate auswählen
• SBOM automatisiert bei jedem Release erzeugen
• Finales Artefakt gegen die SBOM plausibilisieren
• SBOMs versionssicher und zugriffsgeschützt ablegen
• Schwachstellenbewertung mit den SBOM-Daten verknüpfen
• Lieferantenanforderungen und Vertragsprozesse ergänzen
• Incident-Übung mit einer realistischen Sicherheitslücke durchführen
• Prozesse regelmäßig nach Releases, Toolwechseln und Vorfällen verbessern

Eine SBOM wird nicht durch ein einzelnes Tool wirksam, sondern durch das Zusammenspiel von Entwicklung, Security, Einkauf und Betrieb. Wenn ihr diesen Prozess jetzt aufbaut, könnt ihr Sicherheitsmeldungen schneller bewerten, gezielter reagieren und eure Software-Lieferkette nachvollziehbar dokumentieren. Passende Seminare zu Security, Cloud, Entwicklung und IT-Service-Management findest du bei uns auf cmt.de.