Moderne Software entsteht fast nie vollständig im eigenen Haus. Selbst eine überschaubare Anwendung kann auf Hunderten Bibliotheken, Frameworks, Container-Paketen und Cloud-Diensten aufbauen. Diese Komponenten beschleunigen die Entwicklung enorm. Gleichzeitig entsteht eine schwer sichtbare Lieferkette: Wird in einer kleinen Bibliothek eine Sicherheitslücke entdeckt, müssen Unternehmen oft erst mühsam klären, ob und wo sie überhaupt eingesetzt wird.
Genau hier setzt die Software Bill of Materials, kurz SBOM, an. Sie ist ein maschinenlesbares Verzeichnis der Softwarebestandteile eines Produkts – vergleichbar mit einer Stückliste in der Industrie. Eine gute SBOM nennt nicht nur Paketnamen und Versionen. Sie beschreibt auch Abhängigkeiten, Hersteller, eindeutige Kennungen, Prüfsummen und weitere Informationen, mit denen sich Komponenten zuverlässig identifizieren lassen.
Im September 2026 ist das Thema besonders aktuell. Seit dem 11. September gelten erste Meldepflichten des europäischen Cyber Resilience Act. Die umfassenden Produktpflichten folgen zwar erst Ende 2027, doch Hersteller müssen ihre Prozesse schon jetzt aufbauen. Eine gepflegte SBOM wird dabei zu einem wichtigen Bindeglied zwischen Entwicklung, Einkauf, IT-Sicherheit und regulatorischer Dokumentation. Sie verhindert keine Schwachstelle. Aber sie verkürzt die entscheidende Zeit zwischen der Meldung einer Lücke und der Antwort auf die Frage: Sind wir betroffen?
Was ist eine Software Bill of Materials?
Eine SBOM ist ein formaler Datensatz über die Bestandteile eines Softwareprodukts und ihre Beziehungen untereinander. Der Begriff lehnt sich an die klassische Bill of Materials aus Fertigung und Maschinenbau an. Dort beschreibt eine Stückliste, welche Teile in einem Produkt verbaut wurden. Bei Software sind diese Teile beispielsweise Open-Source-Bibliotheken, kommerzielle Module, Betriebssystempakete, eingebettete Firmware, Container-Basisimages oder selbst entwickelte Komponenten.
Die Analogie ist hilfreich, aber nicht vollständig. Ein mechanisches Bauteil bleibt nach der Fertigung meist dasselbe. Software verändert sich laufend: Pakete erhalten Updates, Abhängigkeiten werden ersetzt, Images neu gebaut und Schwachstellen erst Monate später entdeckt. Eine SBOM ist deshalb keine einmalige Bestandsaufnahme, sondern ein versionsgebundenes Dokument. Zu jedem Release muss klar sein, welche Komponenten tatsächlich in genau dieser ausgelieferten Version enthalten sind.
Typische Einträge umfassen:
- Name und Version der Komponente
- Hersteller, Anbieter oder Autor
- eindeutige Paketkennungen wie Package URL oder CPE
- kryptografische Prüfsummen des Artefakts
- Lizenzinformationen
- Beziehungen zwischen direkten und indirekten Abhängigkeiten
- Zeitpunkt und Werkzeug der Erstellung
- Bezug zum konkreten Produkt, Build oder Release
Menschen können eine SBOM lesen, ihr eigentlicher Wert entsteht jedoch durch Automatisierung. Sicherheitssysteme können Tausende Einträge mit Schwachstellendatenbanken abgleichen, neue Warnungen auf vorhandene Produkte beziehen und betroffene Versionen markieren. Dafür müssen Namen, Versionen und Beziehungen eindeutig sein. Eine lose Tabellenkalkulation mit Paketnamen ist deshalb noch keine belastbare SBOM.
Warum Softwarelieferketten so unübersichtlich geworden sind
Ein Entwickler installiert heute selten nur eine einzelne Bibliothek. Das gewünschte Paket zieht weitere Pakete nach, diese wiederum ihre eigenen Abhängigkeiten. In JavaScript-, Python-, Java- oder Container-Ökosystemen können so große Bäume entstehen. Sichtbar ist zunächst oft nur die direkte Abhängigkeit. Eine Schwachstelle kann aber mehrere Ebenen tiefer liegen.
Hinzu kommt, dass nicht jede Komponente aus einem öffentlichen Paketmanager stammt. Unternehmen verwenden interne Bibliotheken, herstellerspezifische SDKs, vorkompilierte Binärdateien, Betriebssystemmodule und Firmware. In vernetzten Geräten treffen Hardware, Embedded Software, mobile App, Backend und Cloud-Dienste aufeinander. Jede Schicht besitzt eine eigene Lieferkette und einen eigenen Aktualisierungsrhythmus.
Diese Komplexität ist nicht automatisch ein Sicherheitsproblem. Wiederverwendbare Komponenten sind eine Grundlage moderner Softwareentwicklung. Das Risiko entsteht durch fehlende Transparenz. Ohne Inventar bleiben vier Fragen unbeantwortet:
- Welche Komponenten befinden sich in einem Produkt?
- Welche konkrete Version wurde ausgeliefert?
- Welche anderen Komponenten hängen davon ab?
- Welche Produkte und Kunden sind von einer neuen Schwachstelle betroffen?
Der bekannte Log4Shell-Fall hat gezeigt, wie schwierig die Suche werden kann. Die betroffene Java-Bibliothek Log4j steckte nicht nur in direkt installierten Anwendungen, sondern häufig tief in Produkten anderer Anbieter. Viele Organisationen mussten Server, Archive, Container und Anwendungen nachträglich durchsuchen. Eine aktuelle SBOM hätte die technische Lücke nicht verhindert. Sie hätte aber schneller gezeigt, wo welche Version verbaut war – und wo nicht.
Was eine SBOM kann – und was nicht
Eine SBOM wird gelegentlich wie ein Sicherheitszertifikat behandelt. Das ist falsch. Sie beschreibt Zusammensetzung und Herkunft, bewertet aber nicht automatisch die Qualität des Codes. Ein Produkt kann eine formal korrekte SBOM besitzen und trotzdem unsicher sein. Umgekehrt kann eine gut entwickelte Anwendung ohne SBOM technisch robust sein, bei einer neuen Schwachstelle aber schwerer zu überprüfen.
| Eine SBOM kann | Eine SBOM kann nicht allein |
|---|---|
| Komponenten und Versionen sichtbar machen | beweisen, dass ein Produkt keine Schwachstellen enthält |
| den Abgleich mit Schwachstellendaten automatisieren | entscheiden, ob eine gemeldete Lücke im konkreten Produkt ausnutzbar ist |
| Lizenz- und Lieferkettenfragen unterstützen | Codeprüfungen, Penetrationstests und Threat Modeling ersetzen |
| betroffene Releases schneller identifizieren | veraltete oder falsch erzeugte Daten korrigieren |
| Informationen zwischen Hersteller und Kunde standardisieren | ohne klare Prozesse automatisch zu einer Sicherheitsreaktion führen |
Der Unterschied zwischen Inventar und Bewertung ist zentral. Ein Sicherheitsteam kann beispielsweise erkennen, dass eine Bibliothek mit bekannter CVE in einem Produkt vorkommt. Daraus folgt noch nicht, dass die Schwachstelle erreichbar oder ausnutzbar ist. Vielleicht wird die betroffene Funktion nicht verwendet, durch eine Konfiguration blockiert oder bereits mit einem herstellerspezifischen Patch abgesichert. Die SBOM liefert den Ausgangspunkt für die Analyse, nicht ihr endgültiges Urteil.
Wie aus einer Komponentenliste eine Sicherheitsfunktion wird
Der praktische Nutzen entsteht durch die Verbindung mehrerer Datenquellen. Zuerst wird für einen konkreten Build eine SBOM erzeugt. Anschließend ordnet ein Analysewerkzeug die Komponenten bekannten Schwachstellen zu. Neue Meldungen können fortlaufend gegen bereits archivierte SBOMs geprüft werden. Wird ein Treffer gefunden, folgt die technische Bewertung: Ist die betroffene Komponente im ausgelieferten Produkt vorhanden? Ist der verwundbare Code erreichbar? Existiert ein Update oder eine andere Schutzmaßnahme?
Ein typischer Ablauf sieht so aus:
- Der Build-Prozess löst alle Abhängigkeiten auf.
- Ein Generator erstellt daraus eine SBOM in einem Standardformat.
- Die Datei wird validiert, signiert und zusammen mit dem Release archiviert.
- Ein System gleicht die Komponenten regelmäßig mit Schwachstellendaten ab.
- Treffer werden nach tatsächlicher Betroffenheit und Risiko bewertet.
- Entscheidungen, Updates und Kundeninformationen werden dokumentiert.
Die SBOM sollte dabei nicht erst nach der Veröffentlichung entstehen. Wird sie direkt in die CI/CD-Pipeline integriert, gehört sie zum Build wie Tests oder Signaturen. Jede neue Version erhält ihren eigenen Datensatz. Das reduziert manuelle Arbeit und verhindert, dass eine Liste aus dem Quellcode fälschlich für das tatsächlich ausgelieferte Artefakt gehalten wird.
Warum der Build-Kontext wichtig ist
Eine reine Analyse der Projektdateien zeigt, was theoretisch als Abhängigkeit deklariert wurde. Sie muss nicht vollständig mit dem Endprodukt übereinstimmen. Bedingte Module, Plattformunterschiede, Build-Skripte oder nachträglich hinzugefügte Dateien können das Ergebnis verändern. Für hohe Genauigkeit werden deshalb mehrere Perspektiven kombiniert: Quellcode- und Manifestanalyse, Informationen des Paketmanagers sowie eine Untersuchung des gebauten Containers, Binärpakets oder Firmware-Images.
Je näher die Erzeugung am fertigen Artefakt liegt, desto besser bildet sie den ausgelieferten Zustand ab. Gleichzeitig kennt eine reine Binäranalyse nicht immer alle ursprünglichen Metadaten. Ein robustes Verfahren führt beide Sichtweisen zusammen und dokumentiert, wie der Datensatz entstanden ist.
SPDX und CycloneDX: Die wichtigsten SBOM-Formate
Damit Hersteller, Kunden und Werkzeuge Informationen austauschen können, braucht es gemeinsame Datenmodelle. Zwei Formate dominieren die Praxis: SPDX und CycloneDX. Beide sind offen, maschinenlesbar und für professionelle Lieferketten geeignet. Die Wahl hängt weniger von einem pauschalen „besser“ oder „schlechter“ ab als vom Einsatzzweck, vorhandenen Werkzeugen und den Anforderungen der Partner.
SPDX
SPDX entstand im Umfeld der Linux Foundation und ist als internationaler Standard ISO/IEC 5962 anerkannt. Historisch lag ein starker Schwerpunkt auf Lizenz- und Herkunftsinformationen. Die aktuelle 3.0-Familie arbeitet mit modularen Profilen. Neben dem Kern lassen sich unter anderem Software-, Sicherheits-, Lizenz-, Build-, Datensatz- und KI-Informationen abbilden. Dadurch kann SPDX weit über eine einfache Paketliste hinausgehen.
CycloneDX
CycloneDX kommt aus dem OWASP-Umfeld und wurde von Beginn an stark auf Sicherheits- und Lieferkettenanwendungen ausgerichtet. Die Spezifikation kann Komponenten, Dienste und ihre Beziehungen darstellen und unterstützt neben SBOMs weitere Stücklistenarten. Dazu gehören etwa Informationen zu Cloud-Diensten, Hardware, kryptografischen Verfahren oder KI-Systemen. Version 1.7 erweitert unter anderem die Darstellung kryptografischer Assets, Datenherkunft und geistiger Eigentumsrechte.
| Aspekt | SPDX | CycloneDX |
|---|---|---|
| Ursprung | Linux Foundation | OWASP / Ecma International |
| Stärke | breites Datenmodell, Herkunft und Lizenzen | Security-Automatisierung und verschiedene BOM-Typen |
| Aktuelle Hauptlinie | 3.0 mit Profilen | 1.7 |
| Typische Formate | JSON, RDF und weitere Serialisierungen | JSON und XML |
| Einsatz | SBOM, Compliance, Security, AI und Daten | SBOM, VEX, SaaSBOM, CBOM, HBOM und AI/ML-BOM |
Für Unternehmen ist Interoperabilität wichtiger als Formatloyalität. Ein Lieferant kann CycloneDX liefern, während ein Kunde SPDX bevorzugt. Konverter helfen, doch bei jeder Umwandlung können Details verloren gehen. Deshalb sollte früh festgelegt werden, welche Pflichtfelder, Kennungen, Beziehungstiefen und Versionen akzeptiert werden. „Wir liefern irgendeine SBOM“ ist keine ausreichende Beschaffungsanforderung.
Warum eindeutige Kennungen wichtiger sind als Paketnamen
Menschen erkennen einen Namen wie „openssl“ sofort. Für Maschinen reicht er nicht immer aus. Gleiche oder ähnliche Namen können in verschiedenen Ökosystemen vorkommen; Hersteller schreiben Bezeichnungen unterschiedlich; Distributionen ergänzen eigene Versionssuffixe. Ohne eindeutige Kennung entstehen falsche Treffer oder tatsächliche Komponenten werden übersehen.
Die Package URL, kurz purl, beschreibt ein Paket einschließlich Typ, Namespace, Name und Version. CPE-Kennungen werden häufig verwendet, um Produkte mit klassischen Schwachstellendatenbanken zu verbinden. Kryptografische Hashwerte identifizieren ein konkretes Artefakt auf Byte-Ebene. Keine dieser Angaben löst jedes Problem allein. Zusammen verbessern sie die Zuordnung erheblich.
Ebenso wichtig ist der Abhängigkeitsgraph. Eine flache Liste sagt, dass eine Komponente vorhanden ist. Sie sagt nicht, warum sie vorhanden ist und welche Anwendung sie eingebracht hat. Für eine schnelle Reaktion muss nachvollziehbar sein, welche direkte Abhängigkeit zu einem verwundbaren Unterpaket führt. Fehlen diese Kanten, wird aus der Stückliste ein Sack voller Teile statt eines Bauplans.
VEX: Wenn „vorhanden“ nicht automatisch „betroffen“ bedeutet
Bei großen Produkten kann der automatisierte Abgleich Tausende Warnungen erzeugen. Ein Teil davon ist für das konkrete Produkt nicht relevant. Genau dafür gibt es VEX, den Vulnerability Exploitability eXchange. Eine VEX-Erklärung ergänzt die SBOM um eine maschinenlesbare Aussage zur Betroffenheit. Ein Hersteller kann beispielsweise dokumentieren, dass ein Produkt nicht betroffen ist, weil der verwundbare Codepfad nicht ausgeführt werden kann.
Übliche Zustände unterscheiden sinngemäß zwischen betroffen, nicht betroffen, behoben und noch in Prüfung. Entscheidend ist die Begründung. Eine pauschale Aussage ohne technische Grundlage schafft kein Vertrauen. Gute VEX-Daten nennen den betroffenen Produktstand, die Schwachstelle, den Status, den Zeitpunkt und eine nachvollziehbare Begründung.
SBOM und VEX erfüllen damit unterschiedliche Aufgaben:
- Die SBOM beantwortet: Was ist enthalten?
- VEX beantwortet: Was bedeutet eine bekannte Schwachstelle für dieses Produkt?
Diese Trennung reduziert unnötige Alarmmeldungen. Gleichzeitig darf „nicht betroffen“ nicht zu einem dauerhaften Etikett werden. Ändern sich Konfiguration, Build oder Angriffstechnik, muss die Bewertung erneut geprüft werden.
Ein Beispiel: Von der neuen CVE zur belastbaren Antwort
Angenommen, an einem Dienstagmorgen wird eine kritische Schwachstelle in einer verbreiteten Bildverarbeitungsbibliothek veröffentlicht. Ohne strukturiertes Inventar beginnt eine Rundfrage: Welche Teams nutzen die Bibliothek? Steckt sie in einem alten Kundenportal, in einer mobilen App oder in der Firmware eines Geräts? Paketdateien, Tickets und Repositories werden einzeln durchsucht. Die Antworten beziehen sich womöglich auf den aktuellen Entwicklungsstand, nicht auf bereits ausgelieferte Versionen.
Mit einem gepflegten SBOM-System läuft die erste Analyse anders. Die eindeutige Paketkennung und der betroffene Versionsbereich werden gegen alle archivierten Release-Stücklisten geprüft. Innerhalb kurzer Zeit entsteht eine Liste konkreter Produkte und Versionen. Der Abhängigkeitsgraph zeigt, über welches Hauptpaket die Bibliothek eingebunden wurde. Verantwortliche Teams erhalten automatisch einen Vorgang mit Produktkontext, Kundenkreis und Supportzeitraum.
Danach beginnt die eigentliche Sicherheitsarbeit. Ein Team stellt fest, dass die Bibliothek zwar enthalten ist, die verwundbare Funktion aber in seinem Produkt nicht aufgerufen wird. Es dokumentiert die Analyse als VEX-Status „nicht betroffen“ mit Begründung. Ein anderes Produkt verarbeitet tatsächlich nicht vertrauenswürdige Bilddateien und gilt als betroffen. Dort wird das aktualisierte Paket eingebaut, getestet und als neues Release veröffentlicht. Die neue Version erhält wiederum eine neue SBOM, in der die korrigierte Abhängigkeit nachweisbar ist.
Dieses Beispiel zeigt den Unterschied zwischen Geschwindigkeit und Automatismus. Die SBOM trifft die Entscheidung nicht selbst. Sie reduziert den Suchraum, verbindet die Warnung mit dem richtigen Produktstand und schafft eine nachvollziehbare Kette vom ersten Treffer bis zur Korrektur. Besonders bei kurzen Melde- und Reaktionsfristen ist genau diese Vorarbeit entscheidend. Ohne sie wird wertvolle Zeit für Bestandsaufnahme verbraucht; mit ihr kann sich das Team auf Ausnutzbarkeit, Schutzmaßnahmen und Kommunikation konzentrieren.
Der Cyber Resilience Act macht SBOMs für Europa praktisch relevant
Mit dem Cyber Resilience Act führt die EU horizontale Cybersecurity-Anforderungen für Produkte mit digitalen Elementen ein. Dazu zählen nicht nur klassische Softwarepakete, sondern auch viele Geräte, Maschinen und vernetzte Produkte, deren Funktion von Software abhängt. Hersteller müssen Sicherheitsrisiken über den Produktlebenszyklus behandeln, Schwachstellen bearbeiten und technische Nachweise führen.
Die Verordnung ist seit Dezember 2024 in Kraft. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Die zentralen Produktanforderungen werden ab dem 11. Dezember 2027 anwendbar. Details zu den aktuellen 24- und 72-Stunden-Fristen erklärt unser Beitrag zum Cyber Resilience Act 2026.
Für die technische Dokumentation verlangt der CRA eine maschinenlesbare SBOM in einem üblichen Format, mindestens für die oberste Ebene der Abhängigkeiten des Produkts. Sie dient unter anderem dazu, Schwachstellen in enthaltenen Komponenten zu erkennen und zu dokumentieren. Daraus folgt nicht, dass jede SBOM öffentlich im Internet stehen muss. Hersteller müssen jedoch in der Lage sein, sie aktuell zu halten und zuständigen Marktüberwachungsbehörden im erforderlichen Rahmen bereitzustellen.
Wichtig ist die Unterscheidung zwischen gesetzlichem Minimum und betrieblichem Nutzen. Eine Liste nur der direkten Abhängigkeiten kann eine formale Mindestanforderung unterstützen, reicht für tief verschachtelte Lieferketten aber häufig nicht aus. Wer eine Schwachstelle in einer indirekten Bibliothek schnell finden möchte, braucht möglichst vollständige transitive Beziehungen.
Neue Daten zur Vorbereitung europäischer Unternehmen
Eine ENISA-Erhebung von 2026 zeigt Fortschritt, aber auch Lücken. 78 Prozent der befragten Organisationen hatten ihre SBOM-Einführung bereits begonnen. 44 Prozent befanden sich noch in einer Pilot- oder begrenzten Einführungsphase, 25 Prozent meldeten eine breite Nutzung und nur 9 Prozent einen reifen, vollständig automatisierten Zustand. 79 Prozent erwarteten, bis zur vollständigen CRA-Anwendung den notwendigen Reifegrad zu erreichen.
Bei den Formaten lag CycloneDX in dieser Erhebung mit 44 Prozent vor SPDX mit 29 Prozent. Als Nutzen nannten Organisationen unter anderem Risikoreduktion und vermiedene Kosten, betriebliche Effizienz sowie Vorteile bei Verträgen und Ausschreibungen. Die Zahlen zeigen: SBOMs sind nicht mehr nur ein Nischenthema für besonders regulierte Branchen, die Umsetzung ist aber vielerorts noch nicht im Regelbetrieb angekommen.
Bei kleinen und mittleren Unternehmen ist die Lücke besonders sichtbar. In einer weiteren ENISA-Befragung nutzten 35 Prozent bereits SBOMs, während 24 Prozent Threat Modeling einsetzten. Dokumentation, Konformitätsbewertung, Ressourcen und praktische Umsetzung gehörten zu den größten Herausforderungen. Gerade für kleinere Hersteller ist deshalb ein automatisierter, schrittweiser Ansatz wichtiger als ein umfangreiches Spezialprojekt.
Was die neuen Mindestanforderungen 2026 verändern
Auch außerhalb Europas entwickeln Behörden die Anforderungen weiter. Die US-amerikanische CISA hat ihre Mindestbestandteile für SBOMs 2026 aktualisiert. Gegenüber frühen Baselines rücken nicht nur Namen und Versionen, sondern auch belastbare Identifikation, Hashwerte, Beziehungen, Vollständigkeit und Aktualisierungsfrequenz stärker in den Mittelpunkt. Das ist eine logische Entwicklung: Eine Datei kann syntaktisch korrekt sein und trotzdem kaum für Sicherheitsentscheidungen taugen.
In der Praxis lassen sich drei Qualitätsstufen unterscheiden:
- Vorhanden: Für ein Produkt existiert irgendeine SBOM.
- Verwertbar: Komponenten sind eindeutig bezeichnet, Beziehungen nachvollziehbar und Daten maschinenlesbar.
- Betriebsfähig: Die SBOM entsteht automatisch pro Release, wird fortlaufend ausgewertet und ist mit Reaktionsprozessen verbunden.
Viele Organisationen haben die erste Stufe erreicht. Der eigentliche Sicherheitsgewinn entsteht erst auf der dritten. Eine SBOM, die niemand überwacht, ist ein Archivdokument. Eine aktuelle SBOM, die bei einer neuen Meldung automatisch einen verantwortlichen Prozess auslöst, wird Teil des Vulnerability Managements.
Die häufigsten Fehler bei der Einführung
1. Eine SBOM nur einmal erzeugen
Software ändert sich mit jedem Release. Wird die Stückliste nur für ein Audit erstellt, veraltet sie sofort. Sie sollte reproduzierbar aus dem Build-Prozess entstehen und eindeutig mit Version, Commit, Artefakt und Zeitpunkt verbunden sein.
2. Nur direkte Abhängigkeiten erfassen
Die größte Überraschung steckt häufig in Unterabhängigkeiten. Ein Paket kann eine Bibliothek über mehrere Stufen einziehen. Eine reine Top-Level-Liste erfüllt daher nicht denselben Zweck wie ein vollständiger Abhängigkeitsgraph.
3. Entwicklungs- und Produktionsumgebung vermischen
Testwerkzeuge und Build-Pakete müssen anders bewertet werden als Komponenten, die tatsächlich im ausgelieferten Produkt laufen. Gleichzeitig können auch Build-Werkzeuge die Lieferkette gefährden. Die SBOM sollte den Lebenszyklus und den betrachteten Artefakttyp klar benennen.
4. Schlechte Kennungen akzeptieren
Unklare Namen ohne Version, Anbieter oder Paketkennung lassen sich kaum zuverlässig abgleichen. Qualitätsprüfungen sollten fehlende purl-, CPE-, Hash- und Beziehungsdaten sichtbar machen, statt eine formal gültige Datei automatisch als vollständig zu behandeln.
5. Jede CVE als akuten Vorfall behandeln
Der erste Treffer ist ein Signal für Prüfung, nicht automatisch ein Beweis für Ausnutzbarkeit. Ohne Priorisierung entstehen Alarmmüdigkeit und unnötige Arbeit. VEX, Erreichbarkeitsanalysen, Exploitinformationen und der Kontext des Produkts helfen, die Reihenfolge sinnvoll festzulegen.
6. Die SBOM unkontrolliert veröffentlichen
Transparenz bedeutet nicht, jedes Detail frei zugänglich zu machen. Eine Stückliste kann Angreifern die Recherche erleichtern oder vertrauliche Produktinformationen enthalten. Unternehmen brauchen Regeln dafür, welche Kunden, Partner und Behörden welche Daten erhalten. Zugriffsschutz, Integrität und Aktualität gehören zur Verteilung ebenso wie das Dateiformat.
Ein realistischer Einführungsplan für Unternehmen
Die Einführung muss nicht mit allen Produkten und jeder denkbaren Metadatenklasse beginnen. Ein begrenzter Pilot zeigt schnell, wo Daten fehlen und welche Werkzeuge zur vorhandenen Entwicklungsumgebung passen.
Schritt 1: Produkt und Verantwortliche festlegen
Ein repräsentatives Produkt eignet sich besser als ein künstlich kleines Testprojekt. Entwicklung, Product Security, Einkauf, Recht und Betrieb sollten wissen, wer die SBOM erzeugt, prüft, freigibt und bei einer Warnung reagiert.
Schritt 2: Ausgabeformat und Qualitätsprofil definieren
Das Team entscheidet sich zunächst für eine unterstützte SPDX- oder CycloneDX-Version. Zusätzlich werden Pflichtfelder definiert: eindeutige Produktkennung, Paketversionen, Hersteller, purl oder CPE, Hashwerte, Lizenzen und Abhängigkeitsbeziehungen. Auch erlaubte Ausnahmen müssen dokumentiert werden.
Schritt 3: Erzeugung in den Build integrieren
Der Generator läuft bei jedem Release. Die SBOM wird zusammen mit dem Artefakt versioniert, validiert und möglichst signiert. Ein fehlgeschlagener Qualitätscheck sollte wie ein fehlgeschlagener Test behandelt werden können, zumindest bei produktiven Releases.
Schritt 4: Konsumieren statt nur produzieren
Das Unternehmen importiert die SBOM in ein System, das Schwachstelleninformationen regelmäßig aktualisiert. Für kritische Treffer werden Zuständigkeit, Reaktionszeit, technische Analyse und Eskalation festgelegt. Die im Digital-Wochenrückblick KW 37 beschriebenen neuen CRA-Meldepflichten zeigen, warum diese Verbindung aus Daten und Prozess zeitkritisch wird.
Schritt 5: Lieferanten einbeziehen
Beschaffungsverträge sollten nicht nur „eine SBOM“ verlangen. Sinnvoll sind Angaben zu Formatversion, Aktualisierung, Übermittlung, Tiefe der Abhängigkeiten, Fehlerkorrekturen und VEX-Unterstützung. Eingehende Dateien müssen automatisiert validiert werden. Vertrauen in den Lieferanten ersetzt keine technische Qualitätsprüfung.
Schritt 6: Üben
Ein Planspiel mit einer fiktiven kritischen Schwachstelle zeigt, ob das System funktioniert. Kann das Team innerhalb weniger Stunden alle betroffenen Produkte und Versionen nennen? Ist bekannt, welche Kunden informiert werden müssten? Lässt sich eine begründete Nichtbetroffenheit dokumentieren? Solche Übungen decken Lücken auf, bevor eine reale Meldung unter Zeitdruck eintrifft.
SBOMs für Container, Cloud-Dienste und Geräte
Bei klassischen Desktop-Programmen lässt sich eine Stückliste relativ klar einem Installer zuordnen. Moderne Architekturen sind dynamischer. Container werden aus Basisimages und zusätzlichen Paketen zusammengesetzt. Microservices werden unabhängig veröffentlicht. Verwaltete Cloud-Dienste ändern sich, ohne dass Kunden einen neuen Download erhalten. Ein vernetztes Gerät kombiniert Firmware, Betriebssystem, Funkmodule, App und Backend.
Deshalb entstehen unterschiedliche Sichten:
- eine Build-SBOM für den Zustand während der Erstellung
- eine Release-SBOM für das ausgelieferte Artefakt
- eine Deployment-SBOM für die tatsächlich installierte Kombination
- eine Runtime-Sicht für geladene Komponenten und aktive Dienste
Nicht jedes Unternehmen braucht sofort alle vier. Entscheidend ist, dass Empfänger wissen, welchen Zustand die Datei beschreibt. Bei Containern sollte die SBOM zum unveränderlichen Image-Digest gehören, nicht nur zu einem Tag wie „latest“. Bei Geräten muss sie mit Modell, Hardware-Revision und Firmware-Version verbunden sein. Bei SaaS-Angeboten können ergänzende Service-Stücklisten beschreiben, welche externen Dienste und Datenflüsse beteiligt sind.
Von SBOM zu CBOM und AI-BOM
Das Grundprinzip der Stückliste breitet sich auf weitere Bereiche aus. Eine Cryptography Bill of Materials, kurz CBOM, erfasst verwendete Algorithmen, Schlüsseltypen, Protokolle und Zertifikate. Das wird mit Blick auf die Migration zu quantensicheren Verfahren relevant: Wer nicht weiß, wo eine bestimmte Kryptografie eingesetzt wird, kann sie später kaum systematisch ersetzen.
Für KI-Systeme entstehen AI- oder ML-BOMs. Sie können Modelle, Datensätze, Bibliotheken, Herkunft, Lizenzen und technische Beziehungen dokumentieren. Das ist anspruchsvoller als bei klassischen Paketen, weil ein Modell nicht nur aus Code besteht. Gewichte, Trainings- und Evaluationsdaten, externe APIs und Laufzeitkomponenten beeinflussen sein Verhalten. Die 2026 veröffentlichte CISA-Leitlinie zu Mindestbestandteilen einer KI-SBOM zeigt, dass sich Lieferkettentransparenz zunehmend auch auf KI erstreckt.
Besonders bei KI-Agenten wird diese erweiterte Sicht wichtig. Ein Agent besteht aus Sprachmodell, Werkzeugen, Konnektoren, Speicher, Systemanweisungen und Ausführungsumgebung. Eine klassische Paketliste bildet nur einen Teil dieser Abhängigkeiten ab. Künftige Transparenzformate müssen technische Komponenten und externe Dienste gemeinsam beschreiben können.
Wird eine SBOM selbst zum Sicherheitsrisiko?
Die Sorge ist nicht völlig unbegründet. Eine detaillierte Komponentenliste kann Hinweise auf veraltete Bibliotheken oder interne Architektur geben. Daraus folgt jedoch nicht, dass Intransparenz sicherer ist. Angreifer untersuchen Binärdateien, Container und öffentliche Pakete ohnehin. Der entscheidende Punkt ist kontrollierte Verteilung.
Unternehmen können verschiedene Zugriffsstufen verwenden. Öffentliche Open-Source-Produkte stellen SBOMs möglicherweise frei bereit. Geschäftskunden erhalten sie über ein Kundenportal oder eine standardisierte Schnittstelle. Besonders sensible Informationen werden nur auf berechtigte Anfrage oder an Behörden übermittelt. Digitale Signaturen und Prüfsummen helfen Empfängern, Herkunft und Unverändertheit zu prüfen.
Auch die SBOM-Infrastruktur selbst braucht Schutz. Ein manipuliertes Inventar kann Komponenten verschleiern oder falsche Sicherheit erzeugen. Generatoren, Build-Pipelines, Signaturschlüssel und Speicherorte gehören deshalb in das Sicherheitsmodell. Die Entwicklung von Passwörtern zu kryptografisch gebundenen Identitäten, wie sie unser Überblick zur Geschichte digitaler Sicherheit beschreibt, zeigt denselben Grundgedanken: Vertrauen braucht überprüfbare technische Nachweise.
Welche Kennzahlen wirklich sinnvoll sind
Die bloße Zahl erzeugter SBOM-Dateien sagt wenig aus. Hilfreicher sind Kennzahlen, die Vollständigkeit und Reaktionsfähigkeit messen:
- Anteil produktiver Releases mit automatisch erzeugter und validierter SBOM
- Anteil eindeutig identifizierter Komponenten
- Anteil der Komponenten mit vollständigen Abhängigkeitsbeziehungen
- Zeit von einer neuen Schwachstellenmeldung bis zur Betroffenheitsanalyse
- Anteil der Lieferanten mit verwertbarer SBOM
- Alter der zuletzt bereitgestellten Stückliste pro Produktversion
- Anteil kritischer Treffer mit dokumentierter VEX-Bewertung
Diese Werte lenken den Blick vom Dokument zum Prozess. Das Ziel lautet nicht, möglichst viele JSON-Dateien zu sammeln. Das Ziel ist, innerhalb kurzer Zeit eine belastbare Entscheidung treffen zu können.
Fazit: Transparenz wird zur Infrastruktur
Eine Software Bill of Materials ist weder ein Sicherheitszertifikat noch eine vollständige Lösung für Lieferkettenrisiken. Sie ist die technische Grundlage, auf der viele weitere Prozesse aufbauen: Schwachstellenmanagement, Lizenzprüfung, Lieferantenbewertung, Kundeninformation und regulatorische Dokumentation.
Der entscheidende Wandel 2026 besteht darin, dass SBOMs vom freiwilligen Spezialwerkzeug zur regulären Produkteigenschaft werden. Der Cyber Resilience Act erhöht in Europa den Handlungsdruck, während Standards wie SPDX und CycloneDX die technische Umsetzung reifer machen. Gleichzeitig zeigen aktuelle Erhebungen, dass viele Organisationen noch zwischen Pilot und automatisiertem Betrieb stehen.
Unternehmen sollten deshalb nicht bis Ende 2027 warten. Ein sinnvoller Einstieg ist klein, aber produktionsnah: ein echtes Produkt, ein standardisiertes Format, automatisierte Erzeugung pro Release und ein geübter Prozess für neue Schwachstellen. Erst wenn eine Komponentenliste aktuell, eindeutig und mit Entscheidungen verbunden ist, wird aus ihr mehr als Dokumentation. Dann wird sie zu einer Landkarte der digitalen Lieferkette – und zu einem Werkzeug, das im Ernstfall wertvolle Zeit spart.
