SBOM erstellen: Software Supply Chain Security für CI/CD
Software Bill of Materials (SBOM) erstellen, Formate vergleichen und automatisiert in Ihre CI/CD-Pipeline integrieren — Schritt für Schritt, mit Code-Beispielen und den richtigen Tools.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Warum SBOMs jetzt entscheidend sind
Die Software-Lieferkette ist zum Angriffsvektor Nummer eins geworden. SolarWinds, Log4Shell, die xz-utils-Backdoor — diese Vorfälle haben gezeigt, dass Unternehmen nicht wissen, welche Komponenten in ihrer Software stecken. Eine SBOM (Software Bill of Materials) ändert das.
Gleichzeitig macht der EU Cyber Resilience Act die SBOM-Dokumentation für alle Produkte mit digitalen Elementen zur Pflicht — mit Fristen ab 2027. Wer jetzt nicht anfängt, riskiert den Marktzugang.
In diesem Artikel zeigen wir Ihnen, was eine SBOM ist, welche Formate und Tools es gibt, wie Sie die SBOM-Generierung in Ihre CI/CD-Pipeline integrieren und was das konkret für industrielle Software bedeutet.
Was Sie in diesem Artikel lernen
Was ist eine SBOM?
Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Inventar aller Komponenten, aus denen eine Software besteht — inklusive Abhängigkeiten, Versionen, Lizenzen und Herkunft.
Die Fertigungs-Analogie
In der Fertigung ist die Stückliste (Bill of Materials) seit Jahrzehnten Standard: Jedes physische Produkt hat ein dokumentiertes Inventar aller Bauteile, Materialien und Zulieferer. Die SBOM überträgt dieses Prinzip auf Software. Genau wie Sie bei einem Rückruf wissen müssen, welche Fahrzeuge ein bestimmtes Bauteil enthalten, müssen Sie bei einer Schwachstelle (CVE) wissen, welche Ihrer Produkte eine betroffene Bibliothek verwenden.
Was enthält eine SBOM?
Komponentenname
lodashVersion
4.17.21Lizenz
MITHerkunft / Supplier
npmjs.comAbhängigkeiten
transitive depsHash / Checksum
SHA-256{
"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" } }]
}
]
}SBOM-Formate im Vergleich: SPDX vs. CycloneDX
Zwei Formate dominieren den Markt. Beide werden vom Cyber Resilience Act akzeptiert, unterscheiden sich aber in Fokus und Stärken. Hier die Gegenüberstellung.
SPDX
Software Package Data ExchangeLinux Foundation
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
CycloneDX Bill of MaterialsOWASP Foundation
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
Unsere Empfehlung
Für die meisten DevSecOps-Pipelines empfehlen wir CycloneDX als primäres Format, da es nativ auf Security-Workflows ausgelegt ist und VEX-Dokumente unterstützt. Für Kunden mit strengen Lizenz-Compliance-Anforderungen oder ISO-Zertifizierung ist SPDX die bessere Wahl. Viele Tools können beide Formate erzeugen — Sie müssen sich nicht exklusiv entscheiden.
SBOM-Tools im Überblick
Alle vier Tools sind Open Source, produktionsreif und lassen sich in CI/CD-Pipelines integrieren. Die Wahl hängt von Ihrem Technologie-Stack und Ihren Anforderungen ab.
Syft
Anchore | Open Source (Apache 2.0)Leistungsstarker 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)
Trivy
Aqua Security | Open Source (Apache 2.0)All-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
cdxgen
CycloneDX / AppThreat | Open Source (Apache 2.0)Spezialisierter 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
Microsoft SBOM Tool
Microsoft | Open Source (MIT)Enterprise-taugliches SBOM-Tool mit Fokus auf SPDX-Konformität und Signierung von SBOMs.
- SPDX 2.2 Output
- SBOM-Signierung und Validierung
- Integration in Azure DevOps
- Enterprise-Support
SBOM in der CI/CD-Pipeline
Die manuelle SBOM-Erstellung skaliert nicht. Der richtige Ansatz ist die automatische Generierung als fester Bestandteil Ihrer CI/CD-Pipeline. So erhalten Sie bei jedem Build eine aktuelle, vollständige SBOM — ohne manuellen Aufwand.
Integration in 6 Schritten
Build-Artefakt erstellen
Ihr regulärer Build-Prozess erzeugt das Artefakt — ein Container-Image, ein Firmware-Binary oder ein Softwarepaket.
SBOM generieren
Direkt nach dem Build wird die SBOM aus dem Artefakt erzeugt. Das Tool analysiert alle enthaltenen Abhängigkeiten, Versionen und Lizenzen.
SBOM validieren
Die erzeugte SBOM wird auf Vollständigkeit und Schema-Konformität geprüft. Unbekannte oder nicht-auflösbare Komponenten werden markiert.
Vulnerability-Check
Die SBOM wird gegen bekannte Schwachstellen-Datenbanken (NVD, OSV, GitHub Advisory) abgeglichen. Kritische CVEs können die Pipeline blockieren.
Lizenz-Compliance prüfen
Automatische Prüfung aller Lizenzen gegen eine definierte Policy. Inkompatible oder unbekannte Lizenzen lösen ein Quality Gate aus.
SBOM archivieren und verteilen
Die signierte SBOM wird zusammen mit dem Release-Artefakt archiviert und kann an Kunden oder Regulierungsbehörden weitergegeben werden.
Beispiel: Jenkinsfile mit SBOM-Generierung
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'
}
}
}
}Beispiel: GitLab CI mit Trivy
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 yearCyber Resilience Act und SBOM-Pflicht
Der EU Cyber Resilience Act (CRA) ist das wichtigste europäische Regelwerk für Cybersicherheit von Produkten mit digitalen Elementen. Die SBOM ist ein zentrales Element der geforderten technischen Dokumentation.
Cyber Resilience Act tritt in Kraft
Meldepflicht für Schwachstellen und Vorfälle
Vollständige Umsetzungspflicht — alle Produkte mit digitalen Elementen
Was der CRA in Bezug auf SBOM fordert
- Identifikation aller Komponenten und Abhängigkeiten (SBOM)
- Dokumentation bekannter Schwachstellen zum Zeitpunkt der Markteinbringung
- Bereitstellung von Sicherheitsupdates über den gesamten Produktlebenszyklus
- Meldepflicht für aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden
- Technische Dokumentation für Marktaufsichtsbehörden auf Anfrage
Eine detaillierte Analyse der CRA-Anforderungen für den Maschinenbau finden Sie in unserem Artikel EU Cyber Resilience Act im Maschinenbau.
SBOM für industrielle Software
SBOM-Erstellung für Web-Applikationen und Cloud-Services ist mittlerweile gut verstanden. Für industrielle Software — SPS-Code, Firmware, Embedded-Systeme — gibt es spezifische Herausforderungen, die besondere Lösungsansätze erfordern.
Proprietäre Toolchains
SPS-Entwicklungsumgebungen wie TIA Portal oder CODESYS haben eigene Paketformate, die von Standard-SBOM-Tools nicht erkannt werden.
Firmware und Embedded-Abhängigkeiten
Embedded-Systeme verwenden oft statisch gelinkte Bibliotheken, die in der Binary-Analyse schwer identifizierbar sind.
Langlebige Produkte
Industrielle Anlagen laufen 15–20 Jahre. Die SBOM muss über den gesamten Lebenszyklus aktuell gehalten werden.
Zulieferketten-Transparenz
OT-Systeme bestehen aus Komponenten verschiedener Zulieferer — jeder mit eigener Software-Landschaft.
DevSecOps für die Industrie
SBOM ist ein Baustein eines umfassenden DevSecOps-Ansatzes für industrielle Umgebungen. Zusammen mit IEC 62443, Policy-as-Code und automatisierten Security-Scans in der Pipeline entsteht ein durchgängiges Sicherheitskonzept vom Quellcode bis zum Shopfloor.
Fazit: SBOM ist kein Nice-to-have mehr
Die Software Bill of Materials wandelt sich vom freiwilligen Best Practice zur regulatorischen Pflicht. Der Cyber Resilience Act setzt klare Fristen, und Supply-Chain-Angriffe machen Transparenz über Software-Abhängigkeiten zur Notwendigkeit.
Die gute Nachricht: Die Tooling-Landschaft ist reif. Mit Syft, Trivy oder cdxgen lässt sich die SBOM-Generierung in wenigen Stunden in bestehende CI/CD-Pipelines integrieren. Die Formate SPDX und CycloneDX sind standardisiert und interoperabel.
Unser Rat: Fangen Sie jetzt an. Beginnen Sie mit einem Pilotprojekt, generieren Sie Ihre erste SBOM automatisiert und bauen Sie von dort aus. In 90 Tagen können Sie eine vollständige SBOM-Pipeline für Ihre kritischsten Produkte haben.
SBOM und DevSecOps in Ihrer Pipeline?
Wir helfen Ihnen, SBOM-Generierung, Vulnerability-Scanning und Lizenz-Compliance in Ihre bestehende CI/CD-Pipeline zu integrieren — für IT und OT.
Häufig gestellte Fragen zu SBOM
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.
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. Viele Tools können beide Formate erzeugen.
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.
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.
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.
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.
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.
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. Für industrielle Software mit proprietären Toolchains ist der Aufwand höher.
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.
Bereit für den nächsten Schritt?
Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Erstgespräch buchen