{"id":11520,"date":"2026-10-20T14:29:53","date_gmt":"2026-10-20T12:29:53","guid":{"rendered":"https:\/\/erminas.com\/?p=11520"},"modified":"2026-10-14T14:53:56","modified_gmt":"2026-10-14T12:53:56","slug":"sbom-erstellen-mit-cdxgen-einstieg-und-qualitaetspruefung","status":"publish","type":"post","link":"https:\/\/erminas.com\/de\/blog\/sbom-erstellen-mit-cdxgen-einstieg-und-qualitaetspruefung\/","title":{"rendered":"SBOM erstellen mit cdxgen: Einstieg und Qualit\u00e4tspr\u00fcfung"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Wer eine SBOM erstellen m\u00f6chte, braucht einen klar abgegrenzten Softwarestand und einen passenden Generator. Ein Softwareprojekt enth\u00e4lt mehrere Bibliotheken und weitere Abh\u00e4ngigkeiten, die diese Bibliotheken mitbringen. Wie l\u00e4sst sich dieser Bestand als maschinenlesbare SBOM erfassen? Dieser Beitrag f\u00fchrt von der Auswahl des untersuchten Softwarestands \u00fcber den Generatoraufruf bis zur Pr\u00fcfung der entstandenen Datei.<\/p>\n\n

Eine SBOM, kurz f\u00fcr Software Bill of Materials, erfasst Softwarekomponenten und ihre Abh\u00e4ngigkeiten in strukturierter Form. In unserem Vortrag \u201eCRA \u2013 SBOM \u2013 Wie Software-St\u00fccklisten wirklich in Entwicklung und Betrieb ankommen\u201c zeigen unsere Experten und Referenten Ruben Brick und Yvette Teiken, wie solche Daten erzeugt und im Entwicklungs- und Sicherheitsprozess genutzt werden k\u00f6nnen. Die Live-Demo f\u00fchrt vom .NET-Projekt zur CycloneDX-Datei und weiter zur Auswertung in Dependency-Track.<\/p>\n\n

Warum diese Transparenz im Unternehmensalltag wichtig ist, erl\u00e4utert unser Beitrag \u201eCybersicherheit ist nicht nur etwas f\u00fcr Tech-Giganten \u2013 KMU m\u00fcssen jetzt handeln\u201c<\/a>. Hier geht es um die technische Umsetzung: Welche Eingabedaten braucht die Erzeugung, was liefert cdxgen und wie pr\u00fcfen Sie das Ergebnis?<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Welche Informationen eine SBOM enthalten sollte<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein brauchbares Inventar beschreibt nicht nur die Anwendung selbst. Es erfasst auch ihre direkten und transitiven Abh\u00e4ngigkeiten. Direkte Abh\u00e4ngigkeiten bindet das Entwicklungsteam ausdr\u00fccklich ein. Transitive Abh\u00e4ngigkeiten gelangen \u00fcber andere Pakete in das Projekt.<\/p>

Die erzeugte JSON-Datei l\u00e4sst sich in einem Editor \u00f6ffnen. Bei vielen Komponenten und verschachtelten Abh\u00e4ngigkeiten wird eine manuelle Pr\u00fcfung jedoch schnell aufwendig. Analysewerkzeuge bereiten diese Daten so auf, dass sich Komponenten und ihre Beziehungen gezielter untersuchen lassen.<\/p>

F\u00fcr die sp\u00e4tere Untersuchung sind insbesondere die Namen und Versionen der Komponenten sowie ihre Beziehungen relevant. Kennungen wie eine Package URL, kurz PURL, helfen dabei, ein Paket seinem \u00d6kosystem zuzuordnen. Lizenzinformationen k\u00f6nnen einen weiteren Anwendungsfall unterst\u00fctzen: die Pr\u00fcfung der im Produkt verwendeten Softwarelizenzen.<\/p>

F\u00fcr den Einstieg lohnt sich eine klare Abgrenzung: Beschreibt die SBOM ein Quellcodeprojekt, einen konkreten Build oder ein ausgeliefertes Artefakt? Diese Frage bestimmt, welche Bestandteile erwartet werden. Eine Analyse des Projekts ist nicht automatisch ein vollst\u00e4ndiges Inventar des sp\u00e4teren Containers oder der gesamten Kundeninstallation.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

SBOM erstellen mit cdxgen: das .NET-Beispiel<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In der Live-Demo kommt cdxgen zum Einsatz. Das Werkzeug unterst\u00fctzt die Erzeugung von CycloneDX-SBOMs f\u00fcr unterschiedliche Technologien. Voraussetzung f\u00fcr das folgende Beispiel sind ein eingerichtetes cdxgen und eine zum .NET-Projekt passende Entwicklungsumgebung.<\/p>\n\n

Ein Aufruf entsprechend der Demo sieht so aus:<\/p>\n\n

cdxgen -t dotnet --spec-version 1.7 --json-pretty -o sbom.cdx.json<\/code><\/pre>\n\n
Der Befehl wird im Projektverzeichnis ausgef\u00fchrt. -t dotnet<\/code> legt den Projekttyp fest, --spec-version 1.7<\/code> die gew\u00fcnschte CycloneDX-Version und -o<\/code> den Namen der Ausgabedatei. Bei einer lokal bereitgestellten ausf\u00fchrbaren Datei kann der Aufruf mit .\/cdxgen<\/code> beginnen, wie im Vortrag gezeigt.<\/p>\n\n
Die Aufnahme zeigt ein konkretes Ergebnis: cdxgen erkennt 16 Komponenten, meldet eine erfolgreiche Validierung und schreibt die Datei sbom.cdx.json<\/code>. Diese Zahl geh\u00f6rt zum Demo-Projekt; sie ist kein Erwartungswert f\u00fcr andere Anwendungen. Welche Voraussetzungen und Optionen f\u00fcr das eigene Projekt gelten, beschreibt die offizielle cdxgen-Dokumentation<\/a>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Eine g\u00fcltige Datei ist noch keine vollst\u00e4ndige SBOM<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Nach der Generierung beginnt die Qualit\u00e4tspr\u00fcfung. Eine erfolgreiche Schema-Validierung best\u00e4tigt, dass die Datei dem gepr\u00fcften Format entspricht. Ob alle relevanten Bestandteile erfasst wurden, muss zus\u00e4tzlich gepr\u00fcft werden.<\/p>
Ein sinnvoller erster Test ist der Vergleich mit bekannten Projektabh\u00e4ngigkeiten: Tauchen bewusst eingebaute Pakete mit den erwarteten Versionen auf? Sind indirekte Abh\u00e4ngigkeiten erkennbar? L\u00e4sst sich die Datei dem richtigen Produktstand zuordnen? Auff\u00e4llige L\u00fccken sollten untersucht werden, bevor die Daten an ein Analysewerkzeug weitergegeben werden.<\/p>
Auch das Ausgabeformat muss zur weiteren Verarbeitung passen. Im Vortrag werden SPDX und CycloneDX als Standards vorgestellt. F\u00fcr die gezeigte Verarbeitung in Dependency-Track wird CycloneDX verwendet. Die Wahl sollte sich deshalb an der gesamten Werkzeugkette orientieren und nicht nur daran, welches Format ein Generator standardm\u00e4\u00dfig ausgibt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Mit einem \u00fcberschaubaren Projekt beginnen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
<\/p>
F\u00fcr einen ersten Versuch eignet sich eine Anwendung, deren Abh\u00e4ngigkeiten das Team gut kennt. So lassen sich die erzeugten Daten leichter \u00fcberpr\u00fcfen. Dokumentieren Sie dabei den verwendeten Generator, seine Konfiguration und den untersuchten Softwarestand. Das erleichtert die Wiederholung und die sp\u00e4tere \u00dcbernahme in den Build-Prozess.<\/p>
Mit einer \u00fcberpr\u00fcften SBOM ist die Grundlage gelegt. Im n\u00e4chsten Schritt sollte ihre Erzeugung regelm\u00e4\u00dfig und verl\u00e4sslich erfolgen. Wie daraus ein fester Bestandteil der Entwicklung wird, zeigt unser Beitrag \u201eSBOM in den Entwicklungsprozess integrieren: von der Datei zum CI\/CD-Workflow\u201c<\/strong>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Quellen und weiterf\u00fchrende Informationen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t