Was ist eine SBOM (Software Bill of Materials)?
Eine SBOM (englisch Software Bill of Materials, deutsch Software-Stückliste) ist ein maschinenlesbares Inventar aller Softwarekomponenten, Bibliotheken, Versionen und Lizenzen eines Produkts. Die zwei etablierten Formate sind SPDX (Linux Foundation) und CycloneDX (OWASP). Wie Sie eine SBOM in der CI/CD-Pipeline erzeugen, zeigt die verlinkte Schritt-für-Schritt-Anleitung.
Auch bekannt als: SBOM · Software Bill of Materials · Software-Stückliste
Ist SBOM (Software Bill of Materials) bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Eine SBOM entsteht, indem ein Werkzeug das Projekt oder das fertige Artefakt untersucht und jede gefundene Komponente als Eintrag ablegt. Pro Eintrag stehen dort mindestens Name, Version und Lieferant, dazu meist die Lizenz, eine eindeutige Kennung wie die Package-URL und ein Hash, der die Datei identifiziert. Die Einträge sind miteinander verknüpft. So hält die SBOM fest, welche Bibliothek eine andere nachzieht. Diese transitiven Abhängigkeiten, also die Abhängigkeiten der Abhängigkeiten, machen in typischen Projekten den größten Teil der Liste aus.
SBOM ist nicht gleich Lizenzliste und nicht gleich Schwachstellenbericht. Die Lizenzliste interessiert die Rechtsabteilung, der Schwachstellenbericht das Security-Team. Die SBOM ist die gemeinsame Datengrundlage für beide. Welche der gelisteten Komponenten tatsächlich angreifbar sind, sagt sie selbst nicht. Das ergibt erst der Abgleich mit einer Schwachstellen-Datenbank. Ob eine bekannte Lücke im konkreten Produkt ausnutzbar ist, beschreibt ein ergänzendes Dokument, der VEX (Vulnerability Exploitability eXchange).
Den Nutzen spürt man, sobald eine kritische Lücke in einer verbreiteten Bibliothek bekannt wird. Wer im Dezember 2021 Log4Shell miterlebt hat, erinnert sich an Teams, die tagelang Build-Verzeichnisse und Archive nach einer einzigen Java-Bibliothek durchsuchten, während stündlich jemand aus der Geschäftsführung nach dem Stand fragte. Mit gepflegten SBOMs ist derselbe Abgleich eine Abfrage über alle Releases, und die Antwort steht nach Minuten fest.
Für Hersteller in der EU wird die SBOM zur Pflicht. Der Cyber Resilience Act verlangt sie ab seiner vollen Geltung am 11. Dezember 2027 für Produkte mit digitalen Elementen, als maschinenlesbare Liste, die mindestens die obersten Abhängigkeitsebenen abdeckt. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten schon seit dem 11. September 2026, und ohne SBOM lässt sich kaum belegen, welches Produkt eine gemeldete Lücke betrifft.
Eine SBOM veraltet in dem Moment, in dem jemand eine Abhängigkeit aktualisiert. Deshalb scheitern einmalig von Hand erstellte Listen. Brauchbar ist nur die SBOM, die zu jedem Build neu entsteht, zum Artefakt archiviert wird und auch die transitiven Komponenten erfasst.
Neue CVE am Montagmorgen, Antwort vor der Mittagspause
Ein Maschinenbauer erfährt von einer kritischen Schwachstelle in einer verbreiteten Kompressionsbibliothek. Früher hätte ein Team jede ausgelieferte Firmware-Version einzeln geprüft. Heute gleicht er seine archivierten SBOMs gegen die CVE ab und hat binnen Stunden die Liste der betroffenen Firmware-Stände, die an den Service geht.
Kundenfragebogen mit SBOM-Anforderung
Ein OEM verlangt im Lieferantenfragebogen zu jedem Steuergerät eine SBOM im Format CycloneDX. Der Zulieferer hatte bisher nur eine Lizenzliste in Excel. Seit jedes signierte Release-Artefakt eine CycloneDX-Datei mitführt, beantwortet er die Anfrage mit einem Download, und dieselbe Datei dient später als Nachweis für den Cyber Resilience Act.
Welches SBOM-Format passt zu Ihrem Ziel?
CycloneDX und SPDX können beide viel — welches Format passt, entscheidet Ihr primäres Ziel. Zwei Klicks zeigen Ihnen die Empfehlung für Ihren Anwendungsfall.
Wofür brauchen Sie die SBOM primär?
- Was ist der Unterschied zwischen SPDX und CycloneDX?
- Beides sind standardisierte SBOM-Formate mit unterschiedlicher Herkunft. SPDX stammt aus dem Lizenz-Compliance-Umfeld der Linux Foundation und ist als ISO/IEC 5962 genormt. CycloneDX kommt aus dem Security-Umfeld der OWASP, legt den Schwerpunkt auf Schwachstellen- und Risikoangaben und ist seit 2024 als ECMA-424 standardisiert. Gängige Werkzeuge erzeugen beide, die Wahl richtet sich meist nach dem, was Kunden und Toolchain verlangen.
- Welche Angaben gehören mindestens in eine SBOM?
- Pro Komponente mindestens Name, Version, Lieferant, eine eindeutige Kennung und die Abhängigkeitsbeziehung zu anderen Komponenten. Dazu kommen Angaben zur SBOM selbst, also wer sie wann erstellt hat. Die BSI-Richtlinie TR-03183-2 konkretisiert die Pflichtfelder für den deutschen Markt, und viele Kunden fordern zusätzlich Lizenz und Hash.
- Reicht es, die SBOM einmal pro Produkt zu erstellen?
- Nein. Eine SBOM ist nur so aktuell wie der Build, zu dem sie gehört, und jede geänderte Abhängigkeit ergibt eine andere Stückliste. Sie gehört deshalb zu jedem Release-Artefakt und wird mit ihm archiviert.
- Muss ich meine SBOM veröffentlichen?
- Nein, eine öffentliche Veröffentlichung schreibt der Cyber Resilience Act nicht vor. Er verlangt, dass der Hersteller die SBOM erstellt, in seiner technischen Dokumentation führt und der Marktüberwachung auf Verlangen vorlegt. Viele Hersteller geben sie zusätzlich gezielt an Kunden weiter, die sie für ihr eigenes Schwachstellenmanagement brauchen.
- Wie erstellt man eine SBOM?
- Am verlässlichsten automatisiert im Build: Ein Werkzeug analysiert das Projekt oder das fertige Container-Image und erzeugt daraus eine Stückliste im Format SPDX oder CycloneDX. Eine einmal von Hand erstellte Liste veraltet dagegen mit dem nächsten Update.
- Ab wann ist eine SBOM Pflicht?
- Für Produkte mit digitalen Elementen auf dem EU-Markt macht der Cyber Resilience Act die SBOM ab seiner vollen Geltung am 11. Dezember 2027 verpflichtend. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten bereits seit dem 11. September 2026. Im Alltag kommt die Anforderung oft früher, weil der nächste OEM-Lieferantenfragebogen die SBOM schon heute abfragt, und wer bis 2027 wartet, beantwortet diese Fragebögen bis dahin mit Lücken.
Wo steht Ihr Team bei SBOM (Software Bill of Materials)?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu SBOM (Software Bill of Materials): Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01CISASoftware Bill of Materials(externe Seite, öffnet in neuem Tab)
Behördliche Mindestanforderungen und Anwendungsfälle einer SBOM.
- /02Linux FoundationSPDX(externe Seite, öffnet in neuem Tab)
Das ISO-normierte Austauschformat für Komponenten- und Lizenzangaben.
- /03OWASPCycloneDX(externe Seite, öffnet in neuem Tab)
Das zweite verbreitete Format, ausgelegt auf Sicherheits- und Lieferkettenanalysen.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance