Wer eine SBOM erstellen möchte, braucht einen klar abgegrenzten Softwarestand und einen passenden Generator. Ein Softwareprojekt enthält mehrere Bibliotheken und weitere Abhängigkeiten, die diese Bibliotheken mitbringen. Wie lässt sich dieser Bestand als maschinenlesbare SBOM erfassen? Dieser Beitrag führt von der Auswahl des untersuchten Softwarestands über den Generatoraufruf bis zur Prüfung der entstandenen Datei.
Eine SBOM, kurz für Software Bill of Materials, erfasst Softwarekomponenten und ihre Abhängigkeiten in strukturierter Form. In unserem Vortrag „CRA – SBOM – Wie Software-Stücklisten wirklich in Entwicklung und Betrieb ankommen“ zeigen unsere Experten und Referenten Ruben Brick und Yvette Teiken, wie solche Daten erzeugt und im Entwicklungs- und Sicherheitsprozess genutzt werden können. Die Live-Demo führt vom .NET-Projekt zur CycloneDX-Datei und weiter zur Auswertung in Dependency-Track.
Warum diese Transparenz im Unternehmensalltag wichtig ist, erläutert unser Beitrag „Cybersicherheit ist nicht nur etwas für Tech-Giganten – KMU müssen jetzt handeln“. Hier geht es um die technische Umsetzung: Welche Eingabedaten braucht die Erzeugung, was liefert cdxgen und wie prüfen Sie das Ergebnis?
Welche Informationen eine SBOM enthalten sollte
Ein brauchbares Inventar beschreibt nicht nur die Anwendung selbst. Es erfasst auch ihre direkten und transitiven Abhängigkeiten. Direkte Abhängigkeiten bindet das Entwicklungsteam ausdrücklich ein. Transitive Abhängigkeiten gelangen über andere Pakete in das Projekt.
Die erzeugte JSON-Datei lässt sich in einem Editor öffnen. Bei vielen Komponenten und verschachtelten Abhängigkeiten wird eine manuelle Prüfung jedoch schnell aufwendig. Analysewerkzeuge bereiten diese Daten so auf, dass sich Komponenten und ihre Beziehungen gezielter untersuchen lassen.
Für die spätere 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 Ökosystem zuzuordnen. Lizenzinformationen können einen weiteren Anwendungsfall unterstützen: die Prüfung der im Produkt verwendeten Softwarelizenzen.
Für 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ändiges Inventar des späteren Containers oder der gesamten Kundeninstallation.
SBOM erstellen mit cdxgen: das .NET-Beispiel
In der Live-Demo kommt cdxgen zum Einsatz. Das Werkzeug unterstützt die Erzeugung von CycloneDX-SBOMs für unterschiedliche Technologien. Voraussetzung für das folgende Beispiel sind ein eingerichtetes cdxgen und eine zum .NET-Projekt passende Entwicklungsumgebung.
Ein Aufruf entsprechend der Demo sieht so aus:
cdxgen -t dotnet --spec-version 1.7 --json-pretty -o sbom.cdx.jsonDer Befehl wird im Projektverzeichnis ausgeführt. -t dotnet legt den Projekttyp fest, --spec-version 1.7 die gewünschte CycloneDX-Version und -o den Namen der Ausgabedatei. Bei einer lokal bereitgestellten ausführbaren Datei kann der Aufruf mit ./cdxgen beginnen, wie im Vortrag gezeigt.
Die Aufnahme zeigt ein konkretes Ergebnis: cdxgen erkennt 16 Komponenten, meldet eine erfolgreiche Validierung und schreibt die Datei sbom.cdx.json. Diese Zahl gehört zum Demo-Projekt; sie ist kein Erwartungswert für andere Anwendungen. Welche Voraussetzungen und Optionen für das eigene Projekt gelten, beschreibt die offizielle cdxgen-Dokumentation.
Eine gültige Datei ist noch keine vollständige SBOM
Nach der Generierung beginnt die Qualitätsprüfung. Eine erfolgreiche Schema-Validierung bestätigt, dass die Datei dem geprüften Format entspricht. Ob alle relevanten Bestandteile erfasst wurden, muss zusätzlich geprüft werden.
Ein sinnvoller erster Test ist der Vergleich mit bekannten Projektabhängigkeiten: Tauchen bewusst eingebaute Pakete mit den erwarteten Versionen auf? Sind indirekte Abhängigkeiten erkennbar? Lässt sich die Datei dem richtigen Produktstand zuordnen? Auffällige Lücken sollten untersucht werden, bevor die Daten an ein Analysewerkzeug weitergegeben werden.
Auch das Ausgabeformat muss zur weiteren Verarbeitung passen. Im Vortrag werden SPDX und CycloneDX als Standards vorgestellt. Für 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äßig ausgibt.
Mit einem überschaubaren Projekt beginnen
Für einen ersten Versuch eignet sich eine Anwendung, deren Abhängigkeiten das Team gut kennt. So lassen sich die erzeugten Daten leichter überprüfen. Dokumentieren Sie dabei den verwendeten Generator, seine Konfiguration und den untersuchten Softwarestand. Das erleichtert die Wiederholung und die spätere Übernahme in den Build-Prozess.
Mit einer überprüften SBOM ist die Grundlage gelegt. Im nächsten Schritt sollte ihre Erzeugung regelmäßig und verlässlich erfolgen. Wie daraus ein fester Bestandteil der Entwicklung wird, zeigt unser Beitrag „SBOM in den Entwicklungsprozess integrieren: von der Datei zum CI/CD-Workflow“.
Quellen und weiterführende Informationen
- Vortrag und Live-Demo, insbesondere 28:31–30:16.
- cdxgen: offizielle Projektdokumentation.
- OWASP CycloneDX: Authoritative Guide to SBOM.
