SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 3: CycloneDX und SPDX

Die zunehmende Komplexität und Interkonnektivität von Softwareanwendungen führt dazu, dass es immer mehr Fremdabhängigkeiten in der Software gibt. IT-Verantwortliche stehen vor der Herausforderung, den Überblick zu behalten und die Zusammensetzung und Herkunft von Softwarekomponenten transparent und nachvollziehbar zu dokumentieren. Wie wichtig diese Dokumentation für die Sicherheit, Compliance und Effizienz des gesamten Softwareentwicklungs- und Bereitstellungsprozesses ist, haben die ersten beiden Teile dieser Reihe gezeigt.

Für alle die neu dabei sind: In dieser Blogserie wird die Bedeutung von Software Bill of Materials (SBOM) als Instrument zur Identifizierung, Verfolgung und Analyse von Softwarekomponenten diskutiert. Wir nehmen euch mit in die Praxis, stellen euch Tools und Funktionalitäten vor.

Während es in den beiden ersten Teilen der Serie um grundsätzliche Fragen rund um die Software-Stücklisten ging, haben wir für diesen dritten Teil die beiden führenden SBOM-Formate, CycloneDX und SPDX, genauer untersucht und miteinander verglichen.

Hier kannst du einen Blick in die ersten beiden Teile der Blogserie werfen:

Aber nun zurück zu diesem 3. Teil:

CycloneDX und SPDX bieten IT-Verantwortlichen Möglichkeiten, um Informationen über die Komponenten von Softwareanwendungen strukturiert zu erfassen und zu kommunizieren, wobei jedes Format seine eigenen Stärken und Einsatzbereiche aufweist.

Diese Untersuchung zielt darauf ab, IT-Fachleuten einen fundierten Einblick in die beiden gängigen Standards für SBOMs zu geben.

Wie sind die SBOM-Formate CycloneDX und SPDX entstanden?

Für SBOMs gibt es zwei relevante Standards: SPDX (Software Package Data Exchange) und CycloneDX, die sich in nur wenigen Aspekten voneinander unterscheiden. Auch dies ist beiden gemeinsam: Beide Standards sind Open Source und wurden von gemeinnützigen Organisationen entwickelt:

  • SPDX wurde 2011 von der Linux Foundation entwickelt und ist seit 2021 ein ISO-Standard (ISO/IEC 5962:2021). Ursprünglich entwickelt wurde SPDX, um in Open Source Projekten Lizenzinformationen zu verwalten. Im Laufe der Zeit wurde der Standard erweitert, um zusätzlich Information zu Sicherheitslücken und weiteren Aspekte aufzunehmen.
  • CycloneDX ist ein Standard des OWASP (Open Web Application Security Projects), der 2017 entwickelt wurde. Sein Fokus liegt darauf, Anwendenden zu ermöglichen, Sicherheitslücken in Ihrer Software zu identifizieren, insbesondere in deren Abhängigkeiten.

Wo liegen die Unterschiede?

SPDX und CycloneDX sind heute nahezu deckungsgleich. Beide enthalten Attribute für Metadaten, Softwareabhängigkeiten und externe Dienste oder Dateien, die eingebunden werden. Damit ist jeder Standard nahezu gleichwertig einsetzbar.

Abhängigkeiten

  • CycloneDX unterteilt Abhängigkeiten explizit in direkte und transitive Abhängigkeiten.
  • SPDX hingegen hat ein eigenes Feld, um Relationen zwischen den verschiedenen Elementen in einer SPDX SBOM abzubilden. Zudem sieht SPDX explizit ein Feld vor, um einen Review der SBOM zu dokumentieren.

Fokus Compliance oder Cybersicherheit?

Die Wahl eines Standards hängt vom Kontext der Verwendung der SBOM ab: Möchte man in erster Linie die Lizenzen einer Software im Auge behalten, bietet sich historisch SPDX an, da dies explizit dafür entwickelt wurde. CycloneDX hingegen wurde speziell für das Verwalten von Sicherheitslücken entwickelt.

Allerdings sind beide Standards mittlerweile so weit entwickelt worden, dass man sie in der Praxis für beides einsetzen kann.

Wie steht es um die Kompatibilität?

Eine Konvertierung zwischen den beiden Standards ist möglich, beide Projekte stellen dafür Tools bereit. Allerdings muss hierbei beachtet werden, dass nicht alle Attribute der jeweiligen Standards in dem anderen abgebildet werden können. Dies wird in den Tools beider Projekte dokumentiert (cyclonedx-cli und cdx2spdx)

Zu prüfen ist allerdings, mit welchem Unternehmen die SBOMs ausgetauscht werden sollen, da diese einen Standard vorgeben könnten. So arbeitet Microsoft bspw. mit SPDX und IBM mit CycloneDX.

Beispiele für den Aufbau der SBOMs

Beispiel für den Aufbau einer CyclonDX SBOM
Beispiel 1: Aufbau einer CyclonDX SBOM (Quelle: https://cyclonedx.org/specification/overview/)

Beispiel für den Aufbau einer SPDX SBOM
Beispiel 2: Aufbau einer SPDX SBOM (Quelle: https://spdx.github.io/spdx-spec/v2.3/composition-of-an-SPDX-document/)

Summary

Gibt es also eine klare Empfehlung für einen der beiden Standards? Aus unserer Sicht: Nein. Für die Wahl des geeigneten Standards ist es – wie wir in den folgenden Artikeln zeigen werden – relevanter mit welchen Tools man arbeiten will und welchen Standard diese unterstützen. Ebenso sollte man den Standard und die Werkzeuge so wählen, dass eine Konvertierung zwischen den Standards vermieden wird.

Wie geht es weiter?

Im nächsten Teil stellen wir uns die Frage: Was ist eine gute SBOM? Wir stellen Kriterien und das Setting für unsere Versuchsreihe vor und nehmen Tools für die Erzeugung von SBOMs unter die Lupe.

Danach geht es weiter mit Fragen wie :

  • Was können die Vulnerability Scanner?
  • Wie kann ich auf kompatible Lizenzen prüfen?
  • Wie integriere ich SBOMs in den Software-Development-Prozess?
  • Was ist beim Start in die SBOM-Welt zu beachten?
  • Was ist von den Konzepten hinter SBOM zu halten?
  • Summary und Tipps für den Start

Alle Teile ansehen:

Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken

Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten

Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX

Teil 4: Was ist eine gute SBOM? – Das Versuchssetting

Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich

Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?

Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks

Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess

Teil 9: Halten SBOMs, was sie versprechen?

Alle Beiträge von Tim Teulings

Tim Teulings ist als Senior Solution Architekt bei OPITZ CONSULTING tätig. Er unterstützt Software-Entwicklungsteams dabei, schnell, einfach und entspannt Software aufzubauen, die perfekt zum Kunden passt. Am Ende stehen Ergebnisse, die der Kunde wirklich haben will – nicht nur eine Version 1.0. Die Themenbereiche Modernisierung und Integration gehören in dieser Funktion zu seinem täglichen Geschäft. Zu Tims Schwerpunkten zählen entsprechende Tools, Frameworks, Methoden, Vorgehen, Architekturen und Techniken.

Avatar-Foto
Alle Beiträge von Dominik Kloke

Dominik ist leidenschaftlicher Softwareentwickler aus Berlin. Mit fundierten Kenntnissen in Informatik schafft er innovative Lösungen für reale Probleme.

Schreibe einen Kommentar