Warum SBOM-Generierung 2026 unverzichtbar geworden ist
Die Nachwehen von Log4Shell kosteten Unternehmen geschätzte 100 Millionen US-Dollar für Notfallmaßnahmen. SolarWinds hat bewiesen, dass eine einzige kompromittierte Abhängigkeit Tausende nachgelagerte Systeme gefährden kann. Im Jahr 2026 verlangen der aktualisierte U.S. Executive Order zur Cybersicherheit, NIST SP 800-218 und der EU Cyber Resilience Act von Softwareanbietern in regulierten Sektoren die Erstellung eines Software Bill of Materials. SBOM-Generierung ist von einem optionalen Audit-Artefakt zu einer harten Compliance-Anforderung geworden.
Wer Software liefert und die Frage Welche Komponenten stecken in diesem Build? nicht binnen Minuten beantworten kann, hat ein Supply-Chain-Problem. Dieser Leitfaden deckt Formate, Tools und Pipeline-Muster ab, inklusive konkreter Beispiele mit dem Microsoft SBOM Tool und den SBOM-Generierungsfähigkeiten von Snyk.
SBOM-Formate: SPDX vs. CycloneDX
Es gibt zwei dominierende SBOM-Formate. SPDX in Version 2.3 ist der ISO/IEC 5962:2021-Standard. CycloneDX, gepflegt von OWASP, befand sich Mitte 2026 bei Version 1.6. Beide serialisieren nach JSON, XML und Tag-Value-Text. CycloneDX bietet bessere native VEX-Unterstützung und passt besser in CI/CD-Pipelines. SPDX hat stärkere Verbreitung im US-Bundesbeschaffungsbereich. Für moderne DevSecOps-Workflows punktet CycloneDX mit besserer Tooling-Ergonomie.
SPDX SBOM Generator Optionen
Für reinen SPDX-Output unterstützt der offizielle spdx-sbom-generator CLI Go, Java, Node.js, Python, Ruby, Rust, PHP und .NET. Er analysiert Dependency-Manifests und erzeugt ein konformes SPDX-Dokument. Caveat: Er deckt nur manifest-deklarierte Abhängigkeiten ab, keine Transitivabhängigkeiten in Container-Layern.
Das Microsoft SBOM Tool: Was es wirklich leistet
Microsoft hat ihre interne SBOM-Toolchain 2022 als microsoft/sbom-tool Open Source gestellt. Bis 2026 ist es ein ausgereiftes, produktionsreifes CLI für Azure DevOps und GitHub Actions. Es erzeugt SPDX 2.2-konforme Dokumente und wird intern für Windows, Azure und Microsoft 365 eingesetzt.
Microsoft SBOM Tool Beispiel
Für ein Node.js-Projekt wird das Tool mit dotnet tool install --global Microsoft.Sbom.DotnetTool installiert und dann wie folgt ausgeführt:
sbom-tool generate -b ./build-output -bc ./src -pn MyService -pv 1.4.2 -ps MyOrg -nsb https://myorg.com/sbom
Das Microsoft SBOM Tool unterstützt NuGet, npm, PyPI, Maven, Gradle, Go Modules, CocoaPods und Ruby Gems in einem Durchlauf, einschließlich Komponenten, die nicht in einer Lockfile stehen, aber als kompilierte DLLs vorhanden sind. Das ist eine bedeutsame Abdeckungserweiterung gegenüber manifest-basierten Tools.
Snyk SBOM-Generierung: Developer-First mit Schwachstellenkontext
Snyk SBOM-Generierung erzeugt CycloneDX- oder SPDX-Dokumente angereichert mit Snyks Schwachstellendatenbank. Der entscheidende Unterschied: andere SBOM-Tools erstellen ein Komponenteninventar. Snyk erstellt ein Komponenteninventar plus bekannte CVEs, Ausnutzbarkeitsdaten und Fix-Verfügbarkeit, alles inline im gleichen Dokument. Diese Integration passt nahtlos in Vulnerability-Management-Workflows.
Weitere SBOM-Generatoren 2026
Syft (Anchore)
Syft ist der am weitesten verbreitete Open-Source-SBOM-Generator für Container. syft myimage:latest -o spdx-json liefert ein SPDX-Dokument über OS-Pakete, Sprachpakete und Binärklassifikation. Unsere Container Image Scanning-Funktionen bauen auf diesem Ansatz auf.
Trivy (Aqua Security)
Trivy verdient Erwähnung als vollwertiger SBOM-Generator mit Unterstützung für OCI-Artefakt-Attestierung — der SBOM wird als OCI-Manifest neben dem Image gepusht und beim Admission-Control verifiziert.
SBOM-Generierung in der DevSecOps-Pipeline
Einmalig einen SBOM generieren und ablegen ist Schaufensterdekoration. Der Wert liegt in kontinuierlicher SBOM-Generierung, gebunden an jeden Build und jedes Release. Diese Pipeline-Hygiene ist zentral für eine reife Code Security-Haltung. Für Teams mit Kubernetes-Workloads schafft die Kombination von SBOM-Generierung und SAST-Pipeline eine zweischichtige Verteidigung.
SBOM-Generierung für Compliance
Artikel 13 des EU Cyber Resilience Act verlangt von Herstellern digitaler Produkte SBOMs für alle eingebetteten Komponenten. NIST SP 800-218 SSDF 1.1 ordnet die SBOM-Erstellung der PW.4-Praxis zu. Der Compliance-Aspekt bei SBOMs wächst kontinuierlich: bei SOC 2 Type II, ISO 27001:2022 oder NIS2 sind dokumentierte Software-Kompositionspraktiken zunehmend Teil von Prüfer-Evidenzpaketen.
SBOM-Speicherung, Signierung und Verteilung
Einen SBOM zu generieren ist nur Schritt eins. Drei Muster dominieren 2026: OCI Artifact Attachment, OWASP Dependency-Track und kommerzielle Plattformen wie SECRAILS. Signierung ist kritisch: ein unsignierter SBOM ist eine Textdatei, die jeder modifizieren könnte. Sigstore cosign ermöglicht schlüssellose Signaturen über OIDC-CI-Identität.
Häufige Fehler bei der SBOM-Generierung
Wiederkehrende Fehler: nur Quell-Manifests scannen statt finaler Build-Artefakte, transitive Abhängigkeiten ignorieren, SBOMs zur Scan-Zeit statt Build-Zeit generieren, und SBOMs nicht aktuell halten. Ergänzen Sie Ihre SBOM-Pipeline mit VM Scans für Laufzeitumgebungen, um die Lücke zwischen geliefertem und betriebenem Stand zu schließen.
Der Weg nach vorne
Die nächste Evolutionsstufe sind abfragbare, vergleichbare und aktionierbare SBOMs quer über die gesamte Flotte. Die Tools sind vorhanden, die Formate stabil, der regulatorische Druck real. Was den meisten Organisationen fehlt, ist die operative Disziplin, SBOMs im Maßstab zu generieren, zu speichern, zu signieren und abzufragen.