SBOM erstellen:
Software-Stückliste
für CI/CD & CRA.

Was Kunden
wirklich fragen.

Q.01

Was ist eine SBOM?

Eine SBOM (Software Bill of Materials), auf Deutsch Software-Stückliste, ist ein maschinenlesbares Inventar aller Softwarekomponenten eines Produkts — inklusive Abhängigkeiten, Versionen, Lizenzen, Herkunft und kryptografischer Prüfsummen. Vergleichbar mit einer Stückliste in der Fertigung listet die SBOM alle Bausteine auf, aus denen eine Software besteht.

Q.02

Was muss in einer SBOM stehen?

In eine SBOM gehören pro Komponente mindestens: Name, Version, Supplier (Hersteller oder Herkunft), eine eindeutige Kennung als Package URL (purl), die Lizenz und ein kryptografischer Hash — dazu die Abhängigkeitsbeziehungen zwischen den Komponenten. Diese Pflichtfelder definiert die BSI TR-03183-2 für den DACH-Raum, die NTIA Minimum Elements verlangen international denselben Kern. Der Cyber Resilience Act fordert als Mindestumfang die obersten Abhängigkeitsebenen; für eine belastbare Betroffenheitsanalyse sollten Sie transitive Abhängigkeiten mit aufnehmen.

Q.03

Wie erstelle ich eine SBOM?

Eine SBOM erstellen Sie in drei Schritten: (1) Build-Artefakt erzeugen, (2) ein SBOM-Tool wie Syft, Trivy oder cdxgen gegen das Container-Image oder den Quellcode ausführen, (3) das Ergebnis als SPDX- oder CycloneDX-Datei speichern und archivieren. In der CI/CD-Pipeline läuft das nach jedem Build automatisch — etwa mit syft myapp:latest -o cyclonedx-json > sbom.json.

Q.04

Wie sieht eine SBOM aus?

Eine SBOM ist eine JSON- oder XML-Datei, keine Tabelle für Menschen: ein Kopfteil mit Format und Version, darunter eine Liste von Komponenten-Objekten. Eine Komponente im CycloneDX-Beispiel trägt die Felder type, name, version, purl, licenses und hashes — etwa "purl": "pkg:npm/express@4.18.2" mit der Lizenz MIT und einem SHA-256-Hash. In SPDX heißen dieselben Angaben name, versionInfo, supplier, licenseConcluded und checksums. Vollständige SBOM-Beispiele in beiden Formaten zeigt dieser Artikel im Abschnitt „Was enthält eine SBOM".

Q.05

Ist SBOM Pflicht?

Ja. Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen in Anhang I zu einer maschinenlesbaren Software-Stückliste, die mindestens die obersten Abhängigkeitsebenen abdeckt. Verbindlich wird diese Pflicht mit der vollen Geltung des CRA am 11. Dezember 2027 — nicht bereits am 11. September 2026; dieses frühere Datum betrifft ausschließlich die Meldepflichten für aktiv ausgenutzte Schwachstellen. Bußgelder bei Verstößen: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, dazu der Verlust der CE-Kennzeichnung.

Q.06

Für wen gilt der Cyber Resilience Act?

Der CRA gilt für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die in der EU auf den Markt gebracht werden — von der vernetzten Maschine über die Steuerungs-Firmware bis zur reinen Software. Entscheidend ist nicht die Unternehmensgröße, sondern das Produkt: Wer eine CE-Kennzeichnung braucht, braucht künftig auch den CRA-Nachweis. Ausgenommen sind unter anderem Produkte, die bereits sektorspezifisch reguliert sind (etwa Medizinprodukte, Kraftfahrzeuge, Luftfahrt), sowie nicht-kommerziell bereitgestellte Open-Source-Software.

Q.07

Ab wann gilt die CRA-Meldepflicht für Schwachstellen?

Ab dem 11. September 2026. Hersteller müssen eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall binnen 24 Stunden als Frühwarnung an die ENISA und das zuständige nationale CSIRT melden, binnen 72 Stunden folgt der Detailbericht. Die übrigen Hersteller-Pflichten inklusive Software-Stückliste greifen erst ab dem 11. Dezember 2027. Ohne aktuelle SBOM ist die 24-Stunden-Frist praktisch kaum zu halten — die Betroffenheitsanalyse bleibt dann Handarbeit.

