Der Cyber Resilience Act (CRA) fordert von Herstellern eine Software-Stückliste – die Software Bill of Materials (SBOM). Die SBOM ist jedoch nicht einfach ein Dokument, sondern das Ergebnis eines Prozesses, der mit jedem Release neu angestoßen wird. Wir erklären, was der CRA zur SBOM verlangt, wie Sie diesen Prozess steuern und Stolpersteine vermeiden.
In aller Kürze
- Die Software Bill of Materials (SBOM) ist eine maschinenlesbare Stückliste eigener Software und eingesetzter Softwarebibliotheken.
- Ziel der SBOM ist es, Schwachstellen in eingesetzten Komponenten schnell identifizieren und beheben zu können.
- Erstellung, Versionierung und Ablage der SBOM sollten in bestehende CI/CD-Prozesse integriert werden, damit sie als tragbarer Nachweis im Sinne des CRA dienen.
- Verschiedene Produktlandschaften und Compliance-Schwerpunkte erfordern unterschiedliche Ansätze und Tools bei der Erstellung der SBOM.
Was ist eine SBOM und warum verlangt der CRA sie?
Eine SBOM ist das Inventar Ihrer Software. Der CRA definiert sie als „formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten“ eines Produkts. Das Prinzip entspricht der Stückliste aus der industriellen Fertigung, die jedes Bauteil mit Lieferanten und Version für ein konkreten Produkttyp verzeichnet. Die SBOM soll die Schwachstellenanalyse erleichtern und Herstellern wie Nutzern helfen, neu bekanntwerdende Risiken zu erkennen und einzuschätzen.
Spätestens seit der Sicherheitslücke Log4Shell ist klar: Wer nicht weiß, welche Komponenten in seiner Software stecken, kann im Ernstfall nicht schnell reagieren. Nur wenn Sie wissen, welche Software-Komponenten in welcher Version in einer Software verwendet wurden, können sie auch sagen, ob sie von einer Sicherheitslücke betroffen sind. Der CRA macht die SBOM deshalb für Hersteller zur Pflicht.
Was schreibt der CRA zur Software-Stückliste konkret vor?
Nach Anhang I Teil II Nummer 1 des CRA müssen Hersteller die Komponenten ihrer Produkte ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste „in einem gängigen maschinenlesbaren Format“, aus der „zumindest die obersten Abhängigkeiten“ hervorgehen. Die SBOM gehört also zur technischen Dokumentation und die Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern. Diese Dokumentation bewahren Sie mindestens zehn Jahre ab dem Inverkehrbringen auf oder für die Dauer des Unterstützungszeitraums, falls dieser länger ist. Veröffentlichen müssen Sie die SBOM nicht.
Achtung: Die meisten Pflichten des CRA gelten für ab dem 11. Dezember 2027 in Verkehr gebrachte Produkte, so auch die zur SBOM.
Die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten jedoch bereits seit dem 11. September 2026 (auch für Produkte, die schon auf dem Markt sind). Wer binnen 24 Stunden eine Frühwarnung abgeben muss, braucht also schon heute einen verlässlichen Überblick über seine Komponenten. Man kann also gar nicht früh genug damit beginnen, eine SBOM zu erstellen.
Was gehört in eine vollständige SBOM?
Eine vollständige SBOM umfasst Ihre eigene Software und deren direkte Abhängigkeiten, also die Softwarebibliotheken, die Ihr Team bewusst einbindet. Entscheidend sind aber die transitiven Abhängigkeiten, die über andere Bibliotheken mitgeliefert werden. Die Schwachstelle Log4Shell zeigte 2021, wie viele Unternehmen nicht wussten, dass die Protokollierungsbibliothek Log4j indirekt in ihren Produkten steckte. Die CRA-Vorgabe „zumindest die obersten Abhängigkeiten“ in der SBOM abzubilden, ist daher eine Untergrenze, kein praxisnahes Zielbild.
Pro Komponente sollte die SBOM mindestens Name, Version, Lieferant, Lizenz, eine eindeutige Kennung wie die Package URL, eine Prüfsumme und die Abhängigkeitsbeziehungen enthalten.
Wichtig für die Praxis: Auch Container-Images (z.B. für Docker) – sofern diese ausgeliefert werden – brauchen eine eigene SBOM, denn sie bringen Betriebssystempakete und Laufzeitkomponenten mit, die nicht im Quellcode auftauchen.
Welches Format sollte die SBOM haben?
Der CRA verlangt lediglich ein „gängiges maschinenlesbares“ Format. Praktisch durchgesetzt haben sich zwei Standards:
- SPDX (Software Package Data Exchange) ist ein Projekt der Linux Foundation, stammt aus der Lizenz-Compliance und ist in Version 2.2.1 als ISO/IEC 5962 genormt. Seine Stärke ist die genaue Abbildung von Lizenzen, Urheberrechten und einzelnen Dateien.
- CycloneDX stammt aus dem Open Worldwide Application Security Project (OWASP), ist als ECMA-424 standardisiert und wurde von Beginn an für Sicherheitsanwendungen entworfen. Es beschreibt auch Dienste, Hardware und KI-Modelle und kann Aussagen zur Ausnutzbarkeit von direkt mitliefern.
Steht das Schwachstellenmanagement im Vordergrund, ist CycloneDX meist die naheliegende Wahl. Verlangen Kunden oder Ihre Rechtsabteilung vor allem Lizenztransparenz, spricht viel für SPDX.
Wichtiger als das Format ist seine Version: Die Technische Richtlinie TR-03183-2 des Bundesamts für Sicherheit in der Informationstechnik (BSI) verlangt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Die Vorgaben des BSI sind als konkrete technische Vorgabe eine gute Orientierung für die Praxis.
Wie lässt sich die SBOM als Prozess verankern?
Eine SBOM zu pflegen, heißt nicht, einfach nur eine Datei zu aktualisieren. Es geht darum, den Prozess der SBOM-Erstellung, die Versionierung, Ablage und Auswertung über den gesamten Unterstützungszeitraum zu sicherzustellen.
SBOM als Teil der CI/CD
Eine von Hand gepflegte Liste ist mit dem nächsten Update veraltet, denn jede neue Softwarebibliotheksversion und jedes neue Basis-Image verändert die Zusammensetzung Ihres Produkts. Eine verlässliche SBOM entsteht deshalb automatisch in der Pipeline für Continuous Integration und Continuous Delivery (CI/CD) bei jedem Release neu. Jede SBOM gehört zu genau einem Release-Artefakt, zugeordnet etwa über den Release-Tag und eine Prüfsumme des Builds.
Beispiel: Wie die Erzeugung einer SBOM technisch in der Build-Pipeline eingebettet werden kann, zeigt als Beispiel das Tool Syft, ein quelloffenes Kommandozeilenwerkzeug des Anbieters Anchore. Es läuft als eigener Pipeline-Schritt, direkt nachdem das Release-Artefakt entstanden ist, etwa ein Container-Image oder ein Installationspaket.
Syft setzt typischerweise am fertigen Artefakt an und liest Paketinformationen aus Programmiersprachen und Betriebssystem aus. So erfasst es auch die Laufzeitumgebung eines Containers.
Das Ergebnis, eine CycloneDX- oder SPDX-Datei, legt die Pipeline gemeinsam mit dem Artefakt ab. Ein nachgelagerter Scanner wie Grype gleicht diese Datei beim Build und danach regelmäßig mit Schwachstellendatenbanken ab und meldet angreifbare Komponenten.
Ansätze zur Umsetzung der SBOM
Die konkrete Umsetzung der SBOM ist abhängig von der Komplexität Ihrer Produktlandschaft:
| Ausgangslage | Typischer Ansatz | Beispiele |
|---|---|---|
| Ein Produkt, ein Technologie-Stack, keine Container | SBOM direkt aus dem Build-Werkzeug erzeugen | CycloneDX-Plugins für Maven, Gradle oder npm; SBOM-Export von GitHub oder GitLab |
| Mehrere Programmiersprachen, Auslieferung als Container | Universeller Generator auf dem fertigen Artefakt plus Schwachstellen-Scanner | Syft mit Grype oder entsprechende (kommerzielle) Alternativen |
| Produktportfolio, viele Releases, SBOMs von Lieferanten | Zentrale Plattform, die alle SBOMs sammelt und laufend überwacht | OWASP Dependency-Track; kommerzielle Plattformen für Software-Composition-Analyse (SCA) |
Wie verankern Sie den SBOM-Prozess im sicheren Entwicklungszyklus?
Im Secure Software Development Lifecycle ist die SBOM ein Freigabekriterium. Es ist zu empfehlen, den Prozess in fünf Schritten festzulegen:
- Automatisch erzeugen: Ohne aktuelle SBOM gibt es keine Freigabe.
- Eindeutig zuordnen: Jede SBOM gehört zu genau einem Release-Artefakt.
- Revisionssicher ablegen: Die SBOMs aller ausgelieferten Versionen bleiben über die gesamte Aufbewahrungsfrist verfügbar.
- Laufend auswerten: Prüfen Sie auch ältere Versionen regelmäßig (idealerweise täglich) gegen aktuelle Schwachstellendaten.
- Verbindlich reagieren: Bewerten Sie Treffer, beheben Sie sie nach Schweregrad, informieren Sie die Verantwortlichen der Komponente und melden Sie aktiv ausgenutzte Schwachstellen fristgerecht.
Ebenso wichtig sind klare Zuständigkeiten: Das Build-Engineering erzeugt die SBOM, der Einkauf fordert SBOMs von Zulieferern ein, die Rechtsabteilung prüft Lizenzen und Weitergabe, die Compliance-Funktion sichert Nachweise und Meldewege.
Am wirksamsten ist der SBOM-Prozess, wenn Sie ihn in ein bestehendes Informationssicherheits-Managementsystem (ISMS) nach ISO/IEC 27001 einbetten.
Welche Stolpersteine bremsen SBOM-Projekte in der Praxis aus?
SBOM-Projekte scheitern selten an der Technik, sondern eher an Lücken im Prozess. Typisch sind diese Stolpersteine:
- Unvollständige Erfassung: Die SBOM bildet nur die obersten Abhängigkeiten oder nur den Quellcode ab. Transitive Komponenten und die Container-Laufzeit bleiben unsichtbar.
- Fehlende Zuordnung: Ohne Bezug zum Release bleibt im Ernstfall unklar, welche Kundenversion betroffen ist.
- Treffer ohne Bewertung: Scan-Ergebnisse laufen auf, ohne dass jemand sie bewertet und dokumentiert. Warnungen stumpfen ab, Nachweise fehlen.
- Veraltete Formatversion: Das Werkzeug erzeugt eine ältere Formatversion, als die TR-03183-2 fordert, und niemand prüft das.
- Ungesicherte Werkzeugkette: Pipeline-Werkzeuge laufen ohne feste Versionen und geprüfte Quellen, obwohl sie selbst Teil Ihrer Lieferkette sind.
- Blinde Flecken bei Zulieferern: Für zugekaufte Komponenten fehlt eine SBOM des Lieferanten, und die Sorgfaltspflicht läuft ins Leere.
Welche Rolle spielt die SBOM für Ihre CRA-Compliance?
Die SBOM ist ein zentraler Nachweis in der technischen Dokumentation und damit in der Konformitätsbewertung. Ist eine notifizierte Stelle beteiligt, prüft sie in regelmäßigen Audits, ob Sie Ihre Verfahren zur Schwachstellenbehandlung angemessen umsetzen.
Zugleich ist die SBOM Grundlage Ihrer Sorgfaltspflicht bei Fremdkomponenten: Nur wer seine Komponenten kennt, kann prüfen, ob sie Sicherheitsaktualisierungen erhalten und frei von bekannten Schwachstellen sind.
Andersherum gilt: Kunden, die unter die NIS2-Richtlinie (Richtlinie (EU) 2022/2555) oder den Digital Operational Resilience Act (DORA) fallen, müssen ihre Lieferkette absichern und werden eine SBOM zunehmend von Ihnen einfordern.
Wie kann activeMind Unternehmen bei der SBOM unterstützen?
Unsere Experten helfen Unternehmen dabei, die Prozesse für Erstellung, Pflege, Archivierung und regelmäßige Analyse der SBOM im Unternehmen zu etablieren. Unser Fokus liegt auf der organisatorischen Integration in das für Ihre CRA-Compliance benötigte Managementsystem.
Ihre Vorteile:
- Durch unsere langjährige Erfahrung mit Cybersicherheit in verschiedensten Kontexten (z.B. ISO 27001, TISAX, NIS2, DORA) wissen unsere Experten, worauf es bei komplexen Prozessen wirklich ankommt – und was Sie sich sparen können.
- Mit unserer spezialisierten SaaS-Lösung bilden wir alle CRA-Aufgaben wie etwa die SBOM audit-sicher ab – und verschaffen so allen Verantwortlichen einen stets aktuellen Überblick.
In einem kostenfreien Erstgespräch erläutern Ihnen unsere Experten gerne das konkrete Vorgehen. Anschließend wissen Sie, welche Schritte Sie für eine funktionierende SBOM gemeinsam mit uns gehen können.
Fazit: Kein Release ohne Stückliste
Eine SBOM ist technisch schnell erzeugt. Ihren Wert entfaltet sie erst durch den Prozess dahinter: automatische Erzeugung, eindeutige Zuordnung zum Release, laufende Auswertung und klare Verantwortlichkeiten.
Für den Einstieg sind drei Schritte zu empfehlen:
- Benennen Sie eine verantwortliche Stelle,
- machen Sie die SBOM zum festen Freigabekriterium in der Build-Pipeline und
- nehmen Sie alle ausgelieferten Versionen in den regelmäßigen Schwachstellenabgleich auf.
Wer die Software-Stückliste so als Prozess versteht, kann im Ernstfall in Stunden statt Tagen sagen, ob die eigenen Produkte betroffen sind. Das hilft nicht nur Ihnen, sondern auch Ihren Kunden und kann sich so als relevanter Wettbewerbsvorteil erweisen.
