SBOM erstellen: Software-Stückliste für CI/CD & CRA-Compliance
Eine SBOM (Software Bill of Materials), auf Deutsch auch Software-Stückliste genannt, 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
Warum SBOMs jetzt entscheidend sind
Eine SBOM (Software Bill of Materials), auf Deutsch Software-Stückliste, ist das zentrale Instrument für Software Supply Chain Security. Die Software-Lieferkette ist zum Angriffsvektor Nummer eins geworden — 75 % aller Unternehmen wurden 2024 Opfer eines Supply-Chain-Angriffs (BlackBerry 2024). SolarWinds, Log4Shell, die xz-utils-Backdoor — diese Vorfälle haben gezeigt, dass Unternehmen nicht wissen, welche Komponenten in ihrer Software stecken. Eine SBOM ändert das.
Gleichzeitig macht der EU Cyber Resilience Act die SBOM-Dokumentation für alle Produkte mit digitalen Elementen zur Pflicht. Erste Meldepflicht: 11. September 2026. Vollständige Umsetzung: 11. Dezember 2027. Bußgelder bei Nicht-Compliance: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes. Wer jetzt nicht anfängt, riskiert den Marktzugang — denn ohne SBOM keine CE-Kennzeichnung.
In diesem Artikel zeigen wir Ihnen, was eine SBOM ist, welche Formate und Tools es gibt, wie Sie die SBOM-Automatisierung in Ihre CI/CD-Pipeline integrieren, was die BSI TR-03183-2 fordert, wie VEX Ihre SBOMs actionable macht 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), auf Deutsch Software-Stückliste, ist ein maschinenlesbares Inventar aller Softwarekomponenten eines Produkts — einschließlich Abhängigkeiten, Versionen, Lizenzen, Herkunft und kryptografischer Prüfsummen. Der EU Cyber Resilience Act macht SBOMs ab Dezember 2027 zur Pflicht für alle Produkte mit digitalen Elementen. SCA (Software Composition Analysis) ist der zugehörige Analyseprozess — die SBOM ist das dokumentierte Ergebnis.
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" } }]
}
]
}SPDX SBOM-Beispiel
{
"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..."
}]
}
]
}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-Formate Übersicht: SPDX vs. CycloneDX im Vergleich
| Kriterium | SPDX | CycloneDX |
|---|---|---|
| Standard | ISO/IEC 5962:2021 | ECMA-424 (in Arbeit) |
| Organisation | Linux Foundation | OWASP |
| Security-Fokus | Mittel | Hoch (native VEX-Unterstützung) |
| Lizenz-Fokus | Hoch | Mittel |
| CRA-konform | Ja | Ja |
| BSI TR-03183-2 | Ab SPDX 3.0.1 | Ab CycloneDX 1.6 |
| VEX-Support | Extern (Companion-Dokument) | Nativ integriert |
| NTIA Minimum Elements | Vollständig abbildbar | Vollständig abbildbar |
SBOM-Tools im Vergleich: Syft vs. Trivy vs. cdxgen
Alle fünf Tools sind Open Source und produktionsreif. Syft, Trivy, cdxgen und das Microsoft SBOM Tool generieren SBOMs; Dependency-Track ist die Management-Plattform für das SBOM-Lifecycle-Management. 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 SBOM-Signierung.
- SPDX 2.2 Output
- SBOM-Signierung und Validierung
- Integration in Azure DevOps
- Enterprise-Support
Dependency-Track
OWASP | Open Source (Apache 2.0)SBOM-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
BSI TR-03183-2: 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 für SBOM-Qualität. Sie definiert, welche Datenfelder eine SBOM enthalten muss und wie tief die Analyse gehen soll — und ist damit der Referenzstandard für SBOM-Compliance im DACH-Raum.
Pflichtfelder gemäß BSI TR-03183-2
- Komponentenname und Version
- Supplier / Hersteller der Komponente
- Package URL (purl) als eindeutige Identifikation
- Lizenzinformationen (SPDX License Expression)
- Kryptografischer Hash (SHA-256 oder stärker)
- Abhängigkeitsbeziehungen (direkt und transitiv)
SBOM-Tiefenstufen nach BSI TR-03183-2
n-Level
Nur direkte Abhängigkeiten — der erste Schritt
Transitiv
Alle Abhängigkeiten inkl. transitive — empfohlen für Security-Analysen
Liefergegenstand
Nur tatsächlich ausgelieferte Komponenten — Mindestanforderung für CRA
Vollständig
Alle Komponenten inkl. Build- und Entwicklungsabhängigkeiten
Format-Anforderungen
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 an die Datenfelder nicht vollständig. Der BSI stellt auf GitHub einen CycloneDX-Namespace bereit, der die TR-Datenfelder auf CycloneDX-Properties abbildet.
SBOM und VEX: Schwachstellen im Kontext bewerten
Eine SBOM listet alle Komponenten. Ein Vulnerability-Scan meldet alle bekannten CVEs für diese Komponenten. Aber: nicht jede gemeldete Schwachstelle ist in Ihrem Produkt tatsächlich ausnutzbar. Genau hier setzt VEX (Vulnerability Exploitability Exchange) an.
In der Praxis bedeutet das: Von 200 gemeldeten CVEs sind oft nur 20 tatsächlich ausnutzbar. Ohne VEX versinken Teams in False Positives. Mit VEX wird aus der SBOM ein actionable Werkzeug für das Vulnerability-Management.
Die vier VEX-Status
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.
SBOM + VEX in der Praxis
SBOM-CI/CD-Integration: Automatisierung der Pipeline
Die manuelle SBOM-Erstellung skaliert nicht. Der richtige Ansatz ist die SBOM-Automatisierung 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.
SBOM erstellen mit Jenkins: Jenkinsfile-Beispiel
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 (Veröffentlichung im Amtsblatt)
Meldepflicht: 24h-Frist für ausgenutzte Schwachstellen an ENISA, 72h für Detailbericht
Vollständige Umsetzungspflicht — keine CE-Kennzeichnung ohne SBOM und Compliance
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
SBOM-Meldepflicht ab September 2026 — jetzt handeln
Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden und innerhalb von 72 Stunden einen Detailbericht nachliefern. Ohne SBOM und automatisiertes Vulnerability-Tracking ist diese Frist praktisch nicht einzuhalten.
Ab 11. Dezember 2027 gilt die vollständige Umsetzungspflicht: Keine CE-Kennzeichnung ohne konforme technische Dokumentation inklusive SBOM. Ohne CE kein Marktzugang in der EU.
Bußgelder bei Nicht-Compliance: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.
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 und Embedded-Software
SBOM-Erstellung für Web-Applikationen und Cloud-Services ist mittlerweile gut verstanden. Für industrielle Software — SPS-Code, Firmware, Embedded-Systeme mit Yocto oder Buildroot — gibt es spezifische Herausforderungen, die besondere Lösungsansätze erfordern. Die IEC 62443 für industrielle Cybersicherheit und der CRA fordern hier besondere Sorgfalt.
Proprietäre Toolchains
SPS-Entwicklungsumgebungen wie TIA Portal oder CODESYS haben eigene Paketformate, die von Standard-SBOM-Tools nicht erkannt werden.
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.
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-Automatisierung in wenigen Stunden in bestehende CI/CD-Pipelines integrieren. Die Formate SPDX und CycloneDX sind standardisiert, die BSI TR-03183-2 definiert klare Qualitätsanforderungen und mit VEX werden Ihre SBOMs actionable. Dependency-Track bietet das zentrale Dashboard für das SBOM-Lifecycle-Management.
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.
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.
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 %.
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. Die SBOM wird als vertrauliches Dokument behandelt.
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.
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.
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. Für CRA-Compliance wird mindestens die Stufe „Liefergegenstand" empfohlen.
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 buchenVon Comquent-Experten beraten — seit 2006 | 47+ erfolgreiche Projekte | Industrie, Automotive, Finance