SPDX vs. CycloneDX: SBOM-Formate im Vergleich

Foto: Benoit Daoust – shutterstock.com

Software-Stücklisten (Software Bill Of Materials – SBOMs) werden zu einer wichtigen Komponente des Schwachstellenmanagements. Viele Unternehmen tun sich aber immer noch schwer mit dem Verständnis grundlegender Themen in der SBOM-Diskussion, wie zum Beispiel den Unterschieden zwischen den SBOM-Formaten.

Was sind SBOM-Formate?

SBOM-Formate sind Standards zur Definition einer einheitlichen Struktur für die Erstellung von SBOMs und deren Weitergabe an Endbenutzer oder Kunden. Sie beschreiben die Zusammensetzung von Software in einem gemeinsamen Format, das andere Tools verstehen können. Die führenden SBOM-Formate sind:

• Software Package Data Exchange (SPDX),

• Software Identification (SWID) Tagging und

• CycloneDX.

Nur SPDX und CycloneDX werden für Security-Zwecke eingesetzt. SWID ist in erster Linie auf die Lizenzierung ausgerichtet und fällt daher aus dem Rahmen dieser Diskussion. Wie die U.S. Cybersecurity and Infrastructure Security Agency (CISA) und andere festgestellt haben, wird es für einige Zeit mehrere SBOM-Formate geben.

SPDX

SPDX, ein Projekt der Linux Foundation, wurde mit der Absicht gegründet, ein gemeinsames Datenaustauschformat für Informationen über Softwarepakete zur gemeinsamen Nutzung und Sammlung zu schaffen. SPDX unterstützt die größte Sammlung von Dateiformaten unter den führenden SBOM-Formaten. Dazu gehören:

• RDFa,

• .xlsx,

• .spdx,

• .xml,

• .json und

• .yaml.

SPDX zielt auch darauf ab, eine dynamische Spezifikation zu sein, indem es in der Lage ist, eine Reihe von Softwarepaketen, Dateien oder Snippets zu beschreiben.

SPDX ist das einzige SBOM-Format mit ISO-Zertifizierung, was bedeutet, dass es alle von der ISO definierten Anforderungen an die Standardisierung und Qualitätssicherung erfüllt. Diese im September 2021 bekannt gegebene Errungenschaft unterstreicht die Akzeptanz von SPDX durch große Unternehmen wie Intel, Microsoft, Siemens und Sony, die sich an der SPDX-Community beteiligen.

Die SPDX-Spezifikation liegt zum Zeitpunkt der Erstellung dieses Dokuments in der Version 2.2.2 vor. Um als gültiges SPDX-Dokument zu gelten, müssen bestimmte Felder und Abschnitte vorhanden sein, die in der SPDX-Spezifikation definiert sind. SPDX-Dokumente können aus folgenden Feldern und Daten bestehen:

• Informationen zur Dokumenterstellung,

• Paketinformationen,

• Dateiinformationen,

• Snippet-Informationen,

• Lizenzierungsinformationen,

• Beziehungen und

• Anmerkungen.

Die Informationen zur Dokumentenerstellung werden für die Vorwärts- und Rückwärtskompatibilität bei der Arbeit mit Verarbeitungswerkzeugen verwendet. Paketinformationen dienen der Beschreibung verschiedener Einheiten wie Produkte, Container und Komponenten und können zur Gruppierung zusammengehöriger Elemente mit gemeinsamem Kontext verwendet werden. Dateiinformationen umfassen Metadaten wie Namen, Prüfsummenlizenzen und Copyright-Informationen. Snippets sind optional und werden vor allem dann verwendet, wenn die Daten aus einer anderen Originalquelle stammen oder an eine andere Lizenz gebunden sind. SPDX unterstützt außerdem Beziehungen für Dokumente, Pakete und Dateien. Mit Hilfe von Anmerkungen kann ein Prüfer Informationen aus seinen Prüfaktivitäten in ein SPDX-Dokument aufnehmen.

SPDX bietet auch ein SPDX-Lite-Profil an, das eine Untermenge der SPDX-Spezifikation darstellt. Dieses hat das Ziel, sich an die Arbeitsabläufe bestimmter Branchen anzupassen und gleichzeitig die Einhaltung des übergreifenden SPDX-Standards und der Spezifikation zu gewährleisten. Das Lite-Profil konzentriert sich auf Felder aus den Bereichen Dokumentenerstellung und Paketinformationen sowie auf begleitende Basisinformationen.

CycloneDX

