Das Schreiben von Software oder Softwarekomponenten von Grund auf neu ist in der modernen Softwareentwicklung selten. Bereits existierende Bibliotheken und Frameworks bieten die Basis für die Entwicklung neuer Features und Funktionalitäten, und dieses neue Produkt kann wiederum die Basis für ein weiteres Produkt werden.
Diese Schichtung von Software und Komponenten kann jedoch sowohl für Entwickler als auch für Endverbraucher blinde Flecken erzeugen. In Teil 1 haben wir erörtert, wie diese Schichtung die Identifizierung von Zero-Day-Schwachstellen erschwert (was weltweit bei log4shell zu beobachten war).
Weitere Risiken sind mit Software unbekannter Zusammensetzung verbunden, darunter:
das Risiko, Komponenten mit einer restriktiven Lizenz einzubinden
End-of-Life-Komponenten oder
Komponenten, die von staatlichen Akteuren beeinflusst werden.
Die Fertigungsindustrie ist mit ähnlichen Problemen im Lieferketten- und Bestandsmanagement umgegangen, indem sie Stücklisten (BOM - Bill of Materials), Obsoleszenzmanagement, Produktänderungsmitteilungen (PCN) und End-of-Life-Management (EOL) eingeführt hat.
Die SBOM überträgt diese Erkenntnisse und Praktiken auf die Softwareentwicklung.
Software-Stückliste (SBOM)
Im Kern ist eine SBOM (Software Bill of Materials) ein Dokument, das die Komponenten der Software, deren Lieferanten und die Beziehungen der Komponenten untereinander (Schichtung) beschreibt, zusammen mit einigen Metadaten, um all das verständlich zu machen.
Konzeptionelle SBOM — Quelle: Framing Software Component Transparency
Die CISA empfiehlt, SBOMs nach bestehenden Spezifikationen zu erstellen:
Diese Spezifikationen sind sehr flexibel, und daher hat die CISA auch Mindestelemente für eine SBOM empfohlen, um sicherzustellen, dass die erstellte SBOM zur Bewältigung der oben genannten Risiken verwendet werden kann.
SBOM-Anwendungsfälle
Eine vollständige SBOM kann helfen, die folgenden Probleme zu lösen:
1. Komponentenbestand Eine vollständige SBOM enthält alle Komponenten, einschließlich der verschachtelten Komponenten, und kann daher einen Komponentenbestand für das Produkt erstellen.
2. Lizenzbestand Eine vollständige SBOM enthält alle Lizenzen, die jeder Komponente zugeordnet sind, und kann daher für den Aufbau und die Überwachung des Lizenzbestands verwendet werden. Dies ist ein entscheidender Teil der Risikominimierung im Zusammenhang mit Open-Source-Lizenzen.
3. Schwachstellenmanagement Eine gut beschriebene Komponente in einer SBOM folgt weit verbreiteten Namenskonventionen für Komponenten wie CPE, PURL oder SWID-Tag. Ein genauer Komponentenname kann für die Suche nach Schwachstellen in Datenbanken wie NVD und OSV verwendet werden. Da die SBOM verschachtelte Beziehungen (und viele weitere Beziehungsarten) unterstützt, löst dies das in Teil 1 beschriebene Problem der Schwachstellensuche.
4. Obsoleszenz- und End-of-Life-Management Wenn das Produkt altert, ermöglicht die Erstellung eines Komponentenbestands der SBOM, veraltete oder EOL-Komponenten zu verfolgen.
5. Offenlegung der Ausnutzbarkeit von Schwachstellen SBOM kann mit VEX kombiniert werden, um den Status von Schwachstellen im Zusammenhang mit dem Produkt zu kommunizieren. Dies hilft, das Rauschen in Fällen zu reduzieren, in denen Software-Zusammensetzungs-Analyse-Tools ein Produkt scannen. Eine Einführung in die Offenlegung der Ausnutzbarkeit von Schwachstellen finden Sie hier.
SBOM-Herausforderungen
Das Potenzial von SBOMs ist für Organisationen, die sie erstellen, offensichtlich. Mehrere der oben beschriebenen Anwendungsfälle enthalten jedoch Formulierungen wie vollständige SBOM, gut beschriebene Komponente und genauer Komponentenname.
Die Erstellung einer vollständigen SBOM oder die Verwendung eines exakten Namens für eine Komponente ist eine echte Herausforderung. Diese Herausforderungen können Erstanwender frustrieren oder zu einer unaufrichtigen Ablehnung von SBOMs führen.
In Teil 3 – Warum SBOM-Herausforderungen Chancen und keine Risiken sind.