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.
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 (Software Bill of Materials) ist das Software-Pendant zur Stückliste in der Fertigung: ein vollständiges, maschinenlesbares Verzeichnis aller Komponenten, aus denen ein Softwareprodukt besteht — direkte und transitive Abhängigkeiten, Versionen, Lizenzen und idealerweise Herkunftsangaben. Die etablierten Formate sind SPDX und CycloneDX, die beide von gängigen Werkzeugen erzeugt und gelesen werden können.
Der praktische Nutzen zeigt sich vor allem im Schwachstellenmanagement. Wird eine neue kritische Lücke in einer weit verbreiteten Bibliothek bekannt, lässt sich anhand der SBOMs in Minuten beantworten, welche Produkte und Releases betroffen sind — statt tagelang Code zu durchforsten. Wer das Log4Shell-Wochenende miterlebt hat, kennt den Unterschied: Teams greppen tagelang Build-Verzeichnisse und Archive nach einer einzigen Bibliothek, während stündlich jemand nach dem Stand fragt. Mit gepflegten SBOMs wäre derselbe Abgleich eine Abfrage von Minuten gewesen.
Für Industrieunternehmen wird die SBOM zur regulatorischen Pflicht: Der EU Cyber Resilience Act verlangt mit seiner vollen Geltung ab dem 11. Dezember 2027 von Herstellern digitaler Produkte eine SBOM und ein dokumentiertes Schwachstellenmanagement über den Lebenszyklus. Auch IEC 62443 und Branchenstandards bewegen sich in dieselbe Richtung. Eine in die CI/CD-Pipeline integrierte, automatische SBOM-Generierung stellt sicher, dass jedes Release reproduzierbar eine aktuelle Stückliste mitführt.
Typische Stolpersteine: SBOMs werden einmalig manuell erstellt und veralten sofort, weil sie nicht an den Build gekoppelt sind. Oder sie erfassen nur direkte Abhängigkeiten und übersehen den tieferen, transitiven Anteil, der oft den Großteil ausmacht. Wertvoll wird eine SBOM erst, wenn sie automatisch, vollständig und versioniert zu jedem Artefakt entsteht und mit einer Schwachstellen-Datenquelle abgeglichen wird.
Automatische Betroffenheitsanalyse bei neuer CVE
Als eine kritische Schwachstelle in einer verbreiteten Bibliothek bekannt wird, gleicht ein Maschinenbauer seine archivierten SBOMs gegen die CVE ab und identifiziert binnen Stunden die betroffenen Firmware-Versionen — statt manuell jedes ausgelieferte Produkt zu prüfen.
SBOM-Artefakt als CRA-Nachweis
Ein Hersteller koppelt die SBOM-Generierung an seinen Build, sodass jedes signierte Release-Artefakt eine CycloneDX-Datei mitführt. Diese dient zugleich als Konformitätsnachweis für den Cyber Resilience Act, dessen Hauptpflichten ab dem 11. Dezember 2027 vollständig gelten.
- Was ist der Unterschied zwischen SPDX und CycloneDX?
- Beides sind standardisierte SBOM-Formate. SPDX hat seinen Ursprung im Lizenz-Compliance-Umfeld und ist ein ISO-Standard, CycloneDX kommt aus dem Security-Kontext der OWASP und legt einen Schwerpunkt auf Schwachstellen- und Risikoangaben. In der Praxis werden beide von gängigen Tools unterstützt; die Wahl richtet sich nach Anforderung und Toolchain.
- Reicht es, die SBOM einmal pro Produkt zu erstellen?
- Nein. Eine SBOM ist nur so aktuell wie der Build, zu dem sie gehört. Jede Änderung an Abhängigkeiten erzeugt eine neue, abweichende Stückliste. Deshalb sollte die SBOM-Generierung Teil jeder Pipeline sein und pro Release-Artefakt versioniert archiviert werden.
- Muss ich meine SBOM veröffentlichen?
- Der Cyber Resilience Act verlangt, dass die SBOM erstellt und Behörden auf Anfrage zugänglich gemacht wird — eine generelle öffentliche Veröffentlichung ist nicht zwingend vorgeschrieben. Viele Hersteller stellen sie ihren Kunden gezielt bereit, etwa für deren eigenes Schwachstellenmanagement.
- Wie erstellt man eine SBOM?
- Am verlässlichsten automatisiert im Build: Werkzeuge analysieren das Projekt oder das fertige Container-Image und erzeugen daraus eine Stückliste im Format SPDX oder CycloneDX. In die CI/CD-Pipeline integriert, entsteht so zu jedem Release-Artefakt reproduzierbar eine aktuelle SBOM, die sich anschließend gegen Schwachstellen-Datenbanken abgleichen lässt — manuelle Einmal-Erstellung veraltet dagegen sofort.
- Ab wann ist eine SBOM Pflicht?
- Für Produkte mit digitalen Elementen auf dem EU-Markt macht der Cyber Resilience Act die SBOM mit seiner vollen Geltung ab dem 11. Dezember 2027 verpflichtend; die Meldepflichten für ausgenutzte Schwachstellen greifen bereits ab dem 11. September 2026. Faktisch greift die Pflicht oft früher: Der nächste OEM-Lieferantenfragebogen verlangt die SBOM heute schon, nicht erst der Stichtag 2027 — wer erst kurz vor dem Termin anfängt, beantwortet solche 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.
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