Q.08

Wer braucht eine SBOM?

Eine SBOM braucht jeder, der Software oder Produkte mit digitalen Elementen ausliefert — Maschinen- und Anlagenbauer, Embedded- und Firmware-Hersteller, Softwareanbieter. Im Unternehmen arbeiten drei Gruppen damit: die Entwicklung (Abhängigkeiten und Lizenzen im Blick behalten), die Security (Betroffenheit bei neuen CVEs bewerten) und die Compliance (Nachweis gegenüber Marktaufsicht und Kunden). In der Praxis kommt die Anforderung heute meist früher vom OEM im Liefervertrag als vom Gesetzgeber.

Q.09

Muss ich meine SBOM veröffentlichen?

Nein. Der Cyber Resilience Act fordert weder eine Veröffentlichung noch eine Herausgabe an Endkunden. Die SBOM muss Teil der technischen Dokumentation sein und der Marktüberwachungsbehörde auf begründetes Verlangen vorgelegt werden. Unabhängig davon fordern OEMs und öffentliche Auftraggeber SBOMs zunehmend vertraglich ein — üblicherweise unter NDA und in maschinenlesbarem Format.

Q.10

Welches SBOM-Format sollte ich verwenden?

Die zwei etablierten Formate sind SPDX (Linux Foundation, ISO/IEC 5962:2021) und CycloneDX (OWASP). SPDX ist stärker bei Lizenz-Compliance, CycloneDX bei Security und Vulnerability-Tracking mit nativer VEX-Unterstützung. Für den Cyber Resilience Act werden beide akzeptiert. Die BSI TR-03183-2 fordert mindestens CycloneDX 1.6 oder SPDX 3.0.1.

Q.11

Welches SBOM-Tool ist das beste?

Es gibt kein universell bestes Tool. Syft ist der vielseitigste SBOM-Generator, Trivy kombiniert SBOM-Erzeugung mit Vulnerability-Scanning, cdxgen unterstützt die meisten Programmiersprachen und das Microsoft SBOM Tool eignet sich besonders für Azure-DevOps-Umgebungen. Alle sind Open Source und produktionsreif.

Q.12

Wie erstelle ich eine SBOM mit Trivy?

Trivy erzeugt eine SBOM mit einem einzigen Befehl: trivy image --format cyclonedx -o sbom.cdx.json myapp:latest. Damit scannt Trivy ein Container-Image, Git-Repository oder Dateisystem und schreibt das Komponenten-Inventar im CycloneDX-Format. Eine bestehende SBOM prüfen Sie anschließend mit trivy sbom sbom.cdx.json gegen bekannte CVEs — so kombiniert Trivy SBOM-Generierung und Vulnerability-Scan in einem Tool.

Q.13

Wie erstelle ich eine SBOM mit Syft?

Syft (Anchore) ist das vielseitigste SBOM-Tool. Sie erzeugen eine SBOM mit syft myapp:latest -o cyclonedx-json > sbom.json — Syft analysiert Container-Images, Dateisysteme und Archive und gibt wahlweise SPDX oder CycloneDX aus. In Kombination mit dem Scanner Grype lassen sich die erkannten Komponenten anschließend direkt auf Schwachstellen prüfen.

Q.14

Kann ich eine SBOM direkt aus GitHub oder GitLab erzeugen?

Ja. GitHub erzeugt aus dem Dependency Graph über die Weboberfläche oder die gh-sbom-CLI eine SPDX-2.3-Datei, GitLab liefert mit dem Dependency Scanning einen CycloneDX-Report als Job-Artefakt. Für einen ersten Überblick genügt das. Für CRA- und BSI-TR-03183-2-Konformität sind diese Exporte meist zu dünn: Sie beschreiben die deklarierten Abhängigkeiten des Repositories, nicht das tatsächlich ausgelieferte Artefakt. Wer Container ausliefert, erzeugt die SBOM besser mit Syft oder Trivy gegen das gebaute Image.

Q.15

Wie integriere ich SBOM in meine CI/CD-Pipeline?

