SBOM erstellen:
Software-Stückliste
für CI/CD und CRA.
Wie Sie eine SBOM (Software Bill of Materials) Schritt für Schritt erstellen: Format wählen, Tool wählen, in der Pipeline erzeugen, gegen die BSI TR-03183-2 prüfen und Schwachstellen bewerten. Mit Befehlen, die Sie kopieren können, und den Sonderfällen aus SPS und Firmware.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Wie erstellt
man eine SBOM?
Nach jedem Build.
Eine SBOM (Software Bill of Materials) erstellen Sie, indem nach dem Build ein Tool wie Syft, Trivy oder cdxgen Ihr Container-Image, Ihre Firmware oder Ihren Quellcode analysiert und alle Komponenten mit Version, Lizenz und Prüfsumme in eine Datei schreibt. Als Format nehmen Sie CycloneDX oder SPDX. Die deutsche Richtlinie BSI TR-03183-2 verlangt CycloneDX ab 1.6 oder SPDX ab 3.0.1. Pflicht wird die SBOM mit dem EU Cyber Resilience Act am 11. Dezember 2027.
Stand: 13.10.2026 · Syft 1.54 · Trivy 0.75 · CycloneDX 1.7 (ECMA-424) · BSI TR-03183-2 v2.1.0 · CRA-Meldepflicht seit 11.09.2026
Wer im Dezember 2021 dabei war, erinnert sich an das Log4Shell-Wochenende. Tagelang wurden Repositories durchsucht, Hersteller angeschrieben und Excel-Listen geführt, nur um herauszufinden, wo log4j überhaupt steckt. Mit einer SBOM ist dieselbe Frage ein Abgleich von Minuten. SolarWinds und die Hintertür in xz-utils haben seitdem gezeigt, dass das kein Einzelfall war.
AIDer Artikel folgt der Reihenfolge, in der Sie arbeiten. Ob Sie überhaupt müssen, klärt Abschnitt 02. Wer SPS-Programme oder Firmware ausliefert, findet die Sonderfälle in Abschnitt 09.
* Mehr als 75 % der Software-Lieferketten waren in den zwölf Monaten vor April 2024 Cyberangriffen ausgesetzt. Umfrage unter 1.000 IT-Entscheidern, BlackBerry, Juni 2024.
Ist die SBOM-Pflicht 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.
Ist SBOM Pflicht?
Ab Dezember 2027.
Ja. Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt in Anhang I eine Software-Stückliste „in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“. Verbindlich wird das mit der vollen Geltung am 11. Dezember 2027. Die SBOM gehört dann zur technischen Dokumentation und wird der Marktüberwachung auf begründetes Verlangen vorgelegt. Veröffentlichen müssen Sie sie nicht. Bei Verstößen drohen bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Der Cyber Resilience Act tritt in Kraft (Amtsblatt vom 20.11.2024).
Meldepflicht gilt: aktiv ausgenutzte Schwachstellen binnen 24 Stunden als Frühwarnung an die ENISA-Meldeplattform, Meldung binnen 72 Stunden.
Volle Geltung: Die SBOM gehört zur technischen Dokumentation, ohne sie keine CE-Konformität.
Die Meldepflicht läuft schon. Seit dem 11. September 2026 melden Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden, auch für Maschinen, die längst beim Kunden stehen. Die erste Frage in dieser Meldung lautet: Welche Produkte und Softwarestände sind betroffen? Ohne SBOM wird aus diesen 24 Stunden ein Log4Shell-Wochenende.
Oberste Ebene reicht dem Gesetz, der Praxis nicht. Die BSI TR-03183-2 verlangt eine rekursive Auflösung bis über den eigenen Lieferumfang hinaus, und die internationalen Mindestanforderungen, die CISA und BSI im Juli 2026 mit 16 weiteren Behörden veröffentlicht haben, kennen keine Mindesttiefe mehr. Ein Durchführungsrechtsakt zum SBOM-Format, den der CRA in Art. 13 Abs. 24 erlaubt, liegt noch nicht vor. Die TR ist damit die konkreteste Vorlage, die es gibt.
Die gestaffelten Fristen und Produktklassen erklärt unser Glossar unter Cyber Resilience Act (CRA), was sie für Maschinenbauer bedeuten, der Artikel EU Cyber Resilience Act im Maschinenbau.
Was steht in
einer SBOM?
In der Fertigung hat jedes Produkt seit Jahrzehnten eine Stückliste. Die SBOM (Software Bill of Materials) überträgt das auf Software. Bei einem Rückruf müssen Sie wissen, in welchen Maschinen ein fehlerhaftes Bauteil sitzt. Bei einer neuen CVE ist es dieselbe Frage, nur für eine Bibliothek.
Die purl ist die Adresse der Komponente. Eine Package URL wie pkg:npm/express@4.18.2 nennt Paketquelle, Name und Version in einer Zeile. Über sie gleichen Scanner und Schwachstellen-Datenbanken ab, ob eine Meldung Ihre Komponente betrifft. Seit Dezember 2025 ist das Schema als ECMA-427 standardisiert.
Die Prüfsumme beweist, welche Datei gemeint ist. Zwei Builds mit derselben Versionsnummer können sich unterscheiden. Erst der Hash der ausgelieferten Datei macht die Zuordnung eindeutig, und die BSI-Richtlinie verlangt ihn als SHA-512.
SBOM-Beispiel: Wie sieht eine Software-Stückliste aus?
Eine SBOM ist eine JSON- oder XML-Datei, keine Tabelle für Menschen. Oben stehen Format und Version, darunter eine Liste von Komponenten, jede mit Name, Version, purl, Lizenz und Hash. Die beiden Beispiele beschreiben dieselbe Bibliothek einmal in CycloneDX und einmal in SPDX. Der Inhalt ist gleich, die Feldnamen unterscheiden sich.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "library",
"name": "express",
"version": "4.18.2",
"purl": "pkg:npm/express@4.18.2",
"licenses": [
{ "license": { "id": "MIT" } }
],
"hashes": [{
"alg": "SHA-512",
"content": "<128 Hex-Zeichen>"
}]
}
]
}{
"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",
"licenseConcluded": "MIT",
"externalRefs": [{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:npm/express@4.18.2"
}]
}
]
}Gekürzte Beispiele. Ein Beispiel mit allen Pflichtfeldern der BSI TR-03183-2 steht in Abschnitt 07. SPDX 2.3 genügt der Richtlinie nicht, sie verlangt SPDX ab 3.0.1.
Was macht CycloneDX,
und wann passt SPDX besser?
CycloneDX ist der Stücklisten-Standard der OWASP mit Sicherheitsfokus. Er trägt Schwachstellen und VEX-Bewertungen im selben Dokument und ist damit das Format für Schwachstellen-Management in der Pipeline. SPDX ist als ISO/IEC 5962 genormt und bildet Lizenzen und Herkunft feiner ab, was bei Lizenz-Compliance und Zertifizierungen zählt. Der Cyber Resilience Act akzeptiert beide.
Auf dem Papier ist das eine Geschmacksfrage. In der Werkzeugkette ist sie es nicht mehr. Die BSI-Richtlinie verlangt SPDX ab 3.0.1. Trivy und der GitHub-Export schreiben SPDX nur bis 2.3, Syft kann SPDX 3 erst seit Juni 2026 und nur auf Anforderung, und Dependency-Track liest SPDX gar nicht. CycloneDX ab 1.6 dagegen kommt aus allen gängigen Generatoren.
SPDX
- Organisation
- Linux Foundation
- Standard
- ISO/IEC 5962:2021 (SPDX 2.2.1), SPDX 3.0 im ISO-Verfahren
- — ISO-Norm
- — Lizenzen und Herkunft sehr fein abbildbar
- — Yocto und das Microsoft SBOM Tool schreiben SPDX 3.0
- — Trivy und GitHub schreiben nur SPDX 2.3, Syft schreibt SPDX 3 nur auf Anforderung
- — Dependency-Track liest kein SPDX
- — VEX nur in einem anderen Format (CSAF, OpenVEX)
Lizenz-Compliance, Yocto-basierte Embedded-Systeme, Zertifizierungen
CycloneDX
- Organisation
- OWASP Foundation
- Standard
- ECMA-424 (2. Ausgabe Dez. 2025 = CycloneDX 1.7)
- — Auf Schwachstellen-Management ausgelegt
- — VEX im selben Format
- — Syft, Trivy und cdxgen schreiben standardmäßig 1.7
- — Dependency-Track liest es direkt
- — Keine ISO-Norm
- — Lizenzangaben weniger granular als SPDX
DevSecOps-Pipelines, Container, CRA- und BSI-Nachweise
Nehmen Sie CycloneDX ab 1.6 als Hauptformat. Damit sind Pipeline, BSI-Richtlinie und Dependency-Track ohne Umweg verbunden. Syft, Trivy und cdxgen schreiben inzwischen 1.7. Dependency-Track liest diese Version erst ab 5.1 und 4.14.4. Wer einen älteren Stand betreibt, legt Syft mit -o cyclonedx-json@1.6 auf die Vorgängerversion fest. SPDX bleibt die richtige Wahl, wenn ein Kunde es verlangt, wenn Lizenz-Compliance im Vordergrund steht oder wenn Ihr Yocto-Build es ohnehin als SPDX 3 schreibt. Tools wie cdxgen exportieren bei Bedarf beide Formate.
Syft. Trivy. cdxgen.
Alle Open Source.
Welches SBOM-Tool passt, entscheidet Ihr Artefakt. Liefern Sie Container aus, setzen Sie Syft oder Trivy auf das fertige Image. Liegt der Schwerpunkt im Quellcode vieler Sprachen, ist cdxgen stärker. Die Liste trennt nach Rolle: Vier Tools erzeugen die SBOM, Grype prüft sie, Dependency-Track behält sie nach dem Release im Blick.
- /01Erzeugt
SyftSBOM-Generator für Container-Images und Dateisysteme
Anchore · Apache 2.0Der vielseitigste Generator. Syft liest Container-Images, Verzeichnisse und Archive. Seit Juni 2026 schreibt es standardmäßig CycloneDX 1.7, mit -o cyclonedx-json@1.6 die Vorgängerversion. SPDX kommt als 2.3, auf Anforderung mit -o spdx-json@3.0 als SPDX 3. Für die BSI-Richtlinie passt die CycloneDX-Ausgabe ohne Zusatz.
- — Docker- und OCI-Images
- — Dateisysteme und Archive
- — CycloneDX 1.7 und 1.6, SPDX 2.3 und 3.0
- — Grype prüft die Syft-SBOM
$ syft myapp:latest -o cyclonedx-json > sbom.cdx.json - /02Erzeugt und prüft
TrivyTrivy-SBOM erzeugen und im selben Tool auf CVEs prüfen
Aqua Security · Apache 2.0Scanner, der auch SBOMs schreibt. Trivy erzeugt das Inventar aus Images, Repositories und Kubernetes-Clustern und prüft mit trivy sbom eine vorhandene SBOM gegen bekannte CVEs.
- — SBOM und Schwachstellen-Scan in einem Tool
- — Container, Git-Repositories, Kubernetes
- — CycloneDX 1.7, SPDX 2.3
- — Liest VEX-Dokumente ein
$ trivy image --format cyclonedx -o sbom.cdx.json myapp:latest - /03Erzeugt
cdxgenCycloneDX-Generator für Quellcode vieler Paketmanager
OWASP CycloneDX · Apache 2.0Setzt am Quellcode an statt am fertigen Image. cdxgen erkennt Maven, Gradle, npm, pip, Go, Cargo, NuGet und viele weitere Paketmanager samt transitiver Abhängigkeiten und schreibt standardmäßig CycloneDX 1.7.
- — Java, .NET, Go, Rust, Python, JavaScript u. v. m.
- — Transitive Abhängigkeiten
- — CycloneDX 1.6 und 1.7
- — Export nach SPDX 3.0.1
$ cdxgen -t java -o sbom.cdx.json . - /04Erzeugt
Microsoft SBOM ToolSPDX-SBOM für Build-Ausgaben, auch als SPDX 3.0
Microsoft · MITErzeugt SPDX aus einem Build-Ordner und kann die Datei signieren. Standard ist SPDX 2.2, mit dem Parameter -mi SPDX:3.0 schreibt es die Version, die die BSI-Richtlinie verlangt.
- — SPDX 2.2 und 3.0
- — Signierung und Validierung
- — Azure DevOps und GitHub Actions
- — Build-Ordner statt Image
$ sbom-tool generate -b ./build -bc ./src -pn myapp -pv 1.0 -ps "Muster GmbH" -nsb https://sbom.example.com -mi SPDX:3.0 - /05Prüft
GrypeSchwachstellen-Scanner für fertige SBOMs
Anchore · Apache 2.0Das Gegenstück zu Syft. Grype liest eine SBOM, gleicht jede Komponente mit Schwachstellen-Datenbanken ab und beendet den Build mit Fehler, sobald eine CVE ab dem gesetzten Schweregrad auftaucht.
- — Liest CycloneDX und SPDX
- — Build-Abbruch per --fail-on
- — Läuft offline mit lokaler Datenbank
- — Ergebnis als Tabelle, JSON oder SARIF
$ grype sbom:./sbom.cdx.json --fail-on critical - /06Verwaltet
Dependency-TrackSBOM-Plattform für laufendes CVE-Monitoring
OWASP · Apache 2.0Kein Generator, sondern das Gedächtnis. Dependency-Track speichert die SBOM jedes Releases und prüft sie fortlaufend gegen neue Schwachstellen, auch Jahre nach der Auslieferung. Version 5.0 ist seit Juni 2026 verfügbar.
- — Laufender CVE-Abgleich aller Versionen
- — Policies für Lizenzen und Schweregrade
- — VEX-Import und Audit-Trail
- — Nur CycloneDX, kein SPDX
$ curl -X POST https://dtrack.example.com/api/v1/bom -H "X-Api-Key: $DT_API_KEY" -F "projectName=myapp" -F "projectVersion=1.4.0" -F "autoCreate=true" -F "bom=@sbom.cdx.json"
Docker erzeugt die SBOM auf Wunsch selbst. docker buildx build --sbom=true hängt sie beim Bauen als SPDX-Attestation an das Image, docker scout sbom liest sie aus einem fertigen Image. Den älteren Befehl docker sbom hat Docker entfernt. GitHub exportiert SPDX 2.3 aus dem Dependency Graph, GitLab schreibt beim Dependency Scanning CycloneDX. Beide beschreiben das Repository, nicht das ausgelieferte Artefakt.
Im März 2026 veröffentlichten Angreifer mit gestohlenen Zugangsdaten ein manipuliertes Trivy-Release und ersetzten die Tags der GitHub Action trivy-action durch Code, der CI/CD-Secrets abgreift. Für ein paar Stunden war genau das Werkzeug kompromittiert, das die Lieferkette absichern soll. Pinnen Sie Actions deshalb auf einen Commit-SHA und Images auf einen Digest, nie auf latest oder einen Tag. Advisory GHSA-69fq-xp46-6x23
Welches SBOM-Format passt zu Ihrem Ziel?
CycloneDX und SPDX können beide viel. Welches Format passt, entscheidet Ihr primäres Ziel. Wo die SBOM entstehen muss, entscheidet den Weg dorthin. Zwei Klicks zeigen Ihnen die Empfehlung für Ihren Anwendungsfall.
Wofür brauchen Sie die SBOM primär?
Manuell skaliert nicht.
Automatisieren.
Die erste SBOM entsteht meist auf einem Entwickler-Laptop: ein Tool-Aufruf, eine JSON-Datei, ein Haken auf der Compliance-Liste. Drei Releases später beschreibt die Datei eine Software, die es so nicht mehr gibt, und niemand hat es bemerkt. Deshalb gehört die SBOM als fester Schritt in Ihre CI/CD-Pipeline. Sechs Schritte, die bei jedem Build laufen:
- /01
Artefakt bauen
Der normale Build erzeugt das Artefakt: ein Container-Image, ein Firmware-Image oder ein Softwarepaket. Die SBOM beschreibt genau dieses Artefakt, nicht das Repository.
- /02
SBOM erzeugen
Direkt nach dem Build läuft Syft, Trivy oder cdxgen gegen das Artefakt und schreibt alle Komponenten mit Version, Lizenz und Prüfsumme als CycloneDX-Datei.
- /03
SBOM validieren
cyclonedx validate prüft die Datei gegen das Schema. Ein zweiter Schritt prüft die Pflichtfelder der BSI TR-03183-2 und meldet Komponenten ohne Version, Ersteller oder Hash.
- /04
Schwachstellen prüfen
Grype oder trivy sbom gleichen die SBOM mit NVD, OSV und GitHub Advisories ab. Ab dem Schweregrad, den Sie festlegen, hält der Build an.
- /05
Lizenzen prüfen
Ein Abgleich gegen Ihre Lizenz-Policy findet Komponenten mit unbekannter oder unverträglicher Lizenz, bevor sie ausgeliefert werden.
- /06
Archivieren und hochladen
Die Pipeline legt die SBOM, am besten signiert, neben das Release-Artefakt und lädt sie in Dependency-Track hoch. Dort bleibt sie unter Beobachtung, solange die Version im Feld ist.
Pipeline-Beispiele: Jenkins, GitLab CI, GitHub Actions
Alle drei Beispiele erzeugen CycloneDX, prüfen auf kritische Schwachstellen und legen die SBOM beim Build ab. Versionen und Actions sind gepinnt, aus dem Grund, der in Abschnitt 05 steht.
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'docker build -t myapp:$BUILD_NUMBER .'
}
}
stage('SBOM erzeugen') {
steps {
sh 'syft myapp:$BUILD_NUMBER -o cyclonedx-json > sbom.cdx.json'
}
}
stage('SBOM validieren') {
steps {
sh 'cyclonedx validate --input-file sbom.cdx.json'
}
}
stage('Schwachstellen prüfen') {
steps {
sh 'grype sbom:sbom.cdx.json --fail-on critical'
}
}
stage('Archivieren') {
steps {
archiveArtifacts artifacts: 'sbom.cdx.json',
fingerprint: true
}
}
}
}generate-sbom:
stage: security
image:
name: aquasec/trivy:0.75.0 # fest pinnen, besser per Digest
entrypoint: [""]
script:
- trivy image
--format cyclonedx
--output sbom.cdx.json
$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
- trivy sbom sbom.cdx.json
--severity CRITICAL
--exit-code 1
artifacts:
paths:
- sbom.cdx.json
expire_in: never- name: SBOM erzeugen
uses: anchore/sbom-action@<commit-sha> # per SHA pinnen
with:
image: ghcr.io/muster/myapp:${{ github.sha }}
format: cyclonedx-json
output-file: sbom.cdx.jsonJob-Artefakte in Jenkins oder GitLab laufen irgendwann ab oder werden beim Aufräumen gelöscht. Der CRA verlangt, die technische Dokumentation zehn Jahre nach dem Inverkehrbringen aufzubewahren, bei längerem Unterstützungszeitraum entsprechend länger. Legen Sie die SBOM deshalb zusätzlich an das Release selbst, in die Package Registry oder in Ihr Artefakt-Repository, und laden Sie sie in Dependency-Track hoch.
Was verlangt
die BSI-Richtlinie
für SBOMs?
Die BSI TR-03183-2 ist die Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik für SBOMs, aktuell in Version 2.1.0 vom 20. August 2025. Sie verlangt je Komponente Ersteller, Name, Version, Dateiname, Abhängigkeiten, Lizenz und einen SHA-512-Hash, dazu Ersteller und Zeitstempel der SBOM. Abhängigkeiten müssen rekursiv aufgelöst werden, mindestens bis zur ersten Komponente außerhalb Ihres Lieferumfangs. Zugelassen sind CycloneDX ab 1.6 und SPDX ab 3.0.1.
Die Richtlinie ist kein Gesetz. Sie ist aber die genaueste Beschreibung, was eine SBOM enthalten muss, damit sie im Ernstfall trägt, und daran wird sich ein CRA-Nachweis gegenüber deutschen Behörden messen lassen müssen. Wer sie erfüllt, erfüllt auch den CRA-Wortlaut.
- 01Ersteller der Komponente, als E-Mail-Adresse oder URL
- 02Name und Version
- 03Dateiname, ohne Pfad
- 04Abhängigkeiten, mit der Angabe, ob die Aufzählung vollständig ist
- 05Distributionslizenz(en)
- 06SHA-512-Hash der ausgelieferten Datei
- 07Eigenschaften: ausführbar, Archiv, strukturiert
Für die SBOM selbst kommen Ersteller und Zeitstempel hinzu. Wenn vorhanden, gehören außerdem eine purl oder CPE, die URL des Quellcodes und die Originallizenz hinein.
- Top-level
Nur die direkten Abhängigkeiten der Hauptkomponente. Das ist das Mindestmaß des CRA-Wortlauts.
- n-level
Direkte und transitive Abhängigkeiten bis zu einer festgelegten Tiefe.
- Transitiv
Alle Abhängigkeiten sind aufgeführt, aber nicht alle vollständig beschrieben.
- Liefergegenstand
Alles im Lieferumfang vollständig beschrieben, dazu die erste Ebene außerhalb identifiziert. Das verlangt die TR mindestens.
- Vollständig
Alle Komponenten und alle Abhängigkeiten vollständig beschrieben.
Die fünf Stufen beschreibt der Anhang der TR zur Erläuterung. Verbindlich ist Abschnitt 5.1: rekursive Auflösung auf jedem Pfad bis einschließlich der ersten Komponente außerhalb des Lieferumfangs.
Beispiel einer SBOM nach BSI TR-03183-2
Das BSI hat für CycloneDX eigene Felder registriert, die Eigenschaften mit dem Präfix bsi:component:. Dort stehen Dateiname, die drei Eigenschaften ausführbar, Archiv und strukturiert sowie die wirksame Lizenz. Ob die Liste der Abhängigkeiten vollständig ist, sagt der Block compositions.
Den SHA-512-Hash prüfen Sie im ersten Lauf besonders genau. Generatoren übernehmen gern die Prüfsummen aus den Paket-Metadaten, und die beschreiben nicht zwingend die Datei, die Sie ausliefern. Für Ihr eigenes Artefakt rechnet sha512sum den Wert im selben Pipeline-Schritt.
Quellen: BSI TR-03183-2 v2.1.0 · BSI-Taxonomie für CycloneDX
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2026-09-28T08:15:00Z",
"manufacturer": {
"name": "Muster GmbH",
"url": ["https://muster.example"]
},
"component": {
"bom-ref": "myapp",
"type": "application",
"name": "myapp",
"version": "1.4.0"
}
},
"components": [{
"bom-ref": "pkg:npm/lodash@4.17.21",
"type": "library",
"name": "lodash",
"version": "4.17.21",
"manufacturer": { "url": ["https://lodash.com"] },
"purl": "pkg:npm/lodash@4.17.21",
"licenses": [{ "license": { "id": "MIT" } }],
"hashes": [{ "alg": "SHA-512", "content": "<128 Hex-Zeichen>" }],
"properties": [
{ "name": "bsi:component:filename",
"value": "lodash-4.17.21.tgz" },
{ "name": "bsi:component:executable",
"value": "non-executable" },
{ "name": "bsi:component:archive",
"value": "archive" },
{ "name": "bsi:component:structured",
"value": "structured" },
{ "name": "bsi:component:effectiveLicence",
"value": "MIT" }
]
}],
"dependencies": [
{ "ref": "myapp",
"dependsOn": ["pkg:npm/lodash@4.17.21"] },
{ "ref": "pkg:npm/lodash@4.17.21", "dependsOn": [] }
],
"compositions": [
{ "aggregate": "complete", "dependencies": ["myapp"] }
]
}Gekürzt: Die Hauptkomponente myapp braucht dieselben Pflichtfelder wie lodash. Die vollständige Zuordnung aller Felder zu CycloneDX und SPDX steht in Tabelle 9 der TR.
Von 200 CVEs.
Zu 20 relevanten.
Lassen Sie einen Scanner über die SBOM eines gewachsenen Container-Images laufen, und die Liste der gemeldeten CVEs ist schnell dreistellig. Nur ein Teil davon ist in Ihrem Produkt ausnutzbar: Die verwundbare Funktion wird nie aufgerufen, das Modul ist nicht geladen, die Konfiguration sperrt den Angriffsweg. Diese Bewertung festzuhalten ist die Aufgabe von VEX (Vulnerability Exploitability eXchange).
Ohne VEX prüft jedes Team dieselben Meldungen immer wieder, und der Kunde bekommt eine Fundliste statt einer Antwort. Mit VEX steht die Bewertung einmal im Dokument und gilt für den nächsten Scan mit.
- Not Affected
Die Schwachstelle steckt in der Komponente, ist in Ihrem Produkt aber nicht ausnutzbar, etwa weil der betroffene Codepfad nie aufgerufen wird.
- Affected
Die Schwachstelle ist ausnutzbar. Es braucht einen Patch, ein Upgrade oder eine Gegenmaßnahme.
- Fixed
Die Schwachstelle ist behoben, durch Upgrade, Patch oder geänderte Konfiguration.
- Under Investigation
Die Prüfung läuft noch. Auch das ist eine Aussage, die Kunden weiterhilft.
Die vier Status stammen aus den VEX-Mindestanforderungen der CISA und aus OpenVEX, CSAF nennt sie known_not_affected, known_affected, fixed und under_investigation. CycloneDX nutzt eigene, feinere Werte wie not_affected, exploitable oder in_triage.
Das ist kein Entweder-oder. Die SBOM sagt, was in Ihrem Produkt steckt. CSAF (Common Security Advisory Framework) sagt, was eine Schwachstelle für Ihr Produkt bedeutet, und transportiert VEX als Sicherheitshinweis an Kunden. CSAF ist ein OASIS-Standard und seit 2025 als ISO/IEC 20153 genormt, das BSI empfiehlt es ausdrücklich. Siemens und Beckhoff veröffentlichen ihre Advisories bereits so. Die BSI TR-03183-2 verlangt außerdem, dass die SBOM selbst keine Schwachstelleninformationen trägt, weil sich diese ändern, die Stückliste eines Releases aber nicht. Legen Sie die Bewertung deshalb als eigenes Dokument ab. Intern reicht dafür VEX in CycloneDX, nach außen ist CSAF das Format, das Kunden-Tools lesen.
Eine SBOM beantwortet nur die Fragen, die jemand an sie stellt. OWASP Dependency-Track stellt sie ständig: Die Plattform speichert die SBOM jeder ausgelieferten Version und gleicht sie laufend mit neuen Schwachstellen aus NVD, GitHub Advisories und OSV ab. Wird morgen die nächste log4j-Lücke bekannt, zeigt eine Suche über alle Projekte, welche Softwarestände betroffen sind. VEX-Bewertungen importiert sie mit, sodass bereits geprüfte Befunde nicht wieder auftauchen. Seit Juni 2026 gibt es Version 5.0, als Container mit PostgreSQL. Sie liest nur CycloneDX.
Wie erstellen Sie eine
SBOM für eine Maschine?
Als Stückliste aus Stücklisten.
Jede Baugruppe mit Software bekommt ihre eigene SBOM: das SPS-Programm, die HMI, der Industrie-PC, die Antriebs-Firmware, das zugekaufte Kamerasystem. Die SBOM der Maschine verweist auf diese Einzel-SBOMs, statt alles in eine Datei zu kopieren. Für den Teil, den Sie selbst programmieren, müssen Sie die Stückliste erzeugen. Für den zugekauften Teil müssen Sie sie beim Lieferanten einfordern.
Für Web-Anwendungen ist das alles Routine. In der Automatisierung scheitern die Standard-Tools an proprietären Projektformaten und an Firmware ohne Paketmanager. Wie SPS-Projekte überhaupt versioniert und automatisiert gebaut werden, zeigt unser Artikel zu CI/CD für SPS mit TIA Portal und Jenkins. Darauf setzt die SBOM auf.
AI- /01
SBOM für TIA Portal, CODESYS und TwinCAT
SPS-Projekte liegen in proprietären Formaten. Ein Scan mit Syft oder Trivy läuft durch und meldet keine einzige Komponente. Einen dokumentierten SBOM-Export für Anwenderprojekte haben wir bei TIA Portal, CODESYS und TwinCAT bislang nicht gefunden (Stand Oktober 2026).
So geht esDie Stückliste entsteht über die Automatisierungsschnittstellen der Engineering-Tools: Openness bei TIA Portal, die Scripting-Schnittstelle bei CODESYS, das Automation Interface bei TwinCAT. Ein Skript im Build liest Bibliotheken und Bausteine mit Version und Herkunft aus und schreibt sie als CycloneDX. Die Laufzeitumgebung ist davon getrennt: Die CODESYS-Runtime für Linux bringt seit Version 4.15 eine eigene SBOM mit, auf die Sie verweisen können.
- /02
SBOM für Firmware und Embedded Linux
Ein Yocto-Image enthält schnell mehrere hundert Pakete, und statisch gelinkte Bibliotheken sind im fertigen Binary kaum noch zu erkennen. Deshalb entsteht die SBOM hier im Build, nicht danach.
So geht esYocto schreibt SPDX seit Version 5.1 als 3.0, seit Yocto 6.0 (Mai 2026) nur noch als SPDX 3, und prüft mit der Klasse sbom-cve-check direkt auf Schwachstellen. Buildroot erzeugt CycloneDX mit make show-info | utils/generate-cyclonedx. Für Container-basierte Firmware reicht Syft gegen das Image.
- /03
Firmware ohne Betriebssystem
Bei Mikrocontroller-Firmware mit IAR, Keil oder STM32Cube gibt es keinen Paketmanager, den ein Tool auslesen könnte. HAL, RTOS und Middleware liegen als Quellcode im Projekt.
So geht esPflegen Sie die eingebundenen Bibliotheken als versionierte Komponentenliste im Repository, mit Version, Herkunft und Lizenz, und erzeugen Sie daraus bei jedem Build die SBOM. Den SHA-512-Hash des Firmware-Images liefert sha512sum im selben Schritt.
- /04
Maschinen mit Zulieferteilen
Eine Maschine enthält Software vieler Hersteller: SPS, HMI, Antriebe, Kamerasysteme, Industrie-PC. Keine einzelne SBOM kann all das aus eigener Kenntnis beschreiben.
So geht esDie Maschinen-SBOM verweist auf die SBOMs der Baugruppen. Die BSI TR-03183-2 erlaubt solche Verweise, wenn die referenzierten SBOMs selbst TR-konform sind, und legt die Verantwortung für ihre Verfügbarkeit beim Hersteller der Maschine ab. Deshalb gehören Format, Richtlinie und Lieferzeitpunkt der SBOM in jeden Zuliefervertrag.
- /05
Produkte, die 15 Jahre laufen
Eine Anlage von 2021 ist 2036 noch im Feld. Die SBOM ihres damaligen Softwarestands muss dann noch auffindbar sein, und neue CVEs müssen sie noch erreichen.
So geht esJede ausgelieferte Version behält ihre eigene SBOM, archiviert mit dem Release und als eigenes Projekt in Dependency-Track. Wird eine Schwachstelle bekannt, zeigt die Suche über alle Projekte, welche Softwarestände betroffen sind.
Die SBOM ist ein Baustein eines DevSecOps-Ansatzes für industrielle Umgebungen. Zusammen mit IEC 62443, Policy-as-Code und automatisierten Security-Scans ergibt sich eine Kette vom Quellcode bis zur Maschine beim Kunden, die ein Auditor nachvollziehen kann. Die Einbettung in die Norm beschreibt unser Artikel DevSecOps in der Industrie: IEC 62443.
Der Aufwand steckt weniger im Einrichten als im Dranbleiben. Scanner-Feeds veralten, Lizenzen ändern sich, und eine SBOM, die seit dem letzten Release nicht neu erzeugt wurde, ist im Ernstfall wertlos. Wer diesen Betrieb nicht selbst leisten will, lässt die Pipeline als Managed CI/CD per SLA betreiben. Die SBOM-Erzeugung läuft dann in jedem Build mit.
AIWhitepaper · 23 Seiten · PDF · Oktober 2026
Die SBOM für TIA Portal V21, in zehn Schritten.
Für TIA Portal nennt die Liste oben nur den Weg, die Schnittstelle Openness. Das Whitepaper führt ihn für SIMATIC-Steuerungen und TIA Portal V21 aus. Ein Skript liest Artikelnummern und Firmware-Stände aus dem Projekt, dazu kommen die SBOMs der Hersteller und Ihr eigener Code. Ein eigenes Kapitel zeigt die Jenkins-Pipeline, die daraus bei jedem Build eine geprüfte CycloneDX-Datei erzeugt und an Dependency-Track übergibt.
- /01Was in die SBOM einer Steuerung gehört: CPU-Firmware, Kommunikationsmodule, Bibliothekstypen, Anwenderprogramm, Webseiten des CPU-Webservers und zugekaufte Bausteine mit Know-how-Schutz
- /02Zehn Schritte von der Produktgrenze über das Auslesen per TIA Portal Openness mit C#-Beispiel und die Pflichtfelder der BSI TR-03183-2 bis zum Abgleich mit der Firmware, die tatsächlich in der Anlage läuft
- /03Eine Jenkins-Pipeline in acht Stufen mit Jenkinsfile, Validierung gegen CycloneDX 1.6 und Quality Gates, die Entwicklungs- und Release-Builds unterscheiden
- /04Neun typische Fallstricke mit Abhilfe und ein Einführungsplan in fünf Phasen von der Bestandsaufnahme bis zum Betrieb
Whitepaper anfordern
Kostenlos · per E-Mail · DSGVO-konform
Die Tools sind reif.
Fangen Sie mit einem Produkt an.
Nehmen Sie das Produkt, bei dem die letzte Kundenanfrage zu Schwachstellen am längsten gedauert hat. Bauen Sie Syft oder Trivy in dessen Pipeline, schreiben Sie CycloneDX ab 1.6, und laden Sie das Ergebnis in eine Dependency-Track-Instanz. Für eine Pipeline mit Containern ist das in ein bis drei Tagen erledigt. Bei SPS-Projekten und Firmware dauert es länger, weil die Komponentenliste erst entstehen muss.
Danach gleichen Sie die Datei gegen die Pflichtfelder der BSI TR-03183-2 ab. Die Lücken, die dabei auftauchen, sind Ihre Arbeitsliste bis Dezember 2027: meist der SHA-512-Hash, der Ersteller jeder Komponente und die Vollständigkeitsangabe der Abhängigkeiten.
Der erste Pipeline-Lauf ist oft ernüchternd und beruhigend zugleich. Auf dem Bildschirm steht eine vollständige Komponentenliste, für die vorher niemand die Hand ins Feuer gelegt hätte, und sie entsteht ab jetzt bei jedem Build von selbst.
AIWas Kunden
wirklich fragen.
Grundlagen
- Was ist eine SBOM?
- Eine SBOM (Software Bill of Materials), auf Deutsch Software-Stückliste, ist ein maschinenlesbares Inventar aller Softwarekomponenten eines Produkts: mit Version, Lizenz, Hersteller, Prüfsumme und den Abhängigkeiten untereinander. Sie funktioniert wie die Stückliste in der Fertigung. Wird für eine Komponente eine Schwachstelle bekannt, zeigt die SBOM, welche Ihrer Produkte sie enthalten.
- Was muss in einer SBOM stehen?
- Je Komponente mindestens Name, Version, Ersteller, Lizenz, eine Prüfsumme und die Abhängigkeiten, dazu für die SBOM selbst Ersteller und Zeitstempel. Die BSI TR-03183-2 verlangt zusätzlich den Dateinamen, einen SHA-512-Hash der ausgelieferten Datei und die Angabe, ob die Liste der Abhängigkeiten vollständig ist. Eine Package URL (purl) oder CPE gehört hinein, sobald es eine gibt.
- Wie sieht eine SBOM aus?
- Eine SBOM ist eine JSON- oder XML-Datei, keine Tabelle für Menschen. Oben stehen Format, Version, Ersteller und Zeitstempel, darunter eine Liste von Komponenten. Eine Komponente im CycloneDX-Format trägt Felder wie name, version, purl, licenses und hashes, etwa "purl": "pkg:npm/express@4.18.2" mit der Lizenz MIT. In SPDX heißen dieselben Angaben anders, der Inhalt ist gleich. Vollständige Beispiele in beiden Formaten und eines nach BSI TR-03183-2 zeigt dieser Artikel in den Abschnitten 03 und 07.
- Was ist die purl in einer SBOM?
- Die purl (Package URL) ist eine eindeutige Adresse für ein Softwarepaket, zum Beispiel pkg:npm/express@4.18.2 oder pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1. Sie nennt Paketquelle, Name und Version in einer Zeile. Schwachstellen-Datenbanken und Scanner gleichen Komponenten über die purl ab. Seit Dezember 2025 ist das Schema als ECMA-427 standardisiert.
- Was macht CycloneDX?
- CycloneDX ist ein Stücklisten-Standard der OWASP, gebaut für die Sicherheit der Software-Lieferkette. Er beschreibt Komponenten, Versionen, Lizenzen und Abhängigkeiten und kann im selben Dokument Schwachstellen und VEX-Bewertungen tragen. Neben Software beschreibt er auch Hardware (HBOM), Kryptografie (CBOM) und Services. CycloneDX 1.6 erschien im April 2024 und wurde im Juni 2024 als ECMA-424 standardisiert, die zweite Ausgabe vom Dezember 2025 entspricht der aktuellen Version 1.7. Erzeugen lässt es sich mit Syft, Trivy, cdxgen oder den CycloneDX-Plugins für Maven, npm und Python.
- Welches SBOM-Format sollte ich verwenden?
- Für die meisten Pipelines CycloneDX. SPDX (ISO/IEC 5962:2021) bildet Lizenzen feiner ab, CycloneDX ist auf Schwachstellen-Management ausgelegt und trägt VEX nativ. Der Cyber Resilience Act akzeptiert beide. Die BSI TR-03183-2 verlangt CycloneDX ab 1.6 oder SPDX ab 3.0.1, und hier liegt der praktische Unterschied: Trivy und der GitHub-Export schreiben SPDX nur bis 2.3, Syft schreibt SPDX 3 nur auf Anforderung, und Dependency-Track liest gar kein SPDX. Wer mit diesen Tools BSI-konform arbeiten will, landet bei CycloneDX.
- Was ist der Unterschied zwischen SBOM, HBOM und CBOM?
- Die SBOM listet Software, die HBOM (Hardware Bill of Materials) Hardware-Bauteile und die CBOM (Cryptography Bill of Materials) die kryptografischen Verfahren, Schlüssel und Zertifikate in einem Produkt. Die CBOM wird mit der Umstellung auf Post-Quanten-Kryptografie wichtiger, weil sie zeigt, wo RSA oder ECC im Einsatz sind. CycloneDX bildet alle drei im selben Format ab.
- Was ist der Unterschied zwischen SBOM und SCA?
- SCA (Software Composition Analysis) ist der Analyseprozess, der Open-Source-Komponenten in einer Software findet. Die SBOM ist das Ergebnis dieser Analyse als standardisiertes Dokument. SCA-Produkte wie Snyk oder Black Duck analysieren und können SBOMs ausgeben, SBOM-Generatoren wie Syft oder cdxgen konzentrieren sich auf das Inventar in SPDX oder CycloneDX.
Pflicht und Richtlinien
- Ist SBOM Pflicht?
- Ja. Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt in Anhang I Teil II eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten eines Produkts erfasst. Verbindlich wird das mit der vollen Geltung am 11. Dezember 2027. Das frühere Datum 11. September 2026 betrifft nur die Meldepflicht für aktiv ausgenutzte Schwachstellen. Bei Verstößen drohen bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
- Für wen gilt der Cyber Resilience Act?
- Für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden: von der vernetzten Maschine über Steuerungs-Firmware bis zur reinen Software. Entscheidend ist das Produkt, nicht die Unternehmensgröße. Ausgenommen sind unter anderem Produkte, die sektorspezifisch reguliert sind (Medizinprodukte, Kraftfahrzeuge, Luftfahrt), sowie nicht kommerziell bereitgestellte Open-Source-Software.
- Wer braucht eine SBOM?
- 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 behält Abhängigkeiten und Lizenzen im Blick, die Security bewertet neue CVEs, die Compliance führt den Nachweis gegenüber Marktaufsicht und Kunden. In der Praxis verlangt heute meist der OEM die SBOM im Liefervertrag, bevor es der Gesetzgeber tut.
- Ab wann gilt die CRA-Meldepflicht für Schwachstellen?
- Seit dem 11. September 2026. Hersteller melden eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall über die Meldeplattform der ENISA: eine Frühwarnung binnen 24 Stunden und die Meldung binnen 72 Stunden. Der Abschlussbericht folgt bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur verfügbar ist, bei Sicherheitsvorfällen binnen eines Monats nach der Meldung. Die Pflicht gilt auch für Produkte, die schon im Feld sind. Ohne aktuelle SBOM ist die 24-Stunden-Frist kaum zu halten, weil die Frage nach der Betroffenheit dann Handarbeit bleibt.
- Muss ich meine SBOM veröffentlichen?
- Nein. Der Cyber Resilience Act fordert keine Veröffentlichung. Die SBOM ist Teil der technischen Dokumentation nach Anhang VII und wird der Marktüberwachungsbehörde auf begründetes Verlangen vorgelegt. Stellen Sie die SBOM Nutzern freiwillig bereit, müssen Sie angeben, wo sie zu finden ist. OEMs und öffentliche Auftraggeber fordern SBOMs zunehmend vertraglich an, meist unter NDA.
- Was fordert die BSI TR-03183-2 für SBOMs?
- Die Technische Richtlinie BSI TR-03183-2 (Version 2.1.0 vom 20. August 2025) verlangt je Komponente Ersteller, Name, Version, Dateiname, Abhängigkeiten mit Vollständigkeitsangabe, Distributionslizenz, einen SHA-512-Hash der ausgelieferten Datei sowie die Angaben, ob die Komponente ausführbar, ein Archiv oder strukturiert ist. Für die SBOM selbst gehören Ersteller und Zeitstempel hinein. Als Format sind CycloneDX ab 1.6 und SPDX ab 3.0.1 zugelassen.
- Wie tief muss eine SBOM gehen?
- Der Cyber Resilience Act verlangt zumindest die obersten Abhängigkeiten. Die BSI TR-03183-2 geht weiter: Abhängigkeiten werden rekursiv aufgelöst, auf jedem Pfad mindestens bis zur ersten Komponente außerhalb Ihres Lieferumfangs. Ihr Anhang beschreibt dazu fünf Stufen (Top-level, n-level, Transitiv, Liefergegenstand, Vollständig), die Richtlinie selbst verlangt mindestens die Stufe Liefergegenstand. Die CISA-Mindestanforderungen von 2026 nennen gar keine Mindesttiefe mehr, sondern erwarten alle Komponenten.
- Was ist VEX und wie hängt es mit SBOM zusammen?
- VEX (Vulnerability Exploitability eXchange) sagt, ob eine bekannte Schwachstelle in Ihrem Produkt tatsächlich ausnutzbar ist. Die SBOM listet die Komponenten, der Scanner meldet alle CVEs dazu, und VEX ordnet jede Meldung einem Status zu: nicht betroffen, betroffen, behoben oder in Prüfung. CycloneDX kann VEX im selben Dokument tragen. Die BSI TR-03183-2 verlangt die Bewertung aber getrennt von der SBOM und empfiehlt dafür CSAF (OASIS-Standard, seit 2025 ISO/IEC 20153).
Tools und Pipeline
- Wie erstelle ich eine SBOM?
- In drei Schritten: Bauen Sie das Artefakt, lassen Sie ein SBOM-Tool wie Syft, Trivy oder cdxgen gegen das Container-Image oder den Quellcode laufen, und speichern Sie das Ergebnis als CycloneDX- oder SPDX-Datei zusammen mit dem Release. In der CI/CD-Pipeline läuft das nach jedem Build automatisch, etwa mit syft myapp:latest -o cyclonedx-json > sbom.cdx.json.
- Welches SBOM-Tool ist das beste?
- Es gibt kein universell bestes Tool, es kommt auf das Artefakt an. Syft ist der vielseitigste Generator für Container und Dateisysteme, Trivy erzeugt die SBOM und prüft sie im selben Tool auf Schwachstellen, cdxgen deckt die meisten Paketmanager ab und schreibt standardmäßig CycloneDX 1.7, das Microsoft SBOM Tool erzeugt SPDX 3.0. Alle vier sind Open Source.
- Wie erstelle ich eine SBOM mit Syft?
- Mit syft myapp:latest -o cyclonedx-json > sbom.cdx.json. Syft analysiert Container-Images, Verzeichnisse und Archive und schreibt standardmäßig CycloneDX 1.7, SPDX als 2.3. Die Version lässt sich festlegen, etwa mit -o cyclonedx-json@1.6 oder -o spdx-json@3.0. Für die BSI TR-03183-2 passt die CycloneDX-Ausgabe ohne Zusatz, SPDX akzeptiert die Richtlinie erst ab 3.0.1. Auf Schwachstellen prüft anschließend Grype die erzeugte Datei.
- Wie erstelle ich eine SBOM mit Trivy?
- Mit trivy image --format cyclonedx -o sbom.cdx.json myapp:latest. Trivy scannt Container-Images, Git-Repositories und Dateisysteme und schreibt das Inventar als CycloneDX. Eine vorhandene SBOM prüfen Sie mit trivy sbom sbom.cdx.json gegen bekannte CVEs. Pinnen Sie Trivy in der Pipeline auf eine feste Version oder einen Digest: Im März 2026 waren kurzzeitig manipulierte Trivy-Releases und GitHub-Action-Tags im Umlauf.
- Was ist der Unterschied zwischen Syft und Grype?
- Syft erzeugt die SBOM, Grype prüft sie. Beide stammen von Anchore. Syft inventarisiert, was in einem Image oder Verzeichnis steckt, Grype gleicht dieses Inventar mit Schwachstellen-Datenbanken ab und bricht mit --fail-on critical den Build ab, wenn es eine kritische CVE findet. In der Pipeline laufen sie nacheinander: syft erzeugt sbom.cdx.json, grype sbom:sbom.cdx.json prüft sie.
- Wie erstelle ich eine SBOM für ein Docker-Image?
- Am einfachsten mit syft IMAGE oder trivy image --format cyclonedx IMAGE. Docker selbst bietet zwei Wege: docker scout sbom IMAGE gibt die SBOM eines fertigen Images aus, und docker buildx build --sbom=true hängt sie beim Bauen als SPDX-Attestation an das Image. Den älteren Befehl docker sbom hat Docker entfernt. In GitHub Actions erledigt das die Action anchore/sbom-action.
- Kann ich eine SBOM direkt aus GitHub oder GitLab erzeugen?
- Ja. GitHub exportiert aus dem Dependency Graph eine SPDX-2.3-Datei, GitLab erzeugt mit Dependency Scanning einen CycloneDX-Report als Job-Artefakt. Für einen ersten Überblick reicht das. Für die BSI TR-03183-2 ist SPDX 2.3 zu alt, und beide Exporte 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.
- Wie prüfe ich, ob meine SBOM gültig ist?
- In zwei Stufen. Formal prüft die CycloneDX-CLI mit cyclonedx validate --input-file sbom.cdx.json gegen das Schema, für SPDX übernimmt das pyspdxtools. Inhaltlich prüfen Sie gegen die Pflichtfelder der BSI TR-03183-2: Fehlen Ersteller, Dateiname, SHA-512-Hash oder die Vollständigkeitsangabe der Abhängigkeiten, ist die Datei zwar gültiges JSON, aber keine TR-konforme SBOM.
- Wo kann ich eine SBOM gegen CVE-Datenbanken prüfen?
- Einmalig und lokal mit grype sbom:sbom.cdx.json oder trivy sbom sbom.cdx.json. Dauerhaft mit OWASP Dependency-Track: Sie laden die SBOM jedes Releases hoch, und die Plattform gleicht sie laufend gegen neue Schwachstellen ab, auch Jahre nach der Auslieferung. Dependency-Track liest nur CycloneDX, kein SPDX, und läuft seit Version 5.0 (Juni 2026) als Container mit PostgreSQL.
- Wie oft sollte eine SBOM aktualisiert werden?
- Bei jedem Build. Ist die Erzeugung Teil der Pipeline, bekommt jedes Release seine SBOM ohne Zusatzaufwand. Für Produkte im Feld gilt: Jede ausgelieferte Version behält ihre eigene SBOM, und jedes Security-Update erzeugt eine neue.
- Was kostet die Einführung von SBOM?
- Die Tools sind Open Source und kostenlos. Der Aufwand liegt in der ersten Integration in die Pipeline, typischerweise ein bis drei Tage je Pipeline, und in den Regeln, ab welcher Schwachstelle oder Lizenz der Build anhält. Teurer wird es bei SPS-Projekten und Firmware ohne Paketmanager, wo die Komponentenliste erst entstehen muss.
Industrie und Embedded
- Wie erstelle ich eine SBOM für eine Maschine?
- Als Stückliste aus Stücklisten. Jede Baugruppe mit Software bekommt ihre eigene SBOM: SPS-Programm, HMI, Industrie-PC, Antriebs-Firmware, zugekaufte Geräte. Die SBOM der Maschine verweist auf diese Einzel-SBOMs. Die BSI TR-03183-2 erlaubt solche Verweise, wenn die referenzierten SBOMs selbst TR-konform sind. Für deren Verfügbarkeit bleibt der Maschinenhersteller verantwortlich, deshalb gehört die SBOM-Lieferung in jeden Zuliefervertrag.
- Wie erstelle ich eine SBOM für CODESYS oder TIA Portal?
- Mit Syft oder Trivy geht es nicht, weil die Projektformate proprietär sind. Der Scan läuft durch und meldet keine Komponenten. Einen dokumentierten SBOM-Export für Anwenderprojekte haben wir bei beiden bislang nicht gefunden (Stand Oktober 2026). Die Stückliste entsteht über eigene Extraktoren, die Bibliotheken und Bausteine mit Version und Herkunft auslesen, bei TIA Portal über die Openness-Schnittstelle, bei CODESYS über die Scripting-Schnittstelle, und das Ergebnis als CycloneDX schreiben. Die Laufzeitumgebung ist davon getrennt: Die Linux-Runtime-Pakete von CODESYS bringen seit Version 4.15 eine eigene SBOM mit.
- Kann ich SBOMs für Embedded-Software erstellen?
- Ja. Mit Yocto entsteht die SBOM im Build: Seit Version 5.1 schreibt Yocto SPDX 3.0, seit 6.0 (Mai 2026) nur noch SPDX 3. Buildroot erzeugt CycloneDX mit make show-info | utils/generate-cyclonedx. Bei Firmware ohne Betriebssystem, etwa mit IAR oder STM32Cube, gibt es keinen Paketmanager, den ein Tool auslesen könnte. Dort pflegen Sie HAL, RTOS, Middleware und Compiler-Laufzeit als versionierte Komponentenliste im Repository und erzeugen daraus die SBOM.
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.
Verwandte Artikel
EU Cyber Resilience Act im Maschinenbau
Was der CRA für Maschinenbauer bedeutet: Anforderungen, Fristen und Umsetzungsstrategien.
IEC 62443 in der Praxis: DevSecOps für OT
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.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance