Eine Software-Stückliste (Software Bill of Materials, SBOM) hilft bei der Erstellung und Kommunikation von Softwarekomponenten-Inventaren sowie den damit verbundenen Risiken. Die regulatorischen und Monitoring-Bedürfnisse von SBOMs sind hinlänglich bekannt. Die Erstellung einer „guten“ SBOM erfordert jedoch nach wie vor das Vermeiden einiger Fallstricke, da sich einige der beliebten SBOM-Builder noch in der Entwicklungsphase befinden.
Hier sind die fünf häufigsten Probleme, auf die wir beim Umgang mit SBOMs immer wieder stoßen.
1. Verwechslung von Spezifikationen
Die am hu00e4ufigsten auftretenden Probleme zeigen sich bei Tools, die mehr als eine Spezifikation unterstu00fctzen. Wir beobachten immer wieder, dass die Implementierung der Verarbeitung einer Spezifikation zu ungu00fcltigen Werten fu00fcr die andere fu00fchrt.
2. Falsch identifizierte Identifikatoren
CPE und PURL sind zwei der gängigsten Methoden zur globalen Identifizierung von Komponenten, insbesondere im Schwachstellenmanagement. Darüber hinaus erfordern sowohl CycloneDX als auch SPDX dokumentspezifische, interne eindeutige Identifikatoren (bom-ref bzw. SPDXID). Dies hilft beim Nachverfolgen zusätzlicher Komponenteninformationen, wie beispielsweise den Beziehungen zwischen den Komponenten.
Aber diese Anforderungen an die Identifikatoren können zu zwei häufigen Arten von Herausforderungen führen:
2.1 Fehlendes oder ungültiges CPE/PURL
Ein SBOM, das keine CPE- oder PURL-Angaben enthält, ist für die Schwachstellenverfolgung nicht hilfreich. Es kann jedoch weiterhin als Zutatenliste und Lizenzinventar dienen, sofern Lizenzinformationen vorhanden sind.
2.2 Inkonsistenter eindeutiger Identifikator
Das andere sehr häufige Problem sind SBOMs mit ungültigen oder doppelten Identifikatoren im Dokument. Die bom-ref und SPDXID sollen im Dokument eindeutig sein und unterliegen spezifikationsspezifischen Einschränkungen (z. B. sollte die SPDXID keine Sonderzeichen enthalten).
3. Lizenz zur Verwirrung
Das Festlegen und Verfolgen von Open-Source-Softwarelizenzen war einer der fru00fchesten Anwendungsfu00e4lle fu00fcr die SPDX-Spezifikation. Seitdem haben die SPDX-Lizenzausdru00fccke die Liste der Lizenzen und die Mu00f6glichkeit, mehrere Lizenzen oder spezifische Ausnahmen davon auszudru00fccken, verbessert.
CycloneDX 1.5 und SPDX 2.3 und hu00f6her unterstu00fctzen die Angabe kommerzieller Lizenzen zusammen mit ihren Texten und Links zu externen Dokumenten.
Leider kommt es nur allzu hu00e4ufig vor, dass man in SBOMs auf ungu00fcltige Lizenz-IDs oder Lizenzausdru00fccke stu00f6u00dft.
4. Gesichtsloser-SBOM
Die SBOM existiert im Kontext einer Software- oder Hardwarekomponente eines Systems. Ohne eine ordnungsgemäße Identifizierung der Komponente selbst wird der Rest der SBOM daher zu einer Zutatenliste für etwas Unbekanntes. Die NTIA-Mindestelemente schlagen vor, die Komponente mit Name, Version und anderen eindeutigen Identifikatoren zu identifizieren, um spezifische Abfragen wie die Suche in Schwachstellendatenbanken zu unterstützen.
Es kommt jedoch häufig vor, dass SBOMs ohne diesen Mindestdatensatz zu finden sind.
Ein Beispiel:
Beachten Sie, dass in der Hauptkomponente keine Version angegeben ist und keine Schwachstellenidentifikation vorhanden ist. Dies macht die SBOM unbrauchbar für die Verfolgung von Schwachstellen über Versionen hinweg und für den Abgleich von SBOMs in der Reihenfolge von Produktveröffentlichungen. Die Entschlüsselung der Version 6.2.12-rc230906104347 erfordert produktspezifische, fehleranfällige Anpassungen.
5. SBOM-Burrito
Die am hu00e4ufigsten verwendeten SBOM-Spezifikationen, CycloneDX und SPDX, weisen ein erhebliches Mau00df an Flexibilitu00e4t auf. Leider nehmen einige SBOM-Generatoren einen Umweg und verpacken den SBOM-Inhalt mit zusu00e4tzlichen Daten.
Ein Beispiel:u200d
Dies entspricht keiner der beiden Spezifikationen, und es ist ein menschliches Eingreifen erforderlich, um zu erkennen, dass die eigentliche SBOM am u201esbomu201c-Knoten beginnt.
Die Angaben fu00fcr appID, scanId, type und repo:id sind Details, die auu00dferhalb des Bereichs dieses Tools nicht anwendbar sind. Dies macht die automatisierte Nutzung einer solchen SBOM zu einer improvisierten Notlu00f6sung.
Daru00fcber hinaus verfu00fcgt diese u201eBurrito-Verpackungu201d u00fcber keine Versionierung und kann jegliche nachgelagerte Automatisierung ohne Vorwarnung unbrauchbar machen.
Interlynk mu00f6chte die Offenlegung von Sicherheitsdaten einfach, transparent und automatisiert gestalten. Das Open-Source-Tool von Interlynk, sbomqs, kann die hu00e4ufigsten Probleme mit SBOMs identifizieren und ist offen fu00fcr die Nachverfolgung anderer hu00e4ufiger Fehler, die Ihnen auffallen. Sie ku00f6nnen uns gerne unter hello@interlynk.io kontaktieren.