SBOM erstellen:
Software-Stückliste
für CI/CD & CRA.
Eine SBOM (Software Bill of Materials) erstellen, Formate vergleichen und automatisiert in Ihre CI/CD-Pipeline integrieren — Schritt für Schritt, mit Code-Beispielen, BSI TR-03183-2, VEX und den richtigen Tools.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
SBOM ist kein
Nice-to-have.
Sie wird Pflicht.
Eine SBOM ist das zentrale Instrument für Software Supply Chain Security. SolarWinds, Log4Shell, xz-utils — diese Vorfälle haben gezeigt: Unternehmen wissen nicht, welche Komponenten in ihrer Software stecken.
75 % aller Unternehmen wurden 2024 Opfer eines Supply-Chain-Angriffs (BlackBerry 2024). Der EU Cyber Resilience Act macht SBOMs ab Dezember 2027 zur Pflicht. Erste Meldepflicht: 11. September 2026.
Die Fertigungs-
Analogie.
In der Fertigung ist die Stückliste seit Jahrzehnten Standard: Jedes Produkt hat ein dokumentiertes Inventar aller Bauteile. Die SBOM überträgt dieses Prinzip auf Software. Genau wie bei einem Rückruf müssen Sie bei einer CVE wissen, welche Ihrer Produkte eine betroffene Bibliothek verwenden.
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"components": [
{
"type": "library",
"name": "express",
"version": "4.18.2",
"purl": "pkg:npm/express@4.18.2",
"licenses": [{ "license": { "id": "MIT" } }],
"hashes": [{
"alg": "SHA-256",
"content": "a1b2c3d4e5f6..."
}]
},
{
"type": "library",
"name": "lodash",
"version": "4.17.21",
"purl": "pkg:npm/lodash@4.17.21",
"licenses": [{ "license": { "id": "MIT" } }]
}
]
}{
"spdxVersion": "SPDX-2.3",
"dataLicense": "CC0-1.0",
"SPDXID": "SPDXRef-DOCUMENT",
"name": "myapp-sbom",
"packages": [
{
"SPDXID": "SPDXRef-Package-express",
"name": "express",
"versionInfo": "4.18.2",
"supplier": "Organization: OpenJS Foundation",
"downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz",
"licenseConcluded": "MIT",
"externalRefs": [{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:npm/express@4.18.2"
}],
"checksums": [{
"algorithm": "SHA256",
"checksumValue": "a1b2c3d4e5f6..."
}]
}
]
}Zwei Formate.
Eine Entscheidung.
Beide werden vom Cyber Resilience Act akzeptiert, unterscheiden sich aber in Fokus und Stärken.
SPDX
- Organisation
- Linux Foundation
- Standard
- ISO/IEC 5962:2021
- — ISO-zertifizierter Standard
- — Stark bei Lizenz-Compliance
- — Breite Tool-Unterstützung
- — Unterstützt RDF, JSON, YAML, Tag-Value
- — Komplexere Spezifikation
- — Weniger fokussiert auf Security-Workflows
Lizenz-Compliance, regulierte Branchen, internationale Standards
CycloneDX
- Organisation
- OWASP Foundation
- Standard
- ECMA-424 (in Arbeit)
- — Nativ für Security-Anwendungsfälle
- — VEX-Unterstützung (Vulnerability Exploitability eXchange)
- — Einfachere Spezifikation
- — JSON und XML
- — Kein ISO-Standard (noch)
- — Lizenz-Abbildung weniger granular als SPDX
Security-Fokus, Vulnerability-Management, DevSecOps-Pipelines
Für die meisten DevSecOps-Pipelines empfehlen wir CycloneDX als primäres Format — nativ auf Security-Workflows ausgelegt, unterstützt VEX-Dokumente. Für strenge Lizenz-Compliance oder ISO-Zertifizierung ist SPDX die bessere Wahl. Viele Tools können beide Formate erzeugen.
Syft. Trivy. cdxgen.
Alle Open Source.
Vier Generatoren plus Dependency-Track als Management-Plattform. Die Wahl hängt von Technologie-Stack und Anforderungen ab.
- /01
Syft
Anchore · Apache 2.0Leistungsstarker SBOM-Generator für Container-Images und Dateisysteme. Erzeugt SBOMs in SPDX und CycloneDX.
- — Container-Images (Docker, OCI)
- — Dateisysteme und Archive
- — SPDX + CycloneDX Output
- — Integration mit Grype (Vulnerability Scanner)
$ syft myapp:latest -o cyclonedx-json > sbom.json - /02
Trivy
Aqua Security · Apache 2.0All-in-One Security-Scanner mit integrierter SBOM-Generierung. Scannt Container, Repos, Filesysteme und Kubernetes.
- — SBOM + Vulnerability Scan in einem Tool
- — Container, Git-Repos, Kubernetes
- — SPDX + CycloneDX Output
- — Direkte Integration in CI/CD
$ trivy image --format cyclonedx -o sbom.json myapp:latest - /03
cdxgen
CycloneDX / AppThreat · Apache 2.0Spezialisierter CycloneDX-Generator mit Unterstützung für über 20 Programmiersprachen und Paketmanager.
- — 20+ Sprachen (Java, .NET, Go, Rust, etc.)
- — Erkennt transitive Abhängigkeiten
- — CycloneDX-nativer Output
- — Quellcode- und Binary-Analyse
$ cdxgen -o sbom.json --type java . - /04
Microsoft SBOM Tool
Microsoft · MITEnterprise-taugliches SBOM-Tool mit Fokus auf SPDX-Konformität und SBOM-Signierung.
- — SPDX 2.2 Output
- — SBOM-Signierung und Validierung
- — Integration in Azure DevOps
- — Enterprise-Support
$ sbom-tool generate -b ./build -bc ./src -pn myapp -pv 1.0 - /05
Dependency-Track
OWASP · Apache 2.0SBOM-Management-Plattform für kontinuierliches Vulnerability-Monitoring. Kein Generator, sondern das zentrale Dashboard für SBOM-Lifecycle-Management.
- — Automatischer CVE-Abgleich nach SBOM-Upload
- — Policy-Engine für Lizenz- und Vulnerability-Schwellwerte
- — VEX-Unterstützung und Audit-Trail
- — REST-API für CI/CD-Integration
$ curl -X POST https://dtrack.example.com/api/v1/bom -F "bom=@sbom.cdx.json"
Der deutsche
SBOM-Standard.
Die BSI TR-03183-2 (Version 2.1.0, Februar 2026) ist die technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik. Sie definiert Pflichtfelder und Tiefenstufen und ist der Referenzstandard für SBOM-Compliance im DACH-Raum.
- 01Komponentenname und Version
- 02Supplier / Hersteller der Komponente
- 03Package URL (purl) als eindeutige Identifikation
- 04Lizenzinformationen (SPDX License Expression)
- 05Kryptografischer Hash (SHA-256 oder stärker)
- 06Abhängigkeitsbeziehungen (direkt und transitiv)
- 1n-Level
Nur direkte Abhängigkeiten
- 2Transitiv
Alle Abhängigkeiten inkl. transitive — empfohlen für Security
- 3Liefergegenstand
Nur tatsächlich ausgelieferte Komponenten — Mindestanforderung CRA
- 4Vollständig
Alle Komponenten inkl. Build- und Entwicklungsabhängigkeiten
Die BSI TR-03183-2 fordert mindestens CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Ältere Format-Versionen erfüllen die Anforderungen nicht vollständig. Der BSI stellt auf GitHub einen CycloneDX-Namespace bereit, der die TR-Datenfelder auf CycloneDX-Properties abbildet.
Von 200 CVEs.
Zu 20 relevanten.
Eine SBOM listet alle Komponenten. Ein Vulnerability-Scan meldet alle bekannten CVEs. Aber: nicht jede gemeldete Schwachstelle ist in Ihrem Produkt tatsächlich ausnutzbar. Hier setzt VEX (Vulnerability Exploitability Exchange) an.
Ohne VEX versinken Teams in False Positives. Mit VEX wird aus der SBOM ein actionable Werkzeug für das Vulnerability-Management.
- Not Affected
Die Schwachstelle existiert in der Komponente, ist aber im konkreten Produkt nicht ausnutzbar (z. B. betroffener Codepfad wird nicht verwendet).
- Affected
Die Schwachstelle ist im Produkt ausnutzbar und erfordert Maßnahmen (Patch, Upgrade, Workaround).
- Fixed
Die Schwachstelle wurde behoben — durch Upgrade, Patch oder Konfigurationsänderung.
- Under Investigation
Die Ausnutzbarkeit wird noch geprüft. Ermöglicht transparente Kommunikation mit Kunden.
- —CycloneDX unterstützt VEX nativ als integriertes Dokument
- —CSAF (Common Security Advisory Framework) ist das europäische Format für Security Advisories mit VEX
- —Trivy unterstützt VEX-Dokumente als Input für gefilterte Vulnerability-Reports
- —Dependency-Track kann VEX-Bewertungen importieren und automatisch anwenden
- —SBOM + VEX + VDR (Vulnerability Disclosure Report) bilden das Dreigespann für CRA-konformes Vulnerability-Management
Manuell skaliert nicht.
Automatisieren.
Der richtige Ansatz: SBOM-Automatisierung als fester Bestandteil Ihrer CI/CD-Pipeline.
- /01
Build-Artefakt erstellen
Ihr regulärer Build-Prozess erzeugt das Artefakt — ein Container-Image, ein Firmware-Binary oder ein Softwarepaket.
- /02
SBOM generieren
Direkt nach dem Build wird die SBOM aus dem Artefakt erzeugt. Das Tool analysiert alle enthaltenen Abhängigkeiten, Versionen und Lizenzen.
- /03
SBOM validieren
Die erzeugte SBOM wird auf Vollständigkeit und Schema-Konformität geprüft. Unbekannte oder nicht-auflösbare Komponenten werden markiert.
- /04
Vulnerability-Check
Die SBOM wird gegen bekannte Schwachstellen-Datenbanken (NVD, OSV, GitHub Advisory) abgeglichen. Kritische CVEs können die Pipeline blockieren.
- /05
Lizenz-Compliance prüfen
Automatische Prüfung aller Lizenzen gegen eine definierte Policy. Inkompatible oder unbekannte Lizenzen lösen ein Quality Gate aus.
- /06
SBOM archivieren und verteilen
Die signierte SBOM wird zusammen mit dem Release-Artefakt archiviert und kann an Kunden oder Regulierungsbehörden weitergegeben werden.
Jenkins.
GitLab CI.
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'docker build -t myapp:$BUILD_NUMBER .'
}
}
stage('Generate SBOM') {
steps {
sh '''
syft myapp:$BUILD_NUMBER \
-o cyclonedx-json \
> sbom-$BUILD_NUMBER.cdx.json
'''
}
}
stage('Vulnerability Scan') {
steps {
sh '''
grype sbom:sbom-$BUILD_NUMBER.cdx.json \
--fail-on critical
'''
}
}
stage('Archive SBOM') {
steps {
archiveArtifacts artifacts: 'sbom-*.cdx.json'
}
}
}
}generate-sbom:
stage: security
image: aquasec/trivy:latest
script:
- trivy image
--format cyclonedx
--output sbom.cdx.json
myapp:$CI_COMMIT_SHORT_SHA
- trivy sbom sbom.cdx.json
--severity CRITICAL,HIGH
--exit-code 1
artifacts:
paths:
- sbom.cdx.json
expire_in: 1 yearOhne SBOM.
Keine CE.
Kein Markt.
Cyber Resilience Act tritt in Kraft (Veröffentlichung im Amtsblatt)
Meldepflicht: 24 h-Frist für ausgenutzte Schwachstellen an ENISA, 72 h für Detailbericht
Vollständige Umsetzungspflicht — keine CE-Kennzeichnung ohne SBOM und Compliance
Ab 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 h an die ENISA melden, binnen 72 h einen Detailbericht nachliefern. Ab 11. Dezember 2027 gilt die vollständige Umsetzungspflicht. Bußgelder bei Nicht-Compliance: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.
Eine detaillierte Analyse finden Sie in unserem Artikel EU Cyber Resilience Act im Maschinenbau.
SPS. Firmware.
Eigene Spielregeln.
Für Web-Apps ist SBOM gut verstanden. Für industrielle Software — SPS-Code, Firmware, Embedded-Systeme mit Yocto oder Buildroot — gibt es spezifische Herausforderungen. Die IEC 62443 und der CRA fordern hier besondere Sorgfalt.
- /01
Proprietäre Toolchains
SPS-Entwicklungsumgebungen wie TIA Portal oder CODESYS haben eigene Paketformate, die von Standard-SBOM-Tools nicht erkannt werden.
AnsatzEigene Extraktoren entwickeln oder auf herstellerspezifische SBOM-Exporte setzen. SPDX erlaubt Custom-Relationship-Types.
- /02
SBOM für Firmware und Embedded-Systeme
Embedded-Systeme verwenden oft statisch gelinkte Bibliotheken, die in der Binary-Analyse schwer identifizierbar sind. Yocto-basierte Linux-Images können hunderte Pakete enthalten.
AnsatzSBOM-Generierung im Build-Prozess (Source-Level) statt Post-Build. Yocto erzeugt SBOMs nativ über das create-spdx-Modul (bitbake -c create_spdx). Buildroot unterstützt SBOM-Export über legal-info. Für Docker-basierte Firmware: Syft kann Container-Images direkt analysieren.
- /03
Langlebige Produkte
Industrielle Anlagen laufen 15–20 Jahre. Die SBOM muss über den gesamten Lebenszyklus aktuell gehalten werden.
AnsatzVersionierte SBOM-Archive mit Lifecycle-Management. Automatisierte Benachrichtigung bei neuen CVEs für alte Versionen.
- /04
Zulieferketten-Transparenz
OT-Systeme bestehen aus Komponenten verschiedener Zulieferer — jeder mit eigener Software-Landschaft.
AnsatzSBOM-Anforderungen vertraglich mit Zulieferern vereinbaren. Hierarchische SBOMs (SBOM of SBOMs) abbilden.
SBOM ist ein Baustein eines umfassenden DevSecOps-Ansatzes für industrielle Umgebungen. Zusammen mit IEC 62443, Policy-as-Code und automatisierten Security-Scans entsteht ein durchgängiges Sicherheitskonzept vom Quellcode bis zum Shopfloor.
Die Tools sind reif.
Fangen Sie jetzt an.
Die Software Bill of Materials wandelt sich vom freiwilligen Best Practice zur regulatorischen Pflicht. Der Cyber Resilience Act setzt klare Fristen, Supply-Chain-Angriffe machen Transparenz zur Notwendigkeit.
Die gute Nachricht: Mit Syft, Trivy oder cdxgen lässt sich die SBOM-Automatisierung in wenigen Stunden in bestehende CI/CD-Pipelines integrieren. SPDX und CycloneDX sind standardisiert, die BSI TR-03183-2 definiert Qualitätsanforderungen und mit VEX werden Ihre SBOMs actionable. Dependency-Track bietet das zentrale Dashboard für das SBOM-Lifecycle-Management.
In 90 Tagen können Sie eine vollständige SBOM-Pipeline für Ihre kritischsten Produkte haben. Beginnen Sie mit einem Pilotprojekt, generieren Sie Ihre erste SBOM automatisiert und bauen Sie von dort aus.
Was Kunden
wirklich fragen.
- Q.01
- Was ist eine SBOM?
- Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Inventar aller Software-Komponenten eines Produkts — inklusive Abhängigkeiten, Versionen und Lizenzen. Vergleichbar mit einer Stückliste in der Fertigung listet die SBOM alle Bausteine auf, aus denen eine Software besteht.
- Q.02
- 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. Für den Cyber Resilience Act werden beide akzeptiert.
- Q.03
- Ist SBOM Pflicht?
- Ja, zunehmend. Der EU Cyber Resilience Act macht SBOM-Dokumentation für Produkte mit digitalen Elementen zur Pflicht. In den USA fordert Executive Order 14028 SBOMs für Regierungsaufträge. Die vollständige Umsetzungspflicht des CRA beginnt im Dezember 2027.
- Q.04
- 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 dann als Artefakt gespeichert und kann automatisiert auf Schwachstellen und Lizenz-Konformität geprüft werden.
- Q.05
- Welches SBOM-Tool ist das beste?
- Es gibt kein universell bestes Tool. Syft ist der vielseitigste SBOM-Generator, Trivy kombiniert SBOM 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.06
- 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. Bei proprietären Toolchains (z. B. TIA Portal) sind oft eigene Extraktoren oder manuelle Ergänzungen notwendig.
- Q.07
- 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.08
- 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 der Definition von Policies für Lizenz-Compliance und Vulnerability-Schwellwerte.
- Q.09
- 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 umfassen Komponentenname, Version, Supplier, Package URL (purl), Lizenz und kryptografischen Hash. Die Richtlinie unterscheidet vier Tiefenstufen und fordert mindestens CycloneDX 1.6 oder SPDX 3.0.1.
- Q.10
- 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 ein Vulnerability-Scan alle bekannten CVEs meldet, bewertet VEX mit vier Status (Not Affected, Affected, Fixed, Under Investigation), ob eine Schwachstelle im konkreten Produkt tatsächlich ausnutzbar ist. In der Praxis reduziert das die relevanten Findings oft um 90 %.
- Q.11
- Muss ich meine SBOM veröffentlichen?
- Nein. Der Cyber Resilience Act fordert keine Veröffentlichung der SBOM. Sie muss jedoch in der technischen Dokumentation enthalten sein und auf Anfrage den Marktaufsichtsbehörden bereitgestellt werden.
- Q.12
- 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.
- Q.13
- 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; SBOM-Tools wie Syft oder Trivy fokussieren sich auf die standardisierte Inventarerstellung in SPDX oder CycloneDX.
- Q.14
- Welche SBOM-Tiefenstufen gibt es?
- Die BSI TR-03183-2 definiert vier Stufen: (1) n-Level — nur direkte Abhängigkeiten, (2) Transitiv — alle Abhängigkeiten inkl. transitive, (3) Liefergegenstand — nur die tatsächlich ausgelieferten Komponenten, (4) Vollständig — alle Komponenten inkl. Build- und Entwicklungsabhängigkeiten.
Verwandte Artikel
EU Cyber Resilience Act im Maschinenbau
Was der CRA für Maschinenbauer bedeutet: Anforderungen, Fristen und Umsetzungsstrategien.
DevSecOps in der Industrie: IEC 62443
Security-First in der OT-Welt: IEC 62443, Shift-Left und Policy-as-Code für industrielle Umgebungen.
CI/CD für SPS: TIA-Portal mit Jenkins
Automatisierte Build-, Test- und Deployment-Pipelines für SPS-Projekte mit TIA Portal und Jenkins.
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