Die Software Bill of Materials (SBOM) ist eine Liste aller Komponenten, Bibliotheken und anderen Abhängigkeiten, die in einer Softwareanwendung verwendet werden. Zu den Standardformaten für SBOMs gehören SPDX, CycloneDX und CPE (Common Platform Enumeration). Diese Formate bieten eine strukturierte Möglichkeit zur Darstellung der Komponenten und Abhängigkeiten in einer Softwareanwendung und erleichtern so das Verständnis und die Verwaltung der mit diesen Komponenten verbundenen Sicherheitsrisiken.
In diesem Artikel erklären wir ausführlich, welche verschiedenen SBOM-Formate und -Standards es gibt, was eine SBOM beinhalten sollte und warum alle Unternehmen sie verwenden müssen.
Was ist ein SBOM-Standard?
Die Komplexität und Dynamik der Lieferketten moderner Softwaresysteme stellen eine erhebliche Herausforderung für die Transparenz dar. Dieser Mangel an Transparenz trägt zu Cybersicherheitsrisiken bei und erhöht die mit Entwicklung, Beschaffung und Wartung verbundenen Kosten. Die Folgen davon sind weitreichend und betreffen nicht nur Unternehmen, sondern auch kollektive Angelegenheiten wie die öffentliche Sicherheit und die nationale Sicherheit in unserer vernetzten Welt.
Erhöhte Transparenz in Software-Lieferketten kann zu einer Reduzierung der Cybersicherheitsrisiken und -kosten führen, indem:
- Verbesserung der Identifizierung anfälliger Systeme und Ermittlung der Grundursache von Vorfällen
- Weniger ungeplante und unproduktive Arbeit
- Ermöglicht eine fundiertere Marktdifferenzierung und Komponentenauswahl
- Die branchenübergreifende Standardisierung von Formaten führt zu einer Reduzierung von Doppelarbeit
- Erkennung verdächtiger oder gefälschter Softwarekomponenten
Das Sammeln und Teilen dieser Informationen in einem klaren und einheitlichen Format kann dazu beitragen, Kosten zu senken, die Zuverlässigkeit zu verbessern und das Vertrauen in unsere digitale Infrastruktur zu stärken.
Zu diesem Zweck, die NTIA Software Transparency Working Group für Standards und Formate wurde 2018 gegründet, um aktuelle Formate für Software-Stücklisten zu bewerten und potenzielle zukünftige Verwendungsmöglichkeiten zu identifizieren. Die Gruppe untersuchte bestehende Standards und Initiativen im Zusammenhang mit der Identifizierung externer Komponenten und gemeinsam genutzter Bibliotheken, die in Softwareprodukten verwendet werden, und der Kommunikation dieser Informationen in einem maschinenlesbaren Format. Die Gruppe berücksichtigte keine proprietären Formate. Die ursprüngliche Umfrage wurde Ende 2019 veröffentlicht und 2021 aktualisiert, wobei der Schwerpunkt auf der Hervorhebung der Vorteile des SBOM-Tooling-Ökosystems und der Bedeutung der Koordination und Harmonisierung in der technischen SBOM-Welt lag. Die wichtigste Erkenntnis besteht darin, dass SBOM-Daten in verschiedenen Formaten übermittelt werden können und das Ökosystem die Interoperabilität zwischen ihnen unterstützen sollte.
Die Arbeitsgruppe stellte fest, dass drei Formate häufig verwendet werden:
- Software Package Data Exchange (SPDX®), ein maschinenlesbares Open-Source-Format, das von der Linux Foundation entwickelt wurde und jetzt ein ISO/IEC-Standard ist
- CycloneDX (CDX), ein maschinenlesbares Open-Source-Format, das von der OWASP-Community entwickelt wurde
- Software Identification (SWID), ein ISO/IEC-Industriestandard, der von verschiedenen kommerziellen Softwareherstellern verwendet wird
Es ist erwähnenswert, dass diese drei Formate einige gemeinsame Informationen aufweisen. Sie werden jedoch traditionell in verschiedenen Phasen des Softwareentwicklungsprozesses eingesetzt und sind für unterschiedliche Zielgruppen gedacht. Wir werden jedes dieser Formate in diesem Artikel ausführlich besprechen.
Was sollte eine SBOM enthalten?
Die Mindestkomponenten des NTIA Die Elemente einer SBOM werden als Elemente bezeichnet und bestehen aus drei großen und miteinander verbundenen Bereichen. Diese Elemente ermöglichen einen flexiblen Ansatz zur Softwaretransparenz, der sowohl die Technologie als auch den funktionalen Betrieb berücksichtigt. Weitere Details oder technische Weiterentwicklungen können in Zukunft hinzugefügt werden. Wie bereits erwähnt, sind dies derzeit die Mindestkomponenten, und Organisationen benötigen möglicherweise mehr. Die Fähigkeit zur Transparenz in der Software-Lieferkette kann sich im Laufe der Zeit verbessern und weiterentwickeln.
Diese minimal erforderliche Elemente für SBOM werden typischerweise in drei Kategorien eingeteilt:
- Datenfelder: Eine SBOM sollte wichtige Daten zu Softwarekomponenten enthalten, z. B. Komponentenname, Lieferantenname, Version und eindeutige Kennungen. Es sollte auch Informationen über Abhängigkeiten zwischen Komponenten enthalten, um eine genaue Identifizierung und Verfolgung aller Softwarekomponenten in der gesamten Lieferkette zu ermöglichen.
- Praktiken und Prozesse: Die SBOM-Dokumentation sollte auch Standardpraktiken und -verfahren für die Erstellung und Aktualisierung der SBOM, deren Verteilung und Zugriff sowie den Umgang mit Fehlern beschreiben.
- Automatisierungsunterstützung: Die Software-Stückliste sollte sowohl maschinenlesbar als auch automatisch generiert werden können, um eine kontinuierliche Datenverfolgung zu ermöglichen. Typischerweise liegen sie in Standardformaten wie SPDX-, CycloneDX- und SWID-Tags vor, die sie auch für Menschen lesbar machen.
SPDX SBOM-Standardformat
Die SPDX®-Spezifikation (Software Package Data Exchange) ist ein ISO/IEC-Standard für den Austausch von Informationen über Softwarekomponenten, Lizenzen, Urheberrechte und Sicherheitsdetails in mehreren Dateiformaten. Dieses Projekt hat eine Reihe von Datenaustauschstandards entwickelt und verbessert diese weiterhin, die es Unternehmen und Organisationen ermöglichen, Software-Metadaten in einem Format auszutauschen, das sowohl für Menschen als auch für Maschinen verständlich ist, wodurch die Prozesse der Software-Lieferkette vereinfacht werden.
SPDX-Informationen können mit bestimmten Softwareprodukten, Komponenten oder Komponentensätzen, einzelnen Dateien oder sogar kleinen Codeausschnitten verknüpft werden. Das SPDX-Projekt konzentriert sich auf die Erstellung und Verfeinerung einer Sprache zur Beschreibung der Daten, die als Teil eines SBOM ausgetauscht werden können, sowie auf die Möglichkeit, diese Daten in mehreren Dateiformaten (RDF/XML, XLSX, Tag-Wert, JSON, YAML) darzustellen , und XML), um das Sammeln und Teilen von Informationen über Softwarepakete und zugehörige Inhalte zu vereinfachen, was zu Zeit- und Genauigkeitsverbesserungen führt.
Die SPDX-Spezifikation beschreibt die Felder und Abschnitte, die für ein gültiges Dokument erforderlich sind. Es ist jedoch wichtig zu beachten, dass nicht alle Abschnitte obligatorisch sind – nur der Abschnitt mit den Erstellungsinformationen ist erforderlich. Der Ersteller des Dokuments kann auswählen, welche Abschnitte und Felder er einbeziehen möchte, die die Software- und Metadateninformationen beschreiben, die er teilen möchte.
SPDX kann Software-Stücklistendaten effektiv erfassen, indem es alle Komponenten darstellt, die in der Softwareentwicklung und -bereitstellung vorkommen. Es wird verwendet, um Distributions-ISO-Images, Container, Softwarepakete, Binärdateien, Quelldateien, Patches und sogar kleine Codefragmente, die in andere Dateien eingebettet sind, zu dokumentieren. SPDX bietet einen umfassenden Satz an Beziehungen, um Softwareelemente innerhalb von Dokumenten und über SBOM-Dokumente hinweg zu verbinden. Ein SPDX-SBOM-Dokument kann auch auf externe Quellen wie die National Vulnerability Database und andere Metadaten des Verpackungssystems verweisen.
Ein SPDX-Dokument besteht aus mehreren Komponenten: Erstellungsinformationen, Paketinformationen, Dateiinformationen, Snippet-Informationen, andere Lizenzinformationen, Beziehungen und Anmerkungen.
Jedes SPDX-Dokument kann durch eine vollständige Datenmodellimplementierung und Bezeichnersyntax dargestellt werden, was den Austausch zwischen verschiedenen Datenausgabeformaten (RDF/XML, Tag-Wert, XLSX) und die formale Validierung der Genauigkeit des Dokuments ermöglicht. Die Version 2.2 der SPDX-Spezifikation enthält zusätzliche Ausgabeformate wie JSON, YAML und XML und befasst sich auch mit „bekannten Unbekannten“, wie im ursprünglichen SBOM-Dokument identifiziert. Weitere Informationen zum zugrunde liegenden Datenmodell von SPDX finden Sie in Anhang III der SPDX-Spezifikation und auf der SPDX-Website.
CycloneDX SBOM-Standardformat
Das CycloneDX-Projekt wurde 2017 mit dem Ziel ins Leben gerufen, einen vollautomatischen, sicherheitsorientierten SBOM-Standard zu entwickeln. Die Kernarbeitsgruppe veröffentlicht jährlich unveränderliche und abwärtskompatible Versionen unter Verwendung eines risikobasierten Standardisierungsprozesses. CycloneDX umfasst vorhandene Spezifikationen wie Paket-URL, CPE, SWID und SPDX-Lizenz-IDs und -Ausdrücke. Die SBOMs können in verschiedenen Formaten dargestellt werden, darunter XML, JSON und Protokollpuffer (protobuf).
CycloneDX ist eine leichtgewichtige SBOM-Spezifikation, die für die Analyse von Lieferkettenkomponenten und die Softwaresicherheit vorgesehen ist. Es ermöglicht die Kommunikation des Softwarekomponentenbestands, externer Dienste und der Beziehungen zwischen ihnen. Es handelt sich um einen Open-Source-Standard, der vom OWASP (Open Web Application Security Project) entwickelt wurde.
CycloneDX kann die dynamische Natur von Open-Source-Komponenten erfassen, deren Quellcode zugänglich, modifizierbar und weiterverteilbar ist. Die Spezifikation kann den Stammbaum einer Komponente einschließlich ihrer Vorfahren, Nachkommen und Varianten darstellen und die Abstammung der Komponente aus jeder Perspektive sowie die Commits, Patches und Unterschiede beschreiben, die sie einzigartig machen.
Das CycloneDX-Projekt führt eine Liste bekannter Open-Source- und proprietärer Tools, die den von der Community unterstützten Standard unterstützen oder mit ihm kompatibel sind.
Die CycloneDX-Spezifikation legt ein detailliertes Objektmodell fest, das die Konsistenz über alle Implementierungen hinweg gewährleistet. Die Validierung kann mithilfe von XML-Schema und JSON-Schema oder mithilfe der CycloneDX-Befehlszeilenschnittstelle erfolgen. Für die automatisierte Bereitstellung und Nutzung unterstützter Formate werden außerdem Medientypen für XML und JSON bereitgestellt.
CycloneDX-SBOMs können die folgenden Informationen enthalten: Stücklistenmetadaten, Komponenten, Dienste, Abhängigkeiten, Zusammensetzungen und Erweiterungen
CycloneDX ist ein umfassender SBOM-Standard, der verschiedene Arten von Software charakterisieren kann, darunter Anwendungen, Komponenten, Dienste, Firmware und Geräte. Es wird branchenübergreifend häufig zur Beschreibung von Softwarepaketen, Bibliotheken, Frameworks, Anwendungen und Container-Images verwendet. Das Projekt ist mit wichtigen Entwicklungsökosystemen kompatibel und bietet Implementierungen für Softwarefabriken wie GitHub-Aktionen, sodass Unternehmen die SBOM-Erstellung vollständig automatisieren können.
SWID-Tag
SWID-Tags oder Software-Identifikations-Tags wurden erstellt, um Organisationen die transparente Nachverfolgung der auf ihren verwalteten Geräten installierten Software zu ermöglichen. Der Standard wurde 2012 von der ISO eingeführt und 19770 als ISO/IEC 2-2015:2015 überarbeitet. Diese Tags enthalten detaillierte Informationen zu einer bestimmten Version eines Softwareprodukts.
Der SWID-Standard beschreibt einen Lebenszyklus für Tracking-Software: Ein SWID-Tag wird während der Installation eines Softwareprodukts zu einem Endpunkt hinzugefügt und durch den Deinstallationsprozess des Produkts entfernt. Das Vorhandensein eines bestimmten SWID-Tags entspricht direkt dem Vorhandensein der Software, die es beschreibt. Mehrere Standardisierungsorganisationen wie die Trusted Computing Group (TCG) und die Internet Engineering Task Force (IETF) integrieren SWID-Tags in ihre Standards.
Um den Lebenszyklus einer Softwarekomponente zu verfolgen, verfügt die SWID-Spezifikation über vier Arten von Tags: primär, Patch, Korpus und ergänzend. Corpus-, Primär- und Patch-Tags dienen ähnlichen Zwecken, da sie die Existenz und Präsenz verschiedener Arten von Software, wie z. B. Software-Installer, Software-Installationen und Software-Patches, sowie die möglichen Zustände von Softwareprodukten beschreiben. Andererseits stellen ergänzende Tags zusätzliche Details bereit, die in Korpus-, Primär- oder Patch-Tags nicht zu finden sind.
Ergänzende Tags können mit jedem anderen Tag verknüpft werden, um zusätzliche Metadaten bereitzustellen, die nützlich sein können. Zusammen können SWID-Tags eine Vielzahl von Funktionen ausführen, beispielsweise Softwareerkennung, Konfigurationsmanagement und Schwachstellenmanagement.
SWID-Tags können als SBOM fungieren, da sie identifizierende Informationen für eine Softwarekomponente, eine Liste von Dateien und kryptografischen Hashes für die Artefakte der Komponente sowie Herkunftsinformationen über den Ersteller der SBOM (Tag) und den Ersteller der Softwarekomponente bereitstellen. Die Tags können auch mit anderen Tags verknüpft sein und so eine Darstellung eines Abhängigkeitsbaums ermöglichen.
SWID-Tags können während des Build- und Verpackungsprozesses generiert werden, was die automatische Erstellung eines SWID-Tag-basierten SBOM ermöglicht, wenn die entsprechende Softwarekomponente gepackt wird.
Warum sind Software-Stücklisten wichtig?
Software Bill of Materials (SBOMs) werden für Unternehmen immer wichtiger, da sie darauf abzielen, die von ihnen verwendete Software zu verwalten und zu sichern. Es gibt keine kurze Antwort auf die Frage Was ist eine SBOM?. SBOMs bieten eine umfassende Liste aller Komponenten und Abhängigkeiten, aus denen ein Softwarepaket besteht, einschließlich Informationen wie Versionsnummern, Autoren und Lizenzinformationen. Diese Informationen sind für Sicherheit und Compliance sowie für die Nachverfolgung der Herkunft von Softwarekomponenten von entscheidender Bedeutung.
Viele Organisationen, auch in regulierten Branchen, nutzen SBOMs, um die Einhaltung von Vorschriften wie der Datenschutz-Grundverordnung (DSGVO) und dem Payment Card Industry Data Security Standard (PCI DSS) sicherzustellen. SBOMs können auch dabei helfen, Schwachstellen in Software zu identifizieren und zu verwalten sowie die Herkunft von Softwarekomponenten zu verfolgen. Darüber hinaus können SBOMs bei der Verwaltung von Softwarelizenzen helfen und sicherstellen, dass Unternehmen Software in Übereinstimmung mit den Bedingungen ihrer Lizenzen verwenden.
SBOMs können auch verwendet werden, um die Verwendung von Open-Source-Software zu verfolgen, die in der Softwareentwicklung immer häufiger vorkommt. Durch die Bereitstellung detaillierter Informationen über die in einem Softwarepaket verwendeten Open-Source-Komponenten können SBOMs Organisationen dabei unterstützen, die Einhaltung von Open-Source-Lizenzen sicherzustellen.
Darüber hinaus können SBOMs zur Unterstützung der Softwareentwicklung und -wartung eingesetzt werden. Durch die Bereitstellung detaillierter Informationen zu den in einem Softwarepaket verwendeten Komponenten können SBOMs Entwicklern dabei helfen, die Abhängigkeiten eines Softwarepakets zu verstehen, was ihnen dabei helfen kann, potenzielle Kompatibilitätsprobleme zu identifizieren und fundierte Entscheidungen über die Verwendung neuer Komponenten zu treffen.