SBOM-Standards voranbringen: Snyk und SPDX

Viele kennen das SPDX-Projekt durch die Arbeit an der SPDX-Lizenzliste. Diese Liste kanonischer Kennungen für verschiedene Softwarelizenzen kommt in einer Vielzahl entwicklerorientierter Software zum Einsatz – von Snyk bis GitHub. Das zur Linux Foundation gehörende SPDX-Projekt verfolgt jedoch ein viel weiter gefasstes Ziel: einen offenen Standard für den Austausch von Informationen zu Software-Stücklisten bereitzustellen.

Eine Software-Stückliste (Software Bill of Materials, SBOM) listet die Komponenten einer bestimmten Software auf. Ein gängiger Vergleich ist die Zutatenliste auf Lebensmittelverpackungen. Software wird immer komplexer und besteht aus immer mehr Komponenten. Dabei geht es nicht nur um Open-Source-Bibliotheken und Frameworks: Eine moderne Softwareanwendung kann aus mehreren Services bestehen, von denen jeder eine eigene SBOM hat. Zusammen mit Tools verpackt, können diese noch weitere Abhängigkeiten mit sich bringen.

SPDX soll standardisieren, wie wir diese SBOM definieren, und ein maschinenlesbares Format bereitstellen, auf dessen Grundlage die gesamte Softwarebranche Tools entwickeln kann, um vielfältige Probleme in der Supply Chain zu lösen.

Das hilft zunehmend dabei, die heutigen Herausforderungen der Softwaresicherheit zu bewältigen. Erst letzten Monat erließ US-Präsident Biden eine Executive Order zur Verbesserung der Cybersicherheit der Nation, die ausdrücklich die Einführung von SBOMs und die Formalisierung von SBOM-Standards als Ziel nennt. Unsere ausführlichere Einschätzung der Executive Order finden Sie in unserem Blog zu den Anforderungen an die Software-Supply-Chain-Sicherheit.

Snyk und SBOMs

Die von Paketmanagern verwendeten Manifestdateien enthalten zwar Listen von Software, gelten aber im Allgemeinen nicht als SBOMs. Sie sind stärker auf einen bestimmten Anwendungsfall ausgerichtet und enthalten gerade genug Informationen, um die aufgeführte Software zu installieren.

Snyk lässt sich in zahlreiche Paketmanager und Entwicklertools integrieren, um Schwachstellen in den verwendeten Softwarekomponenten zu erkennen. Dafür erstellen wir im Hintergrund eine SBOM, vereinheitlichen die Liste der Software und ergänzen sie um zusätzliche Metadaten aus anderen Quellen. Die Snyk-Tools konzentrieren sich hauptsächlich darauf, diese Informationen zusammen mit Angaben zu Schwachstellen anzuzeigen. Snyk-Kunden können jedoch über unsere integrierte Berichterstellung oder die leistungsstarke API auf die Rohdaten der SBOM zugreifen.

Tatsächlich können Sie sich Snyk-Client-Tools wie die CLI und CI/CD-Plugins so vorstellen, dass sie eine SBOM erstellen. Das Snyk-Backend verarbeitet dann eine SBOM und gibt Schwachstellendaten zurück oder automatisiert die Arbeit mit diesen Daten, damit Sie Probleme beheben können. Diese umfangreiche Erfahrung begründet unser Interesse an neuen Standards in diesem Bereich.

Snyk und SPDX

SPDX gibt es zwar schon seit mehreren Jahren als SBOM-Standard, doch die jüngsten Arbeiten an der Entwurfsspezifikation 3.0 sind vielversprechend. Wir haben uns intensiv mit dem Entwurf eines Schwachstellenprofils für SPDX befasst. Dieses ermöglicht es, neben Informationen zu Softwarekomponenten auch Schwachstellendaten hinzuzufügen – in SBOM-Kreisen manchmal als VEX oder Vulnerability Exploitability bezeichnet.

Um die Arbeit an der Spezifikation zu validieren, haben wir ein einfaches Tool namens snyk2spdx entwickelt. snyk2spdx erfüllt einen einzigen Zweck: Es verarbeitet die zugrunde liegenden Snyk-Testdaten, einschließlich der SBOM-Informationen, und gibt sie im SPDX-Format 3.0 aus – einschließlich des Schwachstellenprofils. Hier sehen Sie die einfache Ausgabe.

1$ snyk test --json | npx snyk2spdx | jq
2{
3  "id": "SPDXRef-todo-list",
4  "name": "todo-list",
5  "specVersion": "SPDX-3.0",
6  "profile": [
7    "base",
8    "vulnerabilities"
9  ],
10  "dataLicense": "CC0-1.0",
11  "creator": "Organization: Snyk Ltd",
12  "documentNamespace": "spdx.org/spdxdocs/todo-list-2bd968c5-d497-41ec-83d7-5ee652720c53",
13  "description": "Snyk test result for project todo-list in SPDX SBOM format",
14  "created": "2021-05-05T16:20:28Z",
15  "vulnerabilities": [
16

Dies ist nur der Header. Hier finden Sie einen Link zur vollständigen SBOM-Ausgabe, wenn Sie sich besonders für das Format interessieren.

Wir haben dieses Tool entwickelt, um damit zu experimentieren und Feedback zum aktuellen Entwurf der Spezifikation zu geben. SPDX 3.0 ist noch in Entwicklung und wird bislang weder von vielen Tools unterstützt, noch gibt es veröffentlichte Schemas. Beides wird mit der Zeit kommen. Dann werden wir diese Funktionalität wahrscheinlich in die Snyk-CLI integrieren und SPDX auch in anderen Bereichen von Snyk verfügbar machen und nutzen.

Wenn Sie sich allgemein für SBOMs und besonders für VEX interessieren, können Sie mit snyk2spdx erste Experimente durchführen. Vielleicht möchten Sie sich sogar an der Arbeit an der Spezifikation oder an den umfassenderen Bemühungen beteiligen, für sie zu werben und Software rund um sie aufzubauen.

Die Zukunft

Während SPDX zunehmend Aufmerksamkeit erhält, arbeitet Snyk eng mit der Linux Foundation zusammen, um den Standard zu verbessern und das Tool-Ökosystem auszubauen. Dieser aktuelle Blogbeitrag der Linux Foundation fasst zusammen, warum und wie die Open-Source-Community vor über einem Jahrzehnt erkannt hat, dass die Herausforderung rund um SBOMs angegangen werden muss.

Standards können Branchen voranbringen, wenn sie zur richtigen Zeit am richtigen Ort entstehen. Die Executive Order von Biden macht deutlich, dass SBOMs eine wichtige Rolle bei der Verbesserung der Sicherheit der Software-Supply-Chain spielen. Wir bei Snyk freuen uns darauf, uns weiterhin in diesem Bereich einzubringen.