CycloneDX entstammt direkt der OWASP Foundation (Open Web Application Security Project) und ist ein “leichtgewichtiger SBOM-Standard, der für den Einsatz in Anwendungssicherheitskontexten und für die Analyse von Komponenten in der Lieferkette entwickelt wurde”. Zum Kernteam gehören Patrick Dwyer, Jeffry Hesse und der Leiter der Software-Lieferkette und Erfinder des Dependency Track, Steve Springett, der den Vorsitz der Gruppe innehat. Zu den Unterstützern von CycloneDX gehören neben OWASP auch Lockheed Martin, Contrast Security und Sonatype.

Das Besondere an CycloneDX ist, dass es von Anfang an als Stücklistenformat konzipiert wurde und eine Vielzahl von Anwendungsfällen abdeckt, darunter auch Software-as-a-Service-BOM (SaaSBOM). CycloneDX unterstützt außerdem eine Vielzahl von Anwendungsfällen über Software hinaus.

CycloneDX ermöglicht die Referenzierung von Komponenten, Diensten und Schwachstellen in anderen Systemen und Stücklisten in einem verschachtelten und hierarchischen Ansatz, der der Komplexität des modernen Software-Ökosystems in Bezug auf Hardware, Cloud und SaaS gerecht wird. CycloneDX bezeichnet diese Fähigkeit als “BOM-Link”. Es unterstützt diese Fähigkeit sowohl im JSON– als auch im XML-Format. Benutzer können die URL der externen BOM oder sogar eine BOM-Link URI referenzieren, die Seriennummern und Versionen für die externen BOMs verwendet.

Darüber hinaus ermöglicht CycloneDX eine vollständige und genaue Inventarisierung aller Erst- und Fremdkomponenten zur Risikoidentifizierung. Dies wird durch eine robuste Liste von Komponententypen und -klassen ermöglicht, die über Software und Anwendungen hinausgehen und bis zu Geräten und sogar Diensten reichen. Die Identifizierung von Schwachstellen ist über drei Felder möglich, nämlich:

• Common Platform Enumeration (CPE),

• SWID und

• Package-URL (PURL).

Die CPE-Spezifikation kann für Sicherheitslücken in Betriebssystemen, Anwendungen und Hardware-Geräten verwendet werden. SWID wird für installierte Software verwendet und PURL kann für Softwarepaket-Metadaten verwendet werden.

CycloneDX erlaubt auch die Integritätsprüfung der mit den verwendeten Stücklisten verbundenen Komponenten mit Hilfe von Hash-Werten und Kryptographie. Dies ist wichtig, da im Rahmen der Bemühungen um die Verbesserung der Sicherheit der Software-Lieferkette das Signieren von Software zunehmend zu einer Best Practice wird. Beispiele dafür sind Projekte wie Sigstore und das dazugehörige Cosign.

CycloneDX unterstützt außerdem die sogenannte Provenance, also die Fähigkeit, die Autoren und Lieferanten von Komponenten darzustellen, von denen die Komponente bezogen wurde. Aufbauend auf diesem Konzept kann CycloneDX auch den Komponentenstammbaum unterstützen, indem es die Vorfahren, Nachkommen und Varianten einer Komponente mitteilt, um die Abstammung einer Komponente zu beschreiben. Die Implementierung von Provenance, Pedigree und digitalen Signaturen stellt für die Anforderungen einer hochsicheren Software-Lieferkette robuste Lieferkettenfähigkeiten dar und wird von Richtlinien wie dem Cybersecurity Supply Chain Risk Management (C-SCRM) des NIST empfohlen.

CycloneDX bietet auch Unterstützung für den Vulnerability Exploitability Exchange (VEX), der Einblick in die Ausnutzbarkeit bekannter Schwachstellen in Softwareprodukten und -komponenten gibt und von Softwareherstellern übermittelt werden kann.

Mehrere SBOM-Formatstandards werden fortgesetzt

Angesichts der zunehmenden Akzeptanz und Nutzung in der Softwarebranche kann man davon ausgehen, dass die beiden führenden SBOM-Formate wahrscheinlich noch einige Zeit bestehen bleiben. Sowohl Softwarehersteller als auch -verbraucher täten entsprechend gut daran, wenn sie beide Formate unterstützen könnten. Führende SBOM-Generierungswerkzeuge wie Syft von Anchore unterstützen ebenfalls beide Formate.

Darüber hinaus ist es wahrscheinlich, dass sich das Ökosystem der SBOM-Formate mit der zunehmenden Verbreitung und Reife von SBOM weiterentwickeln wird und Innovationen aus diesen Projekten sowie potenzielle neue SBOM-Formate hervorgehen. Auch wenn sich darüber streiten lässt, welches Format das bessere ist, sind Transparenz und Sicherheit in der Software-Lieferkette nicht mehr wegzudenken, da böswillige Akteure diesen Angriffsvektor immer häufiger nutzen. (mb)

Dieser Artikel basiert auf einem Beitrag unserer US-Schwesterpublikation CSO Online.