Definition
Eine Software Bill of Materials, kurz SBOM oder im Deutschen auch manchmal “Software-Stückliste” genannt, ist eine Liste aller Komponenten und Abhängigkeiten, die in einer Anwendung verwendet werden. Eine SBOM ist eine Bestandsaufnahme aller Module, Bibliotheken, Abhängigkeiten, ML-Modelle, Datensätze oder anderer Komponenten, die Entwickler in eine Anwendung integrieren oder die für die Ausführung der Anwendung vorhanden sein müssen.
Übersicht
In Hinblick auf Softwareentwicklung kann man eine Software Bill of Materials (SBOM) in etwa mit den Inhalts- und Nährwertangaben auf der Seite einer Konservendose vergleichen.
Denn so ähnlich wie dort, muss man, um die Sicherheit von Software gewährleisten zu können, wissen, welche Komponenten bei der Entwicklung der Software verwendet wurden. Aus diesem Grund sollten Entwickler-, Operation- und Security-Teams darauf bestehen für jede Version ihrer Software eine SBOM zu erstellen, um Sicherheitslücken identifizieren und beheben zu können, sowie die Verwendung von Komponenten für Lizenzierungs- und regulatorische Anforderungen zu dokumentieren.
Wie die Zutaten auf einem Etikett enthalten SBOMs eine detaillierte Liste aller Komponenten, die mit einer bestimmten Softwareversion verbunden sind, einschließlich potenzieller Schwachstellen und Lizenzinformationen.
Wie funktioniert eine SBOM?
In der Regel werden SBOMs während der Build-Phase im Softwareentwicklungsprozesses generiert. In dieser Phase wird die Software aus dem Quellcode in ausführbare Programme oder andere Komponenten kompiliert und zusammengestellt. Die Erstellung einer Software Bill of Materials zu diesem Zeitpunkt ermöglicht eine detaillierte und genaue Auflistung aller in der Software enthaltenen Komponenten, Bibliotheken und Abhängigkeiten. Und das ist entscheidend, um die Herkunft zu verfolgen und die Sicherheit aller in der Software verwendeten Komponenten zu gewährleisten.
Die folgenden Schritte beschreiben den typischen Prozess zur Erstellung einer SBOM:
- Identifizierung der Komponenten – Die Entwickler selbst oder Tools identifizieren alle in der Software verwendeten Komponenten und Ressourcen, inklusive Bibliotheken, Frameworks, Module und Abhängigkeiten. Das kann manuell oder mithilfe automatisierter Tools erfolgen, die die Codebasis scannen und daraus eine komplette Liste erstellen.
- Versionierung und Metadata – Jede Komponente in der SBOM ist mit Metadaten wie Versionsnummer, Lizenzinformationen und Abhängigkeiten verknüpft. Diese Metadaten sind wichtig, um Schwachstellen zu verfolgen, die Einhaltung von Lizenzvereinbarungen sicherzustellen und Updates und Patches zu verwalten.
- Formate und Standards – SBOMs können in verschiedenen Formaten wie SPDX (Software Package Data Exchange) oder CycloneDX dargestellt werden. SPDX ist ein weit verbreiteter Standard zur Dokumentation der Inhalte und Lizenzen von Softwarepaketen.
- Distribution und gemeinsame Nutzung – SBOMs können von verschiedenen Beteiligten in der Software-Lieferkette gemeinsam genutzt werden, darunter Entwickler, Anbieter, Kunden und Aufsichtsbehörden. Diese gemeinsame Nutzung fördert Transparenz, Zusammenarbeit und Verantwortlichkeit bei der Softwareentwicklung, -bereitstellung und Compliance Vorgaben.
- Integration in Tools und Prozesse – SBOMs können in verschiedene Softwareentwicklungs- und Securitytools und -prozesse integriert werden. Sie können beispielsweise von Schwachstellen-Scannern verwendet werden, um bekannte Sicherheitslücken in Softwarekomponenten zu identifizieren, oder von Compliance-Tools um die Einhaltung von Lizenzanforderungen sicherzustellen.
- Laufendes Monitoring und Updates – Weil sich Software ständig weiterentwickelt, müssen auch SBOMs regelmäßig aktualisiert werden, um Änderungen in der Zusammensetzung der Software widerzuspiegeln. Dazu gehört das Hinzufügen neuer Komponenten, das Aktualisieren verwendeter Versionen und das Entfernen veralteter oder anfälliger Komponenten.
Die meisten SBOMs sind klar strukturiert und folgen Formatierungsstandards wie SPDX oder CycloneDX, um verschachtelte Inventare der Inhalte der Software-Lieferkette einer Anwendung darzustellen. Hier sind Beispiele für die Struktur gängiger Formate:
SPDX
Bei der aktuellen Implementierung zur Erstellung eines SPDX-Berichts sind folgende Felder erforderlich:
- Paketname
- Paket-Version
- Erkannte Lizenzen
- Erkannte Prüfsummen wenn möglich
So sollte das dann im Report aussehen:
PackageName: PyYAML SPDXID: SPDXRef-Package-PyYAML-3.10 PackageVersion: 3.10 PackageDownloadLocation: NOASSERTION FilesAnalyzed: false PackageChecksum: SHA256: 3d8ee7cc23fef4279e6a0a46ea8df14f2bfe09703dd1e67b465bca5d4b500602 PackageHomePage: NOASSERTION PackageLicenseConcluded: MIT PackageLicenseDeclared: NOASSERTION PackageCopyrightText: NOASSERTION
CycloneDX
Eine CycloneDX-Implementierung stellt die allgemeinen Metadaten des Berichts bereit, die Informationen wie die Cyclone DX-Version, den Autor und das Erstellungsdatum des Berichts enthalten. Sie umfasst auch detaillierte Komponenteninformationen für jede der erkannten Komponenten und deren Schwachstelleninformationen (VEX).
"type": "application",
"name": "ubuntu:bionic:libsqlite3-0",
"version": "3.22.0-1ubuntu0.4",
"hashes": [
{
"alg": "SHA-256",
"content": "1c0f71e7796c1ddb8527b9b052f9948fc8a2c1e8e9c89b084bcc36100f966714"
}
],
"licenses": [
{
"license": {
"id": "GPL-2.0",
"url": "http://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html"
}
}
]
}
Hier ist ein Beispiel dafür, wie eine SBOM Beispiel-Datei in einer Application verwendet werden kann:
<?xml version="1.0" encoding="utf-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2"
serialNumber="urn:uuid:d6aa76fa-e488-480d-9ad0-f67765dfd015"
version="1">
<metadata>
<timestamp>2020-08-03T03:19:55.999Z</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>Node.js module</name>
<version>2.0.0</version>
</tool>
</tools>
<component type="library" bom-ref="pkg:npm/juice-shop@11.1.2">
<name>juice-shop</name>
<version>11.1.2</version>
<description>
<![CDATA[Probably the most modern and sophisticated insecure web application]]>
</description>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/juice-shop@11.1.2</purl>
<externalReferences>
<reference type="website">
<url>https://owasp-juice.shop</url>
</reference>
<reference type="issue-tracker">
<url>https://github.com/bkimminich/juice-shop/issues</url>
</reference>
<reference type="vcs">
<url>git+https://github.com/bkimminich/juice-shop.git</url>
</reference>
</externalReferences>
</component>
</metadata>
Durch das Parsen des XML-Codes liefert diese SBOM nicht nur Details darüber, welche Komponenten in der Anwendung vorhanden sind, sondern auch Metadaten zu den Versionen und URLs, die mit jeder Komponente verknüpft sind.
Welche Rollen spielt eine SBOM?
Für eine schnelle und skalierbare Erstellung sicherer und hochwertiger Software ist eine umfassende Zusammenarbeit zwischen Entwicklungs-, Betriebs- und Sicherheitsteams erforderlich. Eine SBOM ist ein vielseitiges Tool, das während des gesamten Softwareentwicklungslebenszyklus (SDLC) als Single Source of Truth dient. Im Folgenden sind die verschiedenen Rollen aufgeführt, die das SBOM in verschiedenen Teams und Aspekten der Softwareentwicklung und -bereitstellung übernimmt.
Software Supply Chain
Die Gewährleistung von Transparenz und Rückverfolgbarkeit von Softwarekomponenten von der Entwicklung bis zur Bereitstellung hilft dabei, die Herkunft jeder Komponente zu ermitteln und sicherzustellen, dass nur verifizierte und sichere Komponenten verwendet werden. Wenn eine Schwachstelle ausgenutzt wird, kann sie schnell zurückverfolgt und behoben werden, um den Schaden zu minimieren.
Security
Als wichtige Referenz für Sicherheit und DevSecOps trägt eine Software Bill of Materials dazu bei, dass alle Softwarekomponenten sicher und konform sind, bevor sie Teil des Codes werden. Durch die Auflistung aller Komponenten und ihrer Versionen können Teams Schwachstellen frühzeitig im Entwicklungsprozess identifizieren und beheben, was ein kontinuierliches Sicherheitsmonitoring und eine schnelle Reaktionen auf Sicherheitsbedrohungen ermöglicht.
DevOps
Durch die Automatisierung und Überwachung von Entwicklungsprozessen liefert eine SBOM detaillierte Informationen über Softwarekomponenten und ermöglicht so eine effiziente Nachverfolgung von Updates, Abhängigkeiten und potenziellen Risiken. Diese Informationen sind für die Aufrechterhaltung der Stabilität und Zuverlässigkeit der Software während der kontinuierlichen Integration und kontinuierlichen Bereitstellung über CI/CD-Pipelines von entscheidender Bedeutung.
Cloud Native
In Cloud-nativen Umgebungen wird eine SBOM zur Verwaltung und Sicherung verschiedener Mikroservices und containerisierter Anwendungen verwendet. Sie stellt sicher, dass alle in der Cloud ausgeführten Komponenten dokumentiert und sicher sind. Dies ist insbesondere in dynamischen und skalierbaren Cloud-nativen Architekturen wichtig, in denen sich Komponenten recht häufig ändern können.
Lizenzierung und Compliance
Als integraler Bestandteil des Lizenzmanagements und der Sicherstellung der Compliance bietet eine SBOM eine detaillierte Auflistung aller Softwarekomponenten, einschließlich Bibliotheken und Abhängigkeiten, zusammen mit ihren jeweiligen Lizenzbedingungen. Dank dieser Transparenz können DevOps überprüfen, ob jede Komponente auch gemäß ihrer Lizenz verwendet wird, und somit potenzielle rechtliche Probleme vermeiden.
Software-Stücklisten sind auch für die Einhaltung regulatorischer Standards unerlässlich, die die Offenlegung von Softwarekomponenten aus Sicherheits- und Datenschutzgründen vorschreiben können. Dies ist besonders wichtig in regulierten Branchen wie dem Gesundheitswesen, dem Finanzsektor und kritischen Infrastrukturen, in denen die Nichteinhaltung dieser Vorschriften zu empfindlichen Strafen führen kann.
| Zentrale Aufgaben einer SBOM bei der Sicherung der Software-Lieferkette | |
| Aufgabe | Beschreibung |
| Übersicht & Transparenz | SBOMs bieten einen vollständigen Überblick über die Komponenten, aus denen eine Softwareanwendung besteht. Diese Transparenz hilft Sicherheitsteams zu verstehen, was in ihrer Software enthalten ist, und ermöglicht ihnen ein effektiveres Risikomanagement. |
| Schwachstellen-Management | Durch die Auflistung aller Komponenten und ihrer Versionen helfen SBOMs dabei, bekannte Schwachstellen in diesen Komponenten zu identifizieren. Dadurch können Unternehmen Schwachstellen schnell beheben und patchen, und so das Risiko, dass sie ausgenutzt werden, reduzieren. |
| Compliance und regulatorische Vorgaben | Viele regulatorische Rahmenbedingungen und Standards wie NIST, ISO und andere verlangen von Unternehmen, dass sie ein Verzeichnis der Softwarekomponenten führen. Eine SBOM hilft bei der Erfüllung dieser Compliance-Anforderungen, indem sie eine strukturierte Möglichkeit bietet, die Einhaltung dieser Vorgaben zu belegen.. |
| Risko-Management | Das Wissen um die Komponenten in einer Softwareanwendung hilft bei der Bewertung des mit jeder Komponente verbundenen Risikos. Dazu gehört auch die Bewertung der Sicherheit von Bibliotheken von Drittanbietern und Open-Source-Komponenten. |
| Incident Response | Im Falle eines Security-Vorfalls kann eine SBOM die Reaktion auf den Vorfall beschleunigen, indem rasch ermittelt werden kann, welche Komponenten von einer bestimmten Schwachstelle betroffen sind und welcher Entwickler dafür verantwortlich ist, was eine schnellere Lösung ermöglicht. |
| Bessere Sicherheit | Software Bills of Materials erhöhen die Sicherheit der Software-Lieferkette, weil sie Transparenz in Hinblick auf Komponenten von Drittanbietern schaffen und die mit Software-Lieferketten verbundenen Sicherheitsrisiken verwalten, inklusive Third-Party- und Open-Source-Software. |
| Software Integrity | SBOMs helfen, die Integrität und Herkunft von Softwarekomponenten zu überprüfen. Dadurch wird sichergestellt, dass alle verwendeten Komponenten legitim und nicht manipuliert sind, was die Sicherheit der Anwendung insgesamt erhöht. |
| Verbesserte Wartbarkeit | Mit einer klaren Aufstellung der Komponenten wird es einfacher, Wartungsarbeiten und Updates der Software zu verwalten. SBOMs tragen dazu bei, dass alle Artefakte auf dem neuesten Stand sind und auf Sicherheitslücken gescannt wurden, wodurch das Risiko einer Ausnutzung aufgrund veralteter Versionen bestimmter Komponenten verringert wird. |
Warum sind SBOMs wichtig?
Die Software Bill of Materials spielt eine entscheidende Rolle in der Softwareentwicklung, da sie als übersichtliche Inventarliste dient, das jede Softwarekomponente, Bibliothek und Abhängigkeit zusammen mit ihren Lizenzinformationen detailliert auflistet. Sie spielen auch eine wichtige Rolle bei der Einhaltung von regulatorische Standards und helfen Organisationen, die Komplexität sowohl rechtlicher als auch der betrieblicher Integrität in Bezug auf die Prozesse der Softwareentwicklung zu bewältigen.
Single Source of Truth
Je schneller man feststellen kann, ob und wie sich eine Schwachstelle auf eine Anwendung und deren Betriebsumgebung auswirkt, desto geringer ist das Risiko einer tatsächlichen Sicherheitsverletzung. Eine „Single Source of Truth“ erlaubt es, Schwachstellen in der Lieferkette viel schneller und effizienter zu identifizieren und zu beheben als mit alternativen Methoden. Im Falle einer Sicherheitsverletzung kann eine schnelle Reaktionszeit, die durch eine SBOM ermöglicht wird, ein Unternehmen vor erheblichen wirtschaftlichen Schäden bewahren.
Verbesserte Sicherheit
Entdeckt ein Softwareentwickler oder externer Researcher ein Sicherheitsprobleme in einer Software, werden Informationen über diese Schwachstellen in der Regel in öffentlichen Datenbanken wie der NIST National Vulnerability Database veröffentlicht. Sodass Informationen über bekannte Schwachstellen öffentlich verfügbar sind.
In den meisten Fällen gibt es allerdings keine einfache Möglichkeit, das direkt in den Anwendungen selbst zu tun. Man kann nicht einfach einen Befehl ausführen, um eine Anwendung zu fragen, ob sie eine bestimmte Bibliothek verwendet. Zwar kann man Anwendungen scannen, um Abhängigkeiten und andere Komponenten zu identifizieren, aber das Scannen kann ein zeitaufwändiger Prozess sein, der nicht einfach skalierbar ist, sodass Unternehmen nicht immer die Zeit haben, Veröffentlichungstermine einzuhalten und gleichzeitig kritische Sicherheitsrisiken zu identifizieren, bevor Angreifer sie ausnutzen.
SBOMs lösen dieses Problem, indem sie in eine Überblick über die Komponenten geben, die innerhalb der Lieferkette einer Anwendung vorhanden sind. Mit diesen Informationen können DevOps- und Sicherheitsteams schnell feststellen, ob bekannte Schwachstellen Auswirkungen auf Komponenten in ihren Anwendungen haben.
SBOM Best Practices
Software Bills of Materials tragen zwar wesentlich dazu bei, die Sichtbarkeit von Software-Lieferketten zu verbessern und die Einführung potenzieller Sicherheitslücken zu verhindern, doch reicht es nicht aus, beim Erstellen einer neuen App einfach nur eine SBOM zu erstellen, und davon auszugehen, dass damit Sicherheitsrisiken minimiert sind. Darüber hinaus sollte man stets auch die folgenden Schritte unternehmen, um die Effizient von SBOMs sicherzustellen:
- Ständige Updates – Applications werden ständig weiterentwickelt, und entsprechend müssen auch die SBOMs permanent geupdated werden. Wenn man Komponenten oder Abhängigkeiten von Anwendungen hinzufügt oder entfernt – oder auch nur die Version einer Komponente ändert – sollte man auch die SBOM entsprechend aktualisieren.
- Automatisierte Erstellung – SBOMs können zwar manuell erstellt werden, was aber zeitaufwendig, schwer skalierbar und ineffizient ist. Außerdem können dabei leicht Dinge übersehen werden oder sich Fehler aufgrund menschlichen Versagens einschleichen. Für eine größere Sicherheit sollten SBOMs deshalb automatisch generiert werden, indem Anwendungen gescannt werden, um ihre Inhalte zu identifizieren, und dann automatisch SBOMs auf der Grundlage der identifizierten Komponenten erstellt werden.
- Rich Metadata – Je mehr Daten über Versionen, Quellen und Schwachstellen in der SBOM enthalten sind, desto nützlicher ist eine Software Bill of Materials in kritischen Situationen. In vielen Fällen ist der Kontext, der durch die Metadaten bereitgestellt wird, entscheidend, um schnell herauszufinden, ob eine bestimmte Schwachstelle tatsächlich ausnutzbar ist und wie sie behoben werden kann.
- Konsistenz – SBOMs können auf unterschiedliche Art und Weise formatiert werden. Es lohnt sich daher, die Vor- und Nachteile der einzelnen Formate zu prüfen und zu entscheiden, welches Format für das eigene Projekt am besten geeignet ist. Sobald man sich für eine bestimmte Struktur entschieden hat, sollte man aber Konsistenz in Bezug auf das Format und die Datentypen wahren, die für eine effiziente SBOM-Erstellung und Nutzung erforderlich sind.
JFrog’s SBOM Solution
Eine saubere Verwaltung einer Software-Stückliste (SBOM) war aus Sicherheits- und Compliance-Sicht schon immer Best-Practice. Im Hinblick auf Ankündigungen der US-Regierung wie der Europäischen Union hat das Thema aber zuletzt noch mehr Relevanz erhalten.
Im Oktober 2023 erließ das Weiße Haus eine Executive Order , die KI-Entwicklern vorschreibt, der US-Regierung detaillierte Informationen über die Zusammensetzung ihrer Anwendungen zur Verfügung zu stellen, bevor sie diese für die Öffentlichkeit freigeben. Ebenso verpflichtet der Digital Operational Resilience Act (DORA) der EU, der voraussichtlich 2025 in Kraft treten wird, Finanzinstitute dazu, den Inhalt ihrer Softwareanwendungen offenzulegen, um die operative Widerstandsfähigkeit digitaler Finanzdienstleistungen zu verbessern.
Ob nun aus Compliance- oder Sicherheitsgründen – es ist wichtig, dass SBOMs in einem gemeinsamen, standardisierten Format bereitgestellt werden. Zu diesem Zweck unterstützt JFrog Xray SPDX, CycloneDX und andere Standardformate, die zur Erstellung einer maschinenlesbaren Datei führen, in der das Inventar der Softwarekomponenten und -abhängigkeiten aufgeführt ist. Das Wichtigste ist, dass Sie Ihre SBOM-Anforderungen verstehen und in dasjenige Format exportieren, das für Ihre Anwendung am sinnvollsten ist.
Wenn es um die Verwaltung Ihrer Softwareanwendungen über den gesamten Softwareentwicklungszyklus hinweg geht, ist die JFrog Platform die universelle Software-Lieferkettenlösung für DevOps, DevSecOps und MLOps. Sie umfasst mehr als 50 Integrationen, die die meisten der gängigen Tools im Ökosystem abdecken und eine automatisierte, integrierte, erweiterbare und sichere Verwaltung der gesamten Software-Lieferkette ermöglichen.
Wenn Sie mehr über SBOMs wissen möchten, inklusive wie sie über die JFrog-Plattform erstellt und verwaltet werden können, vereinbaren Sie einfach eine Demo oder starten Sie einen kostenlosen Test.
