Wer heute Software entwickelt, baut fast nie bei null – Bibliotheken, Frameworks und Container-Images sind Standard. Genau hier setzt die Software Bill of Materials (SBOM) an: Sie ist die technische Stückliste deiner Anwendung. Sie zeigt, welche Komponenten du wirklich ausgeliefert hast – und wird mit den neuen EU‑Vorgaben zunehmend zur rechtlichen Pflicht, nicht nur zur technischen Kür. Eine saubere SBOM entscheidet künftig mit darüber, ob ein Projekt Sicherheitsvorfälle beherrscht und Haftungsrisiken im Griff behält – oder im Zweifel nicht nachweisen kann, was überhaupt im eigenen Produkt steckt.
Eine SBOM ist ein maschinenlesbares Dokument und entspricht einer elektronischen Stückliste: Es inventarisiert eine Codebasis und enthält somit Informationen über alle verwendeten Komponenten einer Software. Inzwischen gewinnt die SBOM durch den CRA erhebliche juristische Relevanz und gehört zwingend zur Compliance bei Einsatz oder Entwicklung von Software, speziell mit Blick auf die Supply-Chain.
Was ist eine SBOM – technisch und rechtlich?
Nach der BSI‑Technischen Richtlinie TR‑03183 ist eine SBOM ein maschinenlesbares Dokument, das alle Komponenten eines Softwareprodukts strukturiert auflistet – inklusive Versionen und Beziehungen zwischen den Komponenten. Aus juristischer Sicht ist sie damit nicht nur eine technische Best‑Practice, sondern der objektivierte Nachweis, welche Drittkomponenten im Produkt stecken, wo sich bekannte Schwachstellen auswirken können und welche Lizenz- und Updatepflichten wirklich greifen.
Wenn man in einem Microservice fünf Dependency‑Ebenen tief in npm‑ oder Maven‑Packages steckt, weiß ohne SBOM oft niemand mehr, welche Bibliothek in welcher Version am Ende wirklich mit ausgerollt wird. Die SBOM schließt genau diese Wissenslücke – automatisiert und reproduzierbar.
Bedeutung der SBOM
Eine SBOM sollte bei jedem Softwarehersteller und -anbieter vorhanden sein, um die Komplexität von Software transparent darstellen zu können und um zu wissen, welche Komponenten (z.B. Bibliotheken) verwendet werden, da fast immer eine Vielzahl unterschiedlicher Quellen und Komponenten genutzt wird. Dieses Wissen ist für Softwaremanagementprozesse, insbesondere für einen durchgängigen IT-Sicherheitsprozess und das Software-Lifecycle-Management unabdingbar und gilt daher als „Best Practice“ einer sicheren Software-Lieferkette. Gleichzeitig ist es für die Open Source Compliance nützlich.
Mit Hilfe von SBOM-Informationen kann überprüft werden, ob ein Produkt potenziell von einer Schwachstelle betroffen ist, indem die Komponentenliste des Produkts mit den in den Schwachstelleninformationen aufgeführten Softwarekomponenten verglichen wird. Durch diese standardisierte Abklärung dürfte es sich aus Sicht des Managements um eine Standardmaßnahme zur Vermeidung eigener Haftung handeln.
Eine SBOM sagt nichts darüber, ob eine Komponente sicher konfiguriert ist oder ob eine Schwachstelle praktisch ausnutzbar ist. Sie ist aber die notwendige Datenbasis, um CVE‑Fehlermeldungen automatisiert gegen das eigene Produkt zu spiegeln, etwa in Kombination mit VEX‑Informationen (Vulnerability Exploitability Exchange).
Softwarerecht bei uns
Das Softwarerecht samt Rechtsfragen rund um Open Source ist die große Leidenschaft von Rechtsanwalt Jens Ferner; entsprechend finden Sie auf unserer Seite Unmengen von Informationen rund um Rechtsfragen von Software sowie Beratung zu Softwarerecht und Opensource-Software:
- Rechtsfragen in IT-Projekten
- Rechtsfragen zu Computerspielen
- Cybersicherheit in der Software-Lieferkette und SBOM
- Urheberrechtlicher Schutz von Software und Urheberrecht in der Softwareentwicklung mit Arbeitnehmer
- Copyleft bei Opensource-Software
- Opensource-Software-Compliance und OSS-Rechtsfragen
- Haftung bei Opensource-Software
- Softwareupdates im Vertragsrecht
- CE-Kennzeichen für Software
- Man sollte in jedem Fall unsere Übersichten mit EUGH-Rechtsprechung und BGH-Rechtsprechung zum Thema gebrauchte Software gelesen haben
- GNU GPL und deutsches Recht
- Produkthaftung: Opensource Software sowie kommerzielle Software & KI
- Schutz von KI
- Fortbestand der Unterlizenz nach Untergang der Hauptlizenz
- Haftung für Chatbot
Haftungsprobleme bei fehlender SBOM
Mit Blick auf Produktsicherheitsrecht (insbesondere Cyber Resilience Act) und das modernisierte Produkthaftungsrecht wird eine SBOM zu einem Baustein der Verkehrssicherungspflichten von Herstellern. Wer sicherheitsrelevante Software ohne nachvollziehbare Komponentenliste in Verkehr bringt, wird es schwer haben, später zu zeigen, dass er zumutbare Maßnahmen zur Beherrschung von Schwachstellen ergriffen hat.
Im Incident‑Fall wird nicht gefragt, wie elegant der Code ist, sondern ob man schnell und belastbar sagen kann: Sind wir von CVE‑XYZ betroffen – ja oder nein? Ohne SBOM bleibt das oft ein Ratespiel.
SBOM und die Produkthaftung
Die SBOM spielt in der modernen Produkthaftung eine bedeutende Rolle – allerdings muss man den gesamten Komplex verstehen.
In der neuen Produkthaftungsrichtlinie und im deutschen Gesetzentwurf wird der Begriff „SBOM” nicht verwendet und es gibt keine ausdrückliche Pflicht zur Erstellung einer SBOM. Vielmehr spielt die SBOM im Cyber Resilience Act und in technischen Regelwerken (wie BSI-TR-03183) eine zentrale Rolle und wirkt von dort mittelbar in die Produkthaftung hinein. Die SBOM wird vielmehr über den Cyber Resilience Act verbindlich, der Herstellern von Produkten mit digitalen Elementen ein Schwachstellenmanagement einschließlich der Erstellung einer Software-Stückliste auferlegt.
Diese Verpflichtung ist produktsicherheitsrechtlich verortet. Aus Sicht der Produkthaftung sind solche Vorgaben relevant, da die Richtlinie explizit an die Einhaltung der einschlägigen Sicherheitsanforderungen des Unionsrechts anknüpft, um Fehlerhaftigkeit zu beurteilen. Damit wird die SBOM zu einem faktischen Beweis- und Sorgfaltsinstrument: Wer die CRA-Pflichten erfüllt und eine SBOM führt, kann im Haftungsprozess eher darlegen, dass er zumutbare Maßnahmen zur Identifikation und Behandlung von Schwachstellen getroffen hat. Umgekehrt kann das Fehlen einer SBOM als Indiz dafür gewertet werden, dass das Cybersicherheits- und Schwachstellenmanagement nicht dem Stand von Technik und Recht entspricht, was die Annahme eines Produktfehlers erleichtert.
SBOM-Pflicht im CRA
Der Cyber Resilience Act der EU wird die Erstellung einer SBOM für viele Produkte mit digitalen Elementen verpflichtend machen; der aktuelle Entwurf sieht dies ausdrücklich als Bestandteil des Sicherheits‑by‑Design‑Ansatzes vor. Für Entwickler heißt das: Die SBOM rückt aus der Sphäre ‚nice to have für Security‘ in die Compliance‑Pflicht – vergleichbar mit technischer Dokumentation in der klassischen Produktwelt.
Hersteller sind durch diese Pflichtdokumentation dazu verpflichtet, nicht nur ihre eigenen Entwicklungen, sondern auch Drittkomponenten lückenlos zu erfassen und über den gesamten Produktlebenszyklus hinweg aktuell zu halten. Dadurch ist es möglich, Sicherheitslücken schneller zu identifizieren und gezielt zu schließen, beispielsweise wenn eine bekannte Schwachstelle in einer eingebetteten Bibliothek auftritt. Zwar ist die SBOM primär für Behörden und interne Prozesse bestimmt, doch auch Kunden profitieren indirekt davon: Sie erhalten Klarheit über die Unterstützungsdauer von Updates und können Risiken in ihrer IT-Infrastruktur besser einschätzen.
Open Source, SBOM und Supply‑Chain‑Risiken
Weil moderne Software in der Tiefe Open‑Source‑getrieben ist, wird die SBOM auch zum Schlüsselinstrument der Open‑Source‑Compliance und des Lieferketten‑Risikomanagements. Fachbeiträge weisen darauf hin, dass Unternehmen ohne SBOM weder ihre Lizenzpflichten noch ihre Haftungsrisiken beim Einsatz von OSS entlang der Supply Chain sauber steuern können – zumal die neue Produkthaftung die Verantwortung klar beim Integrator und Endhersteller verortet.
Wenn Sie OSS‑Bibliotheken einbauen, ohne dass sie in einer SBOM auftauchen, fällt das rechtlich nicht unter ‚Open Source‘, sondern unter ‚nicht dokumentierte Fremdkomponente‘ – genau diese Black‑Box‑Anteile wird der Gesetzgeber künftig wohl nicht mehr akzeptieren.
Modernes Risikomanagement
Die sich am Ende ergebende SBOM-Pflicht bedeutet damit einen Paradigmenwechsel im Risikomanagement, der allen Beteiligten, vom Entwickler bis zum einsetzenden Unternehmen, klar sein muss: Bislang führten undokumentierte Abhängigkeiten oft zu verzögerten Reaktionen auf Exploits, wie im Fall von Log4Shell. Der CRA zwingt Hersteller nun, ihre Software-Lieferketten systematisch zu überwachen und proaktiv zu warten.
Gleichzeitig dient die SBOM als Nachweisinstrument für Compliance, etwa gegenüber Marktaufsichtsbehörden oder im Haftungsfall. Denn wer nachweisen kann, dass alle Komponenten gemäß den CRA-Standards gepflegt wurden, minimiert rechtliche Risiken. Die SBOM wird somit zum Bindeglied zwischen technischer Sicherheit und regulatorischer Absicherung und ist ein Werkzeug, das nicht nur Bürokratie schafft, sondern auch die Resilienz digitaler Produkte nachhaltig erhöht. Ihre Einführung unterstreicht, wie der CRA Cybersicherheit als dynamischen Prozess begreift – von der Entwicklung („Security by Design“) bis zur Außerbetriebnahme. Für Entwicklungsteams heißt das ganz konkret:
- SBOM‑Support in die Toolchain integrieren: Build‑Pipelines sollten automatisch SBOMs erzeugen (z. B. in SPDX oder CycloneDX), versionieren und mit Releases verknüpfen.
- SBOMs als Teil der Produktdokumentation behandeln: Intern eindeutig zuständig machen (z. B. Product Security / DevSecOps) und Aufbewahrungsfristen am Lebenszyklus ausrichten.
- SBOMs mit Vulnerability‑Management verknüpfen: CVE‑Feeds und VEX‑Infos gegen die SBOM spiegeln, um schnell entscheiden zu können, welche Produkte tatsächlich betroffen sind.
- Vertrags- und Compliance‑Schnittstelle beachten: SBOM‑Fähigkeit in Ausschreibungen und Verträgen berücksichtigen, insbesondere bei kritischen Zulieferkomponenten.
Übrigens: Im US-amerikanischen Raum wird die SBOM durch die US Executive Order 14028 vom Mai 2021 bereits für Anwendungen im Behördenumfeld gefordert. Seit März 2023 muss zudem bei der Zulassung von Medizinprodukten zwingend eine SBOM seitens der FDA (Food and Drug Administration) vorgelegt werden.
Rechtsanwalt Jens Ferner ist Lehrbeauftragter für Wirtschaftsstrafrecht und IT-Compliance (FH Aachen), Softwareentwickler, fortgebildet in Kommunikationspsychologie und publiziert fortlaufend.
Erreichbarkeit: Erstkontakt per Mail oder Rückruf.
Unsere Anwaltskanzlei im Raum Aachen ist hochspezialisiert auf Strafverteidigung, Cybercrime, Wirtschaftsstrafrecht samt Steuerstrafrecht. Zudem sind wir für Unternehmen im Softwarerecht und Cybersicherheitsrecht beratend tätig.
- KI-Agenten als Innentäter: Wie OpenClaw & Co. zum Haftungs- & Sicherheitsrisiko werden - 14. März 2026
- Retrograde Telegram-Überwachung als Quellen-TKÜ - 13. März 2026
- Cyber Resilience Act als Ende der analogen Fabrik - 11. März 2026