SBOM-Generierung wird als Pipeline-Schritt nach dem Build integriert. Tools wie Syft, Trivy oder cdxgen erzeugen automatisch eine SBOM aus Container-Images oder Quellcode. Die SBOM wird anschließend als Artefakt archiviert und kann mit Dependency-Track oder Grype automatisiert auf Schwachstellen und Lizenz-Konformität geprüft werden.

Q.16

Was fordert die BSI TR-03183-2 für SBOMs?

Die BSI TR-03183-2 (Version 2.1.0, Februar 2026) definiert Qualitätsanforderungen an SBOMs im DACH-Raum. Pflichtfelder sind Komponentenname, Version, Supplier, Package URL (purl), Lizenz und kryptografischer Hash. Die Richtlinie unterscheidet vier Tiefenstufen — n-Level, Transitiv, Liefergegenstand und Vollständig — und fordert mindestens CycloneDX 1.6 oder SPDX 3.0.1.

Q.17

Welche SBOM-Tiefenstufen gibt es?

Die BSI TR-03183-2 definiert vier Tiefenstufen: (1) n-Level — nur direkte Abhängigkeiten, (2) Transitiv — alle Abhängigkeiten inklusive transitiver, (3) Liefergegenstand — nur die tatsächlich ausgelieferten Komponenten, (4) Vollständig — alle Komponenten inklusive Build- und Entwicklungsabhängigkeiten. Für CRA-Compliance wird mindestens die Stufe Liefergegenstand empfohlen.

Q.18

Was ist VEX und wie hängt es mit SBOM zusammen?

VEX (Vulnerability Exploitability Exchange) ergänzt die SBOM um eine Bewertung der tatsächlichen Ausnutzbarkeit von Schwachstellen. Während eine SBOM alle Komponenten listet und ein Vulnerability-Scan alle bekannten CVEs meldet, bewertet VEX mit vier Status (Not Affected, Affected, Fixed, Under Investigation), ob eine Schwachstelle im konkreten Produkt ausnutzbar ist. In der Praxis reduziert das die relevanten Findings oft um 90 %.

Q.19

Kann ich SBOMs für Embedded-Software erstellen?

Ja, aber mit Einschränkungen. Standard-Tools funktionieren am besten bei Quellcode-Analyse während des Builds. Für Embedded-Systeme mit Yocto oder Buildroot gibt es native SBOM-Generierung (bitbake -c create_spdx bzw. legal-info). Bei proprietären Toolchains wie CODESYS oder TIA Portal sind eigene Extraktoren oder manuelle Ergänzungen notwendig.

Q.20

Wie oft sollte eine SBOM aktualisiert werden?

Idealerweise bei jedem Build automatisch. Wenn die SBOM-Generierung in die CI/CD-Pipeline integriert ist, erhalten Sie bei jedem Release eine aktuelle SBOM ohne zusätzlichen Aufwand. Für bereits ausgelieferte Produkte sollte die SBOM mindestens bei jedem Security-Update aktualisiert werden.

Q.21

Was kostet die Einführung von SBOM?

Die Tools sind Open Source und kostenlos. Der Hauptaufwand liegt in der initialen Integration in die CI/CD-Pipeline (typischerweise 1–3 Tage pro Pipeline) sowie in der Definition von Policies für Lizenz-Compliance und Vulnerability-Schwellwerte.

Q.22

Was kostet eine SBOM-Nicht-Compliance?

Der EU Cyber Resilience Act sieht Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor. Hinzu kommt der Verlust der CE-Kennzeichnung — ohne CE darf das Produkt nicht auf dem EU-Markt vertrieben werden. Die erste Frist, die Meldepflicht, gilt bereits ab September 2026.

Q.23

Was ist der Unterschied zwischen SBOM und SCA?

SCA (Software Composition Analysis) ist der Analyseprozess zur Identifikation von Open-Source-Komponenten. Die SBOM ist das Ergebnis — das dokumentierte, standardisierte Inventar. SCA-Tools wie Snyk oder Black Duck führen die Analyse durch und können SBOMs als Output erzeugen; SBOM-Tools wie Syft oder Trivy fokussieren sich auf die standardisierte Inventarerstellung in SPDX oder CycloneDX.

// Ihr nächster Schritt1 Klick, anonym

Wie geht es bei Ihnen mit die SBOM-Pflicht weiter?

Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.

Konkret umsetzenOptionen bewertenErst mal beobachten