Wie wird eine SBOM erstellt?
Manuell ist die Erstellung kaum praktikabel: Eine typische Unternehmensanwendung enthält Hunderte von Abhängigkeiten. Die Praxis setzt auf automatisierte Werkzeuge, die Quellcode oder fertige Binärdateien analysieren und die Stückliste automatisch generieren. Diese Werkzeuge lassen sich in den Entwicklungsprozess integrieren, sodass die SBOM bei jeder neuen Version automatisch aktualisiert wird.
Als Standardformate haben sich zwei Spezifikationen etabliert:
„SPDX“ (Software Package Data Exchange) ist ein von der Linux Foundation entwickeltes und als ISO/IEC 5962 standardisiertes Format mit besonderer Stärke bei Lizenzinformationen.
„CycloneDX“ ab Version 1.5 ist stärker auf Sicherheitsaspekte und Schwachstellenverfolgung ausgerichtet und für den CRA besonders relevant.
Das BSI hat mit seiner Technischen Richtlinie TR-03183 Teil 2 konkrete formale Anforderungen formuliert: maschinenlesbar (JSON oder XML), Angaben zu Komponentenname, Version, Herkunft, deklarierten und abgeleiteten Lizenzen, kryptografischem Hashwert und Erstellungszeitstempel. Abhängigkeiten sind mindestens bis zur ersten externen Ebene zu dokumentieren.
Die Normenbasis: ISO 5230:2020 und ISO 18974:2023
Zwei ISO-Normen aus dem OpenChain-Projekt der Linux Foundation geben der SBOM-Praxis einen strukturierten Rahmen.
„ISO/IEC 5230:2020“ ist der internationale Standard für Open-Source-Lizenz-Compliance. Er definiert, was ein qualitatives Compliance-Programm leisten muss: Welche Open-Source-Komponenten sind im Produkt enthalten? Unter welchen Lizenzen stehen sie? Welche Verpflichtungen ergeben sich daraus? Die SBOM ist das zentrale Werkzeug dieses Programms — ohne sie lässt sich Lizenz-Compliance nicht systematisch betreiben.
„ISO/IEC 18974:2023“ ergänzt die Lizenz-Perspektive um die Sicherheitsdimension: Wie werden Open-Source-Komponenten auf bekannte Schwachstellen überwacht? Auch hier ist die SBOM der Ausgangspunkt — wer nicht weiß, welche Komponenten in seinem Produkt stecken, kann keine systematische Schwachstellenüberwachung betreiben.
Beide Normen sind freiwillig. Sie werden aber in Einkaufsprozessen zunehmend als Qualitätsnachweis gefordert — insbesondere in der Automobilindustrie und bei öffentlichen Ausschreibungen.
Die lizenzrechtliche Dimension
Neben dem KI-Problem gibt es die klassische Lizenzfrage, die durch die SBOM beherrschbar wird.
Viele Open-Source-Lizenzen — insbesondere die GPL-Familie — enthalten Copyleft-Klauseln: Wer GPL-lizenzierte Komponenten in seiner Software verwendet und diese weitergibt, muss den Quellcode offenlegen und die Software selbst unter der GPL lizenzieren. Wer nicht weiß, dass seine Software eine solche Komponente enthält, kann diese Verpflichtung nicht erfüllen und riskiert eine Urheberrechtsverletzung.
Hinzu kommen Lizenzinkompatibilitäten — manche Lizenzen lassen sich nicht ohne weiteres kombinieren — sowie Verwendungsbeschränkungen, die den kommerziellen Einsatz oder bestimmte Nutzungsarten ausschließen. Die SBOM macht diese Risiken sichtbar, bevor sie zum Problem werden.
NIS2: Kaum SBOM-Pflichten
Die NIS-2-Richtlinie und ihre deutsche Umsetzung im NIS2UmsuCG (in Kraft seit Dezember 2025) verpflichten Betreiber wesentlicher und wichtiger Einrichtungen zu umfangreichen Cybersicherheitsmaßnahmen, darunter Lieferkettenmanagement und Sicherheitsanforderungen für eingesetzte Software.
Eine ausdrückliche SBOM-Pflicht enthält NIS2 nicht. Der Standard des Lieferkettenmanagements nach §30 BSIG kann eine SBOM faktisch nahelegen — als gesetzliche Pflicht lässt sie sich daraus aber nicht ableiten.
CRA: Die gesetzliche Pflicht ab 2027
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) enthält die eigentliche SBOM-Pflicht — für Hersteller von Produkten mit digitalen Elementen, die in der EU in den Verkehr gebracht werden.
Art. 13 CRA verpflichtet zur Erstellung und laufenden Pflege einer SBOM in maschinenlesbarem Standardformat. Mindestens die direkten Abhängigkeiten müssen erfasst sein. Die SBOM ist als Teil der technischen Dokumentation mindestens zehn Jahre aufzubewahren und muss über den gesamten Produktlebenszyklus aktuell gehalten werden.
Erwägungsgrund 77 stellt ausdrücklich klar: Die SBOM muss “nicht veröffentlicht“ werden. Sie ist eine interne Unterlage, die Marktüberwachungsbehörden auf Anfrage zugänglich gemacht werden muss — nicht standardmäßig dem Kunden. Wer eine SBOM gegenüber Kunden offenlegen möchte, kann das tun; verpflichtet ist er dazu nicht. Umgekehrt: Wer als Kunde eine SBOM haben möchte, muss das vertraglich vereinbaren.
Die vollständige Anwendbarkeit aller CRA-Anforderungen gilt ab dem „11. Dezember 2027“. Mit dem Aufbau von Prozessen und Werkzeugen heute zu beginnen, ist keine Fleißarbeit — es ist der einzig realistische Weg, die Deadline einzuhalten.
Reicht die SBOM dafür allein aus? Nein.
Hier ist eine These, die in der aktuellen Diskussion fehlt.
Die klassische SBOM dokumentiert Komponenten und ihre Herkunft. Sie ist ein technisches Bestandsverzeichnis. Was sie nicht leistet: Sie sagt nichts darüber aus, ob ein Mensch den fraglichen Code qualitativ geprüft, bewertet und sich zu eigen gemacht hat.
Wer mit KI entwickelt, braucht deshalb eine Ergänzungsschicht: einen „Prüfvermerk“, der dokumentiert, dass ein Entwickler den KI-generierten Code gesichtet, verstanden und fachlich verantwortet hat. Erst dieser Prüfvermerk — sei es als Annotation in der SBOM, als Eintrag im Versionskontrollsystem oder als separate Entwicklungsdokumentation — schafft die Grundlage für das Argument, dass hier eine menschliche Bearbeitung stattgefunden hat, die Schutzfähigkeit begründen kann.
Das ist heute kein Standardfeld in SPDX oder CycloneDX. Es ist auch keine gesetzliche Pflicht. Aber es ist die logische Konsequenz aus dem Zusammenspiel von §69a UrhG, dem Secure-Development-Lifecycle-Anforderungen des CRA und den Literacy-Pflichten des EU AI Act (Art. 4): Wer KI-Tools im Unternehmen einsetzt, muss nachweisen können, dass er kompetent damit umgeht. Der Prüfvermerk ist dieser Nachweis.
