Software Bill of Materials (SBOM)

Was ist eine Software Bill of Materials (SBOM)?

Eine Software Bill of Materials (SBOM) ist eine Inventarliste aller Komponenten und Software-Abhängigkeiten, die Teil der Entwicklung und Bereitstellung einer Software sind. Sie ist eine zunehmend verbreitete und wichtige Komponente des Software Development Lifecycle (SDLC) und der DevSecOps-Prozesse.

Moderne Softwareanwendungen und -dienste werden in der Regel mit mehreren Komponenten und Abhängigkeiten erstellt, die aus unterschiedlichen Quellen stammen. Zu diesen Komponenten und Abhängigkeiten können Open-Source-Softwareprojekte, proprietärer Code, APIs, Programmiersprachen-Frameworks und Softwarebibliotheken gehören. Die verschiedenen Quellen, aus denen sich moderne Software zusammensetzt, sind Teil der Softwarelieferkette und dienen als Bezugsquellen für die Bereitstellung von Anwendungen und Diensten.

Eine Software Bill of Materials ist vergleichbar mit einer Stückliste, wie sie in Lieferketten und in der Fertigung verwendet wird. In der IT-Branche ist es jedoch nicht bei allen Anbietern üblich, die grundlegenden Codekomponenten, auf denen eine Anwendung aufbaut, genau zu beschreiben.

Eine SBOM bietet Einblick in die internen Grundlagen einer Software, damit Unternehmen und Benutzer besser verstehen, was verwendet wird und wo ein potenzielles Risiko besteht.

Was beinhaltet eine Software Bill of Materials?

Die grundlegende Ebene einer SBOM ist eine Bestandsaufnahme der Quellkomponenten und Abhängigkeiten in einer bestimmten Anwendung oder einem Online-Dienst. Zu den Quellkomponenten gehört eine Auflistung der gemeinsam genutzten Objekte, wie zum Beispiel Dynamic Link Libraries (DLL), auf die eine Anwendung zugreift, um zu funktionieren. SBOM umfasst auch Softwarebibliotheken für verschiedene Funktionen und anwendungsabhängigen Open-Source-Code. Jede Verwendung oder Abhängigkeit von Middleware-Komponenten und Programmier-Frameworks, auf denen eine Anwendung arbeitet, muss in einer vollständigen SBOM-Inventarliste aufgeführt werden.

Eine SBOM sollte ebenfalls Informationen darüber enthalten, woher die Komponenten stammen. Bei der modernen Softwareentwicklung ist es häufig so, dass ein Teil des Anwendungscodes von einem anderen abhängig ist. Daher wird ein Abhängigkeitsbaum benötigt, um einen Einblick in die grundlegenden Komponenten einer Anwendung zu erlauben.

Im Juli 2021 gab die US-Behörde National Telecommunications and Information Administration (NTIA) in einem Bericht (PDF) Leitlinien heraus, in denen die Mindestanforderungen für ein SBOM aufgeführt sind, darunter die drei grundlegenden Bereiche:

• Datenfelder. Der Teil Datenfelder einer SBOM ist die Asset-Inventarkomponente, die den Abhängigkeitsbaum für eine Anwendung umreißt. Die Felder sollten den Namen der Komponente, die Version, die Lizenzinformationen und den Namen des Lieferanten sowie die Urheberschaft und einen Zeitstempel für den Zeitpunkt der Erstellung der SBOM-Daten enthalten.
• Automatisierung. Angesichts der Komplexität moderner Softwareentwicklungsprozesse ist es nicht ratsam, eine SBOM manuell zu erstellen. Daher empfiehlt die NTIA ein Mindestmaß an Automatisierung für die SBOM-Erstellung und den Datentransfer, so dass andere Systeme die SBOM-Daten verstehen und nutzen können.
• Prozesse. Eine SBOM erfordert die richtigen Prozesse, um die fortlaufende Erfassung von Daten zu ermöglichen. Außerdem muss definiert werden, wie SBOMs erstellt werden und wie auf sie zugegriffen wird.

Warum brauchen Unternehmen eine Software Bill of Materials?

