In den letzten Jahren sind sich die Menschen zunehmend der Risiken bewusst geworden, die mit der Verwendung von Open-Source-Komponenten in ihrer Software verbunden sind. Wenn man bedenkt, dass es sich bei der meisten Software um eine Mischung aus Open Source und proprietärer Logik handelt, ist es für das ordnungsgemäße Risikomanagement des endgültigen Softwareprodukts von entscheidender Bedeutung, zu wissen, welche Bestandteile direkt oder vorübergehend von außen importiert wurden. Da die Zeiten, in denen die Zutatenverfolgung mithilfe komplizierter Tabellenkalkulationen durchgeführt wurde, längst vorbei und darüber hinaus äußerst ineffizient sind, besteht die wichtigste Möglichkeit zur Nachverfolgung in der Verwendung einer SBOM – einer Software-Stückliste. Wie bei anderen Stücklisten handelt es sich im Wesentlichen um eine Liste der Softwarebestandteile, aus denen die Software besteht, mit Hinzufügung der Beziehungen zwischen verschiedenen Bestandteilen, wobei ein besonderer Schwerpunkt darauf liegt, welche Komponenten voneinander abhängig sind.
Derzeit werden auf dem Markt zwei wichtige SBOM-Formate verwendet: SPDX und CycloneDX.
Softwarepaket-Datenaustausch (SPDX) ist ein maschinenlesbares Open-Source-SBOM-Projekt der Linux Foundation. Die neueste Version des SPDX wurde im Einklang mit dem NTIA-Standard für „Mindestelemente für eine Software-Stückliste.' Es listet die Komponenten, Urheberrechte, Lizenzen und Sicherheitshinweise einer Software auf.
CycloneDX (CDX) ist ebenfalls ein Open-Source- und maschinenlesbares SBOM-Format, das von der Open Web Application Security Project (OWASP)-Community entwickelt wurde. Als Stücklistenformat bietet CycloneDX weitere Anwendungen als die Erstellung von Software-Stücklisten. Es kann auch zum Kompilieren von Komponenten, Schwachstellen und Diensten von Hardware- und Cloud-Systemen verwendet werden.
Warum ist SBOM wichtig?
Die SBOM ist äußerst nützlich für Softwareentwicklungsteams, Einkaufsorganisationen und Endbenutzer. Durch die Verwendung kann sichergestellt werden, dass Open-Source-Komponenten und Komponenten von Drittanbietern auf dem neuesten Stand sind, und bietet Einblick in die Projektabhängigkeiten, die bekannte Schwachstellen aufweisen, die in Ihrer Software möglicherweise ausgenutzt werden. Softwarekäufer hingegen können SBOMs nutzen, um das einem Produkt innewohnende Risiko durch Schwachstellenbewertungen zu analysieren.
Organisationen wären besser beraten, wenn sie mit ihren Anbietern zusammenarbeiten, um sicherzustellen, dass sie Zugriff auf korrekte und aktuelle Informationen zu den Projektkomponenten haben, die in Systeme und/oder Produkte implementiert werden. Sie sollten ihre SBOMs außerdem regelmäßig bewerten, um die Risiken der Verwendung von Open-Source- und Drittanbieterkomponenten zu minimieren.
SBOM-Beispiele
Abhängig vom verwendeten SBOM-Format kann es Unterschiede in den Komponenten der SBOM geben. Abhängig von der Größe und Komplexität Ihres Projekts kann eine SBOM-JSON-Datei problemlos Tausende von Zeilen oder mehr umfassen. Da die Betrachtung einer Datei mit tausend Zeilen nicht sehr aufschlussreich ist, verwenden wir vorhandene, einfachere Beispiele, um zu sehen, was jedes SBOM-Format enthält. Wir werden uns Beispiele der beiden wichtigsten Formate, die heute auf dem Markt sind, genauer ansehen.
SPDX
Das SPDX SBOM-Beispiel, dem wir folgen werden, finden Sie hier HIER.
Der JSON beginnt mit allgemeinen Informationen über die Datei selbst – Metadaten.
Danach erhalten wir die Metadaten über die Software, die wir untersuchen:
Beachten Sie die Prüfsumme und ihren Wert. Jeder Abschnitt der SBOM enthält die Verschlüsselung und das Ergebnis des betreffenden Teils, sodass Personen, die die Datei untersuchen, sicher sein können, dass die erwähnte Software oder Komponente mit der Software oder Komponente identisch ist, die sie betrachten.
Ohne diese Garantie könnten Sie leicht mehrere Kopien mit demselben Namen von Komponenten oder Software finden und hätten keine Ahnung, welche dieser Versionen überprüft oder in der Software oder der SBOM, die sie beschreibt, enthalten ist.
Nach der Beschreibung der überprüften Software können wir mit der Betrachtung der Komponenten beginnen:
Sie können mehrere Felder sehen, die die Lizenz einer Komponente, ihre Homepage, Version, den vollständigen Namen usw. beschreiben.
Eine weitere Sache, die Sie in einem SPDX-Format finden können, sind Anmerkungen – Ergänzungen, die zu einem späteren Zeitpunkt zu einem Abschnitt hinzugefügt werden und weitere Informationen und manchmal sogar Freitext enthalten:
Um mehr über dieses Format und seine Möglichkeiten zu erfahren, besuchen Sie die SPDX-Seite der Linux Foundation.
CycloneDX
Das CycloneDX SBOM-Format kann in einer JSON-Datei, einer XML-Datei oder in Protokollpuffern beschrieben werden. Um die Dinge gleichmäßig und einfach zu halten, folgen wir einem vereinfachten CycloneDX-JSON-Beispiel. Das beschriebene Beispiel finden Sie hier HIER.
Der JSON beginnt mit allgemeinen Metadateninformationen zur Datei.
Dann werden die Metadaten der Software untersucht:
Danach die Softwarekomponenten und ihre Abhängigkeiten:
Bedenken Sie, dass es sich hierbei um ein vereinfachtes Beispiel handelt und dass das Format viele weitere Informationen enthalten kann. Für einen umfassenderen Einblick in verschiedene Anwendungsfälle können Sie sich die Seite „OWASP CyclonDX-Anwendungsfälle“ ansehen HIER.
Hier ist ein Beispiel von dieser Seite, das den Aufbau einer Liste von Abhängigkeiten demonstriert:
Und hier ist eine umfassendere Beschreibung der verschiedenen Komponenten dieses Formats aus dem OWASP Stücklistenfunktionen Seite:
So verwenden Sie eine SBOM
Haben Sie kein schlechtes Gewissen, wenn Sie den hier gezeigten Dateibeispielen nicht folgen können. Obwohl JSON-Dateien für Menschen hervorragend lesbar sind, eignen sie sich weitaus besser für die Maschinenlesbarkeit, sodass spezielle Software die Informationen aufnehmen und die Ergebnisse der Analyse ausspucken kann.
Mithilfe einer Liste von Softwarekomponenten können Sie überprüfen, ob diese keine unerwünschten Open-Source-Lizenzen enthalten (Zeile GPL3.0 oder MPL1.1). Sie können regelmäßig eine Liste der Abhängigkeiten überprüfen, um zu sehen, ob Updates verfügbar sind, oder die Paketnamen anhand von Schwachstellendatenbanken überprüfen, um herauszufinden, welche problematischen Abhängigkeiten Ihre Software enthält.
Es mag kompliziert klingen, eine SBOM zu erfassen und alle diese Informationen zurückzubekommen, aber denken Sie daran, dass Sie nicht alles selbst tun müssen. Dienste wie die Scribe Security-Plattform können viele Probleme beseitigen und weitaus mehr Vorteile bieten. Schauen Sie sich gerne unsere Plattform an und erfahren Sie, wie Sie Ihr Risiko mithilfe unseres kontinuierlichen Überwachungssystems über Ihren Entwicklungslebenszyklus und Ihre Endprodukte hinweg steuern können.