Die 5 häufigsten Probleme bei SBOMs
15.01.2024
Interlynk
Ein Software Bill of Materials (SBOM) hilft dabei, eine Bestandsaufnahme der Softwarekomponenten und der damit verbundenen Risiken zu erstellen und zu kommunizieren. Die regulatorischen und Überwachungsbedürfnisse von SBOM sind gut verstanden. Dennoch erfordert der Aufbau eines „guten“ SBOM das Vermeiden mehrerer Fallstricke, da einige populäre SBOM-Builder noch in der Entwicklung sind.
Hier sind die fünf häufigsten Probleme, auf die wir beim Umgang mit SBOMs stoßen.
1. Spezifikationen Verwechslungen
Die häufigsten treten in Tools auf, die mehr als eine Spezifikation unterstützen. Wir stellen konsequent fest, dass die Implementierung der Verarbeitung einer Spezifikation zu ungültigen Werten für die andere führt.
2. Fälschlich zugeordnete Identifikatoren
CPE und PURL sind zwei der häufigsten Möglichkeiten, Komponenten weltweit zu identifizieren, insbesondere im Schwachstellenmanagement. Darüber hinaus erfordern sowohl CycloneDX als auch SPDX dokumentenspezifische interne eindeutige Identifikatoren ( bom-ref und SPDXID jeweils). Dies hilft dabei, zusätzliche Komponenteninformationen zu verfolgen, wie z.B. die Beziehung zwischen Komponenten.
Aber diese Anforderungen an die Identifikatoren können zu zwei häufigen Arten von Herausforderungen führen:
2.1 Fehlende oder Ungültige CPE/PURL
Ein SBOM, das für CPE oder PURL leer ist, ist für das Schwachstellentracking nicht hilfreich. Es kann dennoch als Zutatenliste und Lizenzinventar dienen, wenn Lizenzinformationen vorhanden sind.
2.2 Inkonsistente Eindeutige Identifikatoren
Das andere häufigste Problem ist ein SBOM mit ungültigen oder doppelten Identifikatoren, die im SBOM vorhanden sind. Der bom-ref und SPDXID sollen im Dokument eindeutig sein und haben spezifische Einschränkungen (z.B. sollte SPDXID keine Sonderzeichen enthalten).
3. Lizenz zur Verwirrung
Das Festlegen und Verfolgen von Open-Source-Softwarelizenzen war einer der frühesten Anwendungsfälle für die SPDX-Spezifikation. Seitdem haben sich die SPDX-Lizenzausdrücke hinsichtlich der Liste von Lizenzen und der Möglichkeit, mehrere Lizenzen oder spezifische Ausnahmen dafür auszudrücken, verbessert.
CycloneDX 1.5 und SPDX 2.3 und höher unterstützen die Angabe von kommerziellen Lizenzen zusammen mit deren Texten und Links zu externen Dokumenten.
Leider ist es viel zu häufig, auf ungültige Lizenz-IDs oder Lizenzausdrücke in SBOMs zu stoßen.
4. Gesichtsloses SBOM
Das SBOM existiert im Kontext einer Software- oder Hardwarekomponente eines Systems. Daher wird ohne die ordnungsgemäße Identifizierung der Komponente selbst der Rest des SBOM zu einer Zutatenliste für eine Unbekannte. NTIA Mindestbestandteile schlägt vor, die Komponente mit Name, Version und Andere eindeutige Identifikatoren zu identifizieren, um spezifische Suchen wie das Nachschlagen in Schwachdatenbanken zu unterstützen.
Es ist jedoch üblich, SBOMs ohne diesen Mindestdatensatz zu finden.
Ein Beispiel:
Beachten Sie, dass keine Version in der primären Komponente angegeben ist und keine Schwachstellenidentifizierung vorhanden ist. Dies macht das SBOM unbrauchbar für die Verfolgung von Schwachstellen über Versionen hinweg und für die Kollision von SBOM in der Reihenfolge der Produkteinführungen. Das Entschlüsseln der Version 6.2.12-rc230906104347 erfordert produktspezifische fehleranfällige Anpassungen.
5. SBOM Burrito
Die am häufigsten verwendeten SBOM-Spezifikationen, CycloneDX und SPDX, haben einen fairen Grad an Flexibilität. Leider nehmen einige SBOM-Builder einen Umweg, um SBOM-Inhalte mit zusätzlichen Daten zu umhüllen.
Ein Beispiel:
Dies folgt keiner der beiden Spezifikationen, und eine menschliche Intervention ist erforderlich, um zu verstehen, dass das tatsächliche SBOM am „sbom“-Knoten beginnt.
Die appID, scanId, type und repo:id sind alles Details, die außerhalb des Anwendungsbereichs dieses Tools nicht zutreffend sind. Dies macht die Automatisierung des Konsums eines solchen SBOM zu einer Notlösung.
Darüber hinaus hat die Burrito-Hülle keine Versionierung und kann jede nachgelagerte Automatisierung ohne Vorwarnung unterbrechen.
Interlynk versucht, die Sicherheitsübertragung einfach, offensichtlich und automatisiert zu gestalten. Das Open-Source-Tool von Interlynk, sbomqs, kann die häufigsten Probleme mit den SBOMs erkennen und ist offen für die Verfolgung anderer häufig auftretender Fehler, die Sie möglicherweise sehen. Zögern Sie nicht, uns unter hello@interlynk.io zu kontaktieren.