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:
- 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
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
|
|
|
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
Bisherige Teile ansehen:
Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX
