Der Bedarf an SBOM - Teil 2
03.07.2023
Interlynk
Software oder Softwarekomponenten von Grund auf neu zu schreiben, ist in der modernen Softwareentwicklung selten. Vorhandene Bibliotheken und Frameworks bieten die Grundlage für die Entwicklung neuer Funktionen und Features, und dieses neue Produkt kann die Basis für ein weiteres Produkt werden.
Diese Schichtung von Software und Komponenten kann jedoch zu blinden Flecken für den Entwickler und die Verbraucher führen. In Teil 1 haben wir erörtert, wie die Schichtung eine Herausforderung bei der Identifizierung von Zero-Day-Sicherheitsanfälligkeiten (weltweit mit log4shell erlebt) darstellt.
Weitere Risiken sind mit der Software unbekannter Zusammensetzung verbunden, einschließlich:
das Risiko, Komponenten mit einer restriktiven Lizenz einzuschließen
Komponenten am Ende ihres Lebenszyklus oder
Komponenten, die von staatlichen Akteuren beeinflusst werden.
Die Fertigung hat ähnliche Bedenken in der Lieferkette und im Bestandsmanagement behandelt, indem sie Build of Materials (BOM), Obsolescence Management, Produktänderungsbenachrichtigung (PCN) und End-of-Life (EOL) Management entwickelt hat.
SBOM bringt dieses Wissen und diese Praktiken in die Softwareentwicklung ein.
Software-Lieferkette (SBOM)
Im Kern ist SBOM ein Dokument, das die Komponenten der Software, ihre Lieferanten und die Beziehungen zwischen den Komponenten (Schichtung) beschreibt, zusammen mit einigen Metadaten, um das Ganze nachvollziehbar zu machen.
Konzeptionelles SBOM — Quelle: Rahmen für die Transparenz von Softwarekomponenten
CISA empfiehlt den Aufbau von SBOM nach bestehenden Spezifikationen:
Diese Spezifikationen sind sehr flexibel, und daher hat CISA auch Mindestanforderungen für ein SBOM empfohlen, um sicherzustellen, dass das generierte SBOM verwendet werden kann, um die oben genannten Risiken zu adressieren.
SBOM-Anwendungsfälle
Ein vollständiges SBOM kann die folgenden Probleme lösen:
1. Komponenteninventar Ein vollständiges SBOM umfasst alle Komponenten, einschließlich der verschachtelten Komponenten, und kann daher ein Komponenteninventar für das Produkt erstellen.
2. Lizenzinventar Ein vollständiges SBOM umfasst alle Lizenzen, die mit jeder Komponente verbunden sind, und kann daher verwendet werden, um ein Lizenzinventar aufzubauen und zu überwachen. Dies ist ein kritischer Teil der Verwaltung von Risiken, die mit Open-Source-Lizenzen verbunden sind.
3. Schwachstellenmanagement Eine gut beschriebene Komponente in einem SBOM folgt weit verbreiteten Namenskonventionen wie CPE, PURL oder SWID-Tag. Ein exakter Komponentenname kann für Schwachstellensuchen in Datenbanken wie NVD und OSV verwendet werden. Da SBOM verschachtelte Beziehungen (und viele weitere Typen von Beziehungen) unterstützt, wird das Problem der Schwachstellensuche, das in Teil-1 beschrieben ist, gelöst.
4. Obsoleszenz- und Lebenszyklusmanagement Während das Produkt älter wird, ermöglicht der Aufbau eines Komponenteninventars dem SBOM, veraltete oder EOL-Komponenten zu verfolgen.
5. Offenlegung der Ausnutzbarkeit von Schwachstellen SBOM kann mit VEX kombiniert werden, um den Status der mit dem Produkt verbundenen Schwachstellen zu kommunizieren. Dies hilft, das Rauschen in den Fällen zu reduzieren, in denen Tools zur Analyse der Softwarezusammensetzung ein Produkt scannen. Eine Einführung in die Offenlegung der Ausnutzbarkeit von Schwachstellen ist hier.
SBOM-Herausforderungen
Das Potenzial von SBOM ist für Organisationen, die sie erstellen, klar. Einige der oben beschriebenen Anwendungsfälle enthalten jedoch Phrasen wie: vollständige SBOM, gut beschriebenes Bauteil und genauer Komponentenname.
Eine vollständige SBOM zu erstellen oder einen genauen Namen für ein Bauteil zu verwenden, ist eine echte Herausforderung. Diese Herausforderungen können frühe Anwender frustrieren oder eine unaufrichtige Ablehnung gegenüber SBOM hervorrufen.
In Teil 3 — Wie SBOM-Herausforderungen Möglichkeiten und keine Risiken sind.