Du willst wissen, was in deiner Software steckt? Erfahre, wie eine Software Bill of Materials (SBOM) dir hilft, Sicherheitslücken schneller zu erkennen – und warum wir auf CycloneDX setzen.
Ein Sicherheitsmangel in einem Bauteil – und sofort steht fest, welche Produkte betroffen sind. Für Hersteller im Maschinenbau ist das Alltag. Die Stückliste, die sogenannte „Bill of Materials“, macht es möglich.
Sie listet alle Einzelteile eines Produkts auf und schafft so volle Transparenz über die Zusammensetzung.
In der Softwareentwicklung hingegen fehlt diese Transparenz häufig. Dabei stehen Hersteller und Betreiber vor ähnlichen Herausforderungen: Auch hier treten regelmäßig Sicherheitslücken auf – in Frameworks, Bibliotheken oder Drittkomponenten.
Die Lösung? Eine Software Bill of Materials (SBOM). Sie überträgt das bewährte Prinzip der Stückliste auf Softwareprodukte und ermöglicht es, Sicherheitsrisiken frühzeitig zu erkennen und gezielt zu handeln.
Warum eine „Software Bill of Materials“
Wie das vorangegangene Beispiel zeigt, ist die „Bill of Materials“ in Branchen wie dem Maschinenbau bereits seit Jahrzehnten nicht wegzudenken. In der IT-Branche ist die Bereitstellung einer „Software Bill of Materials“ (SBOM) jedoch noch nicht sehr verbreitet. Jedoch steht die IT-Branche vor der gleichen Herausforderung wie der Maschinenbau. Es treten ebenfalls Sicherheitsmängel in verwendeten Bibliotheken und Frameworks auf. Diese Sicherheitsmängel werden bereits seit Jahren veröffentlicht, jedoch haben Betreiber sowie Hersteller von IT-Systemen oft keine Transparenz über die verwendeten Bibliotheken und Frameworks. Dies erschwert es zielgerichtet Gegenmaßnahmen gegen Sicherheitslücken zu ergreifen.
Der „Cyber Resilience Act“1 der EU hat sich zum Ziel gesetzt dies zu ändern. Das „Bundesamt für Sicherheit in der Informationstechnik“ hat die technische Richtlinie „BSI TR-03183-2 Software Bill of Materials (SBOM)“2 bereitgestellt. In dieser Richtlinie werden die Rahmenbedingen für eine „Software Bill of Materials“ definiert.
SBOM Standards im Überblick: CycloneDX &SPDX
Wie soll nun die „Software Bill of Materials“ meiner Produkte konkret aussehen? Diese Frage stellen sich nicht nur die Hersteller von Produkten mit digitalen Inhalten, sondern natürlich auch die Betreiber dieser Produkte. Gerade die Betreiber hatten in der Vergangenheit oft die Herausforderung, wenn eine Sicherheitslücke auftrat zu prüfen ob ihre Systeme betroffen waren. Oft war dies nicht direkt möglich, sondern man musste sich auf Sicherheitsmanagement des Lieferanten verlassen. Dies ändert sich nun. Mit der Einführung der „Software Bill of Materials“ verfügen beide Parteien über die Transparenz bezügliche der vorhanden Software-Abhängigkeiten.
Aus diesem Grund sieht die technische Richtline BSI-TR-03183-2 nun die zwei Formate CycloneDX3 und Software Package Data Exchange (SPDX)4 vor. Somit ist klar definiert, welche Formate Anwendung finden. Dies hat zwei Vorteile:
Betreiber von Produkten können gezielt eines der Formate von allen Lieferanten einfordern.
Lieferanten können sich auf ein Format konzentrieren und ihr Prozesse darauf abstimmen.
Warum wir bei doubleSlash auf CycloneDX setzen
Bei doubleSlash haben wir uns für die Nutzung des CycloneDX Format entschieden. Es gibt dafür im Wesentlichen drei Gründe für uns:
Grund 1 – Klar strukturiertes Format:
Grundsätzlich soll die „Software Bill of Materials“ maschinenlesbar sein. Dies ist mit dem gewählten Format in jedem Fall möglich. Neben der Maschinenlesbarkeit ist es auch für den Menschen lesbar, denn es ist gut strukturiert und verständlich.
Grund 2 – Erweiterbarkeit
Beim Thema Erweiterbarkeit kommen zwei Arten von Erweiterbarkeit zum Tragen. Zum einen bietet das CycloneDX Format die Möglichkeit an einigen Stellen benutzerdefinierte Properties zu definieren. Dies ermöglicht weiterführende Informationen zu hinterlegen.
Zum anderen lassen sich mit den CycloneDX Format nicht nur „Software Bill of Materials“ erstellen. Es lassen sich auch „Cryptography Bill of Materials“ (CBOM) für kryptografische Assets oder „Vulnerability Disclosure Records“ (VDR) erstellen. Dies erleichtert die einheitliche Nutzung eines Formats für verschiedene Verwendungszwecke.
Grund 3 – Großes Angebot an Werkzeugen
Es existiert eine große Anzahl von Applikationen und Werkzeugen, die das CycloneDX Format erstellen und verarbeiten können. Dies macht es zu einer guten Wahl. Sowohl die Entwickler, Hersteller sowie die Betreiber von Produkten mit digitalen Inhalten haben die Möglichkeit die „Software Bill of Materials“ mit ihren Werkzeugen zu verarbeiten.
Fazit: Transparenz schafft Sicherheit für alle Beteiligten
Die Software Bill of Materials ist ein bedeutender Schritt hin zu mehr Cybersicherheit. Sie schafft eine neue Form der Transparenz über den gesamten Software-Lebenszyklus hinweg – und das für alle Beteiligten: Entwickler:innen, Hersteller digitaler Produkte und deren Betreiber.
Kommt es zu einer Sicherheitslücke, lässt sich schnell und eindeutig klären, ob und welche Software betroffen ist.
Entwickler:innen können bereits während der Entwicklung prüfen, ob das geplante oder bereits veröffentlichte Release angreifbar ist.
Hersteller wiederum haben die Möglichkeit, ihre Kunden gezielt und proaktiv über Schwachstellen in Komponenten zu informieren – inklusive konkreter Sicherheitshinweise (Advisories).
Auch Betreiber profitieren: Sie können bei Bekanntwerden einer Schwachstelle sofort prüfen, ob ihre Systeme betroffen sind, und geeignete Maßnahmen ergreifen – noch bevor ein Patch verfügbar ist.Die SBOM ermöglicht dadurch ein deutlich schnelleres und gezielteres Handeln bei sicherheitsrelevanten Vorfällen.
Kurz gesagt: Sie bringt mehr Verantwortung, mehr Transparenz – und vor allem mehr Sicherheit.
Der Beitrag Transparenz in der Softwareentwicklung: Die „Software Bill of Materials“ erschien zuerst auf Business -Software- und IT-Blog – Wir gestalten digitale Wertschöpfung.
