Wie lässt sich eine SBOM in der Praxis nutzen? Dieser Frage widmen sich unsere beiden Experten und Referenten Ruben Brick und Yvette Teiken im Vortrag „CRA – SBOM – Wie Software-Stücklisten wirklich in Entwicklung und Betrieb ankommen“. Sie verbinden die technischen Grundlagen von SBOMs mit Fragen zum Umgang mit Schwachstellen in Entwicklung und Betrieb.
Die Live-Demo macht die Arbeitsschritte konkret: Für eine .NET-Anwendung wird eine CycloneDX-SBOM erzeugt und als JSON-Datei geöffnet. Anschließend zeigt Dependency-Track die enthaltenen Komponenten und zugeordnete Sicherheitsbefunde. Damit wird nachvollziehbar, wie aus den strukturierten Daten Informationen für die weitere Untersuchung entstehen.
Der Rückblick knüpft an zwei bestehende Beiträge an: „Cybersicherheit ist nicht nur etwas für Tech-Giganten – KMU müssen jetzt handeln“ behandelt Verantwortung und Strukturen im Unternehmen. „CVD: So gehen Sie professionell mit Sicherheitslücken um“ erläutert den koordinierten Umgang mit externen Meldungen. Der Vortrag ergänzt diese Perspektiven um die praktische Arbeit mit SBOMs.
Aus diesem Zusammenspiel ergeben sich fünf Erkenntnisse für Teams, die SBOMs in Entwicklung und Betrieb einsetzen möchten.
1. Eine SBOM erfasst auch transitive Abhängigkeiten
Die erste Erkenntnis betrifft den Softwarebestand selbst. Eine Anwendung besteht aus mehr als den unmittelbar eingebundenen Paketen. Auch diese Pakete hängen von weiteren Komponenten ab. Der Vortrag veranschaulicht solche transitiven Abhängigkeiten mit einem mehrstufigen Abhängigkeitsbaum.
Eine SBOM macht diese Zusammensetzung nachvollziehbar. Für ein Entwicklungsteam entsteht dadurch eine gemeinsame Informationsgrundlage: Welche Komponenten sind enthalten, in welchen Versionen und mit welchen Beziehungen? Diese Transparenz unterstützt die Untersuchung von Sicherheitsmeldungen ebenso wie Incident Response und Lizenzprüfung.
Das ist besonders relevant, wenn eine Meldung eine Bibliothek betrifft, die niemand bewusst als direkte Abhängigkeit eingebaut hat. Entscheidend ist dann der tatsächliche Bestand des untersuchten Softwarestands. Die SBOM hilft, diesen Bestand gezielt zu prüfen, statt ihn erst im Vorfall mühsam zu rekonstruieren.
2. SBOMs gehören in den Entwicklungsprozess
Die Live-Demo zeigt einen greifbaren Einstieg: cdxgen erzeugt eine CycloneDX-Datei für das .NET-Projekt, erkennt 16 Komponenten und meldet eine erfolgreiche Validierung. Das Ergebnis ist sichtbar und kann anschließend weiterverarbeitet werden.
Für den dauerhaften Einsatz reicht ein einmaliger lokaler Aufruf jedoch nicht aus. Mit jeder relevanten Änderung kann sich die Zusammensetzung der Software verändern. Die im Vortrag vorgestellte CI/CD-Folie verbindet deshalb die Anwendung, Azure DevOps und Dependency-Track zu einem durchgängigen Vorgehensmodell.
Die praktische Konsequenz: Erzeugung, Prüfung und Zuordnung der SBOM sollten regelmäßig und reproduzierbar erfolgen. Besonders für ausgelieferte Releases muss erkennbar bleiben, welche SBOM zu welcher Version gehört. So können auch ältere Produktstände untersucht werden, wenn später neue Sicherheitsinformationen auftauchen.
3. Standards und Tools machen SBOM-Daten praktisch nutzbar
Die erzeugte SBOM liegt in der Demo als JSON-Datei vor. Sie enthält strukturierte Angaben zu Komponenten, Versionen und Abhängigkeiten. Diese Angaben lassen sich zwar manuell lesen, bei umfangreichen Projekten ist das Nachvollziehen der Zusammenhänge jedoch mühsam und zeitaufwendig.
Hier greifen Standards und Werkzeuge ineinander. SPDX und CycloneDX legen fest, wie SBOM-Informationen strukturiert beschrieben werden. Ein Analysewerkzeug kann ein unterstütztes Format einlesen und die Daten gezielt aufbereiten. In der Demo wird dafür eine CycloneDX-SBOM mit Dependency-Track ausgewertet. Die Komponenten erscheinen dort mit ihren Versionen in einer übersichtlichen Oberfläche.
Der praktische Vorteil liegt darin, den Softwarebestand schneller durchsuchen und Zusammenhänge untersuchen zu können. Voraussetzung bleiben korrekte Daten: Namen, Versionen und Kennungen wie PURL oder CPE unterstützen die Zuordnung der Komponenten. Eine übersichtliche Darstellung kann fehlende oder falsche Angaben in der SBOM nicht ausgleichen.
4. SBOMs unterstützen die Analyse konkreter Schwachstellen
In der Live-Demo wird das .NET-Beispielprojekt in Dependency-Track geöffnet. Dort sind die erfassten Komponenten mit ihren Versionen, Hinweise auf veraltete Pakete und zugeordnete Schwachstellen sichtbar. Anschließend wird ein als „Critical“ eingestufter Befund für NuGet.Packaging 6.8.0 geöffnet. Die Detailansicht zeigt die Beschreibung der Schwachstelle und den CVSS-Vektor.
Damit wird die Rolle einer SBOM im Schwachstellenmanagement anschaulich. Ein Inventar lässt sich mit Sicherheitsinformationen zusammenführen und unterstützt die Frage, welche Bestandteile näher untersucht werden müssen. Eine allgemeine Meldung erhält so einen Bezug zum eigenen Projekt.
Der Befund ist dennoch keine fertige Entscheidung. Die Schwere einer Schwachstelle und ihre konkrete Auswirkung im eigenen Produkt müssen gemeinsam betrachtet werden. Analysewerkzeuge liefern Hinweise; Entwicklung und Security müssen daraus eine nachvollziehbare Bewertung ableiten.
5. SBOM-Daten müssen mit dem Produktbetrieb verbunden werden
Die Abschlussfolie ordnet die weitere Arbeit in vier Fragenfelder ein: Betroffenheit, Patchstatus, Threat Model und Kommunikation. Damit wird die Grenze der technischen Demo deutlich: Ein Komponentenfund allein beantwortet noch nicht, welche Kundeninstallation betroffen ist oder ob eine korrigierte Version bereits dort läuft.
Für die Umsetzung müssen daher Release-Informationen, eingesetzte Produktstände und die Bewertung des Befunds zusammengeführt werden. Die SBOM trägt das Inventar bei. Der operative Rahmen für Patchstatus und Kundenkommunikation wird im verlinkten KMU-Beitrag vertieft; die Abstimmung bei externen Meldungen im CVD-Beitrag.
Die fünfte Erkenntnis liegt in dieser Verbindung: Gute Daten müssen die zuständigen Stellen erreichen und in konkrete Entscheidungen einfließen. Die gezeigten Werkzeuge liefern dafür einen technischen Ausgangspunkt.
SBOM in der Praxis: vom Softwarebestand zur Entscheidung
Der Vortrag macht sichtbar, wie die einzelnen Schritte zusammenwirken: cdxgen erzeugt die SBOM, Dependency-Track ordnet den enthaltenen Komponenten Sicherheitsbefunde zu, und die anschließende Bewertung berücksichtigt den Einsatz im konkreten Produkt. Jeder Schritt baut auf den Informationen des vorherigen auf.
Für Entwicklungsteams liegt der Nutzen darin, Sicherheitsfragen anhand eines nachvollziehbaren Softwarebestands untersuchen zu können. Welche Abhängigkeit bringt ein betroffenes Paket mit? Welche Produktversion enthält es? Und welche Voraussetzungen des Advisorys treffen auf die eigene Anwendung zu? Eine gepflegte SBOM schafft die Datengrundlage für diese Untersuchung und hilft, Entscheidungen gegenüber Betrieb und Kunden zu begründen.
Die vollständige Aufzeichnung zeigt, wie unsere Experten Ruben Brick und Yvette Teiken diese Themen anhand der .NET-Live-Demo veranschaulichen. In den kommenden Blogbeiträgen vertiefen wir die einzelnen Schritte: die Erstellung einer SBOM, ihre Integration in den Entwicklungsprozess und ihre Nutzung im Vulnerability Management.