Da sich Unternehmen zunehmend auf Software verlassen, um geschäftskritische Vorgänge auszuführen, ist eine SBOM unabdingbar.

Wenn Softwareschwachstellen entdeckt werden, sind sie oft in Komponenten zu finden, die von anderen Anwendungen abhängig sind. Zu wissen, ob ein Unternehmen durch eine Komponente eines Drittanbieters gefährdet ist, ist eine Herausforderung, die als Lieferkettenrisiko bezeichnet wird.

Viele Unternehmen stehen vor der Herausforderung, herauszufinden, ob sie durch eine bestimmte Softwareschwachstelle gefährdet sind. Die kryptografische Bibliothek OpenSSL zum Beispiel ist Bestandteil unzähliger Anwendungen. Als 2014 die Heartbleed-Schwachstelle bekannt wurde, mussten alle Anwendungen und Dienste, die von OpenSSL abhängig waren, aktualisiert werden. Die gleiche Art von Risiko wurde auch durch die Open-Source-Softwareschwachstelle Log4J aufgedeckt, die im Dezember 2021 bekannt wurde. Selbst nachdem eine Quellkomponente oder Bibliothek vom ursprünglichen Projekt gepatcht wurde, müssen alle nachgelagerten Anbieter, die sich auf die Komponente verlassen, und alle Endnutzer ebenfalls patchen.

Eine SBOM unterstützt nicht nur bei der Suche nach Risiken in der Softwarelieferkette, sondern kann Unternehmen auch bei der Einhaltung von Open-Source-Softwarelizenzen unterstützen. Verschiedene Open-Source-Lizenzen können Nutzungsbeschränkungen enthalten oder von Unternehmen verlangen, dass sie alle Änderungen am Quellcode weitergeben. Eine gut strukturierte SBOM zeigt nicht nur die zugrunde liegenden Open-Source-Softwareabhängigkeiten auf, sondern auch, welche Lizenzbeschränkungen bestehen.

Im Februar 2022 veröffentlichte die Linux Foundation einen Bericht mit dem Titel The State of Software Bill of Materials and Cybersecurity Readiness, aus dem hervorging, dass 78 Prozent der 412 weltweit befragten Unternehmen beabsichtigen, SBOM einzuführen.

Wie man eine Software Bill of Materials aufstellt

Eine Software Bill of Materials kann während des Entwicklungsprozesses einer Softwareanwendung erstellt werden. Es gibt mehrere Tools, die sich in die CI/CD-Technologie (Continuous Integration/Continuous Development) integrieren lassen, um eine SBOM als Teil einer Entwicklungspipeline zu erstellen.

Ein anderer Ansatz zur Erstellung einer SBOM ist die Verwendung von Software Composition Analysis (SCA) Tools, die die Komponenten jeder Anwendung identifizieren können. SCA-Scans können nach Fertigstellung einer Anwendung oder sogar während der Anwendungsentwicklung durchgeführt werden.

Sowohl für Entwickler als auch für Endanwender, die einen Überblick über die Risiken in der Lieferkette haben möchten oder benötigen, ist es wichtig, ein branchenübliches Formular für den SBOM-Datenaustausch zu verwenden. Unabhängig davon, ob das Unternehmen eine SBOM während der Entwicklung – mit einem SCA-Tool oder auf andere Weise – erstellt, müssen die SBOM-Daten in einem portablen und verständlichen Format vorliegen, damit sie in anderen Anwendungen verwendet werden können.

Einer der Industriestandards für SBOM ist ISO/IEC 5962:2021 für die Software Package Data Exchange (SPDX) Spezifikation. SBOMs, die im SPDX-Format geschrieben sind, können in Schwachstellen-, Risiko- und Patch-Management-Technologien verwendet werden, um zu verstehen, welche Softwarekomponenten in einem Unternehmen verwendet werden.

Die NTIA hat außerdem ein Projekt entwickelt, das als Software Identification (SWID) Tagging bekannt ist, um den Teil der Datenfelder einer SBOM bereitzustellen. CycloneDX, das vom Open Web Application Security Project (OWASP) entwickelt wurde, ist ein weiterer gängiger Standard zur Unterstützung von Unternehmen bei der Entwicklung von SBOM-Manifesten.