Die Erstellung des Software-Bill of Materials, oder „SBOM“ — zusammen mit der Software selbst — ist eine gute Praxis zur Überwachung von Zero-Day-Sicherheitsanfällen oder zur Erfüllung von regulatorischen und Compliance-Anforderungen.

‍SBOM ist auch bereit für die Anforderungen an die Software-Transparenz, die in gut regulierten Bereichen wie Finanzen, Gesundheitswesen und Bundesbehörden auftreten.

‍Für die Erstellung von SBOM für Softwareprojekte in den meisten Software-Ökosystemen und aus Anwendungsbinaries und Firmware existieren kommerzielle und Open-Source-Tools.

‍Jedoch wird ein typisches kommerziell verfügbares Softwareprodukt oder verbundenes Gerät als eine Sammlung von Software und Hardware projekten aufgebaut, die aus mehreren Hardwarekomponenten, Bibliotheken, Diensten oder sogar der direkten Verteilung von ausführbaren Dateien zusammengesetzt sind.

‍

Hier einige Beispiele:

• Eine mobile App umfasst Drittanbieterbibliotheken für Marketing-, Authentifizierungs- oder Werbezwecke — alle von Drittanbietern.

• Ein medizinisches Gerät kann programmierbare Komponenten von verschiedenen Anbietern enthalten, von denen jeder seine eigenen Versionen und Upgrade-Zyklen hat.

• Eine Desktop-Anwendung kann einige Drittanbieter-executables verwenden, die sie für spezifische Funktionen aufruft.

In diesen Fällen kann SBOM für Projekte und Bibliotheken mit dem Projekt erstellt werden, aber die Zusammenführung in das endgültige Produkt-SBOM erfordert ein tieferes Verständnis der SBOM-Formate und -Einschränkungen.

Die Erstellung eines endgültigen Produkt-SBOM durch die Kombination des Projekt-SBOM löst mehrere Probleme, einschließlich:

• Bereitstellung eines einzigen Produkt-SBOM anstelle vieler Projekt-SBOMs

• Verfolgung der Produktversion gegenüber spezifischen Projektversionen

• Verfolgung des endgültigen Produkts mit einer einzigen SKU in SBOM-Management-Systemen

• Kartierung neu offengelegter Schwachstellen auf spezifische Projekte