Der umfassende Leitfaden zu SBOMs

SBOMs (Software Bill of Materials) sind strukturierte Dokumente, die die Softwarekomponenten einer Anwendung verzeichnen. Je nach Einsatzzweck können SBOMs auch Angaben zu Softwarelizenzen, Schwachstellen und weitere Metadaten enthalten, die für die Software-Transparenz wichtig sind.

SBOMs gibt es seit Jahrzehnten, doch in den letzten Jahren haben sie stark an Bedeutung gewonnen, angetrieben von regulatorischen Vorgaben und einem wachsenden Bewusstsein für Sicherheitsrisiken in der Software-Lieferkette. Die 2021 erlassene Executive Order der Biden-Regierung zur Cybersicherheit schrieb SBOMs für Unternehmen vor, die an US-Bundesbehörden verkaufen. Es folgten weitere SBOM-bezogene Anforderungen, etwa von der FDA, aus PCI-DSS und aus dem EU Cyber Resilience Act.

Mit seinem Wachstum ist das SBOM-Ökosystem auch ausgereifter geworden. Die beiden wichtigsten maschinenlesbaren SBOM-Spezifikationen (SPDX und CycloneDX) unterstützen zusammen inzwischen Hunderte unterschiedlicher Datenfelder. Neue Tools, die Teile des SBOM-Lebenszyklus automatisieren, erscheinen gefühlt im Wochentakt. Und neue, SBOM-nahe Formate wie VEX (für das Schwachstellenmanagement) entstehen, um bestimmte Anwendungsfälle abzudecken.

Es gibt keinen allgemeingültigen Standard dafür, was eine gültige SBOM ausmacht. In der Praxis enthalten die meisten SBOMs jedoch einen gemeinsamen Satz von Datenfeldern, die die Komponenten einer Anwendung beschreiben.

Diese Datenfelder decken sich mit den Leitlinien der US-Behörde NTIA zu den Mindestbestandteilen einer SBOM. Sie lauten:

• Name des Anbieters
• Name der Komponente
• Version der Komponente
• Weitere eindeutige Kennungen
• Abhängigkeitsbeziehung
• Ersteller der SBOM-Daten
• Zeitstempel

Zusätzlich zu diesen sieben Datenfeldern verlangt die US-Regierung, dass die SBOM in einem maschinenlesbaren Format wie CycloneDX oder SPDX übermittelt wird. Für moderne Sicherheitsteams ist das ohnehin unverzichtbar.

Schließlich umfassen die SBOM-Anforderungen der US-Regierung auch einen Abschnitt zu „Praktiken und Prozessen“, also dazu, wie und wann SBOMs aktualisiert und bereitgestellt werden sollen. Auch das ist nur für Unternehmen verpflichtend, die an US-Bundesbehörden verkaufen, gilt aber für die meisten Anwendungsfälle als bewährte Praxis. Der Abschnitt behandelt etwa, wie häufig SBOMs erzeugt werden sollen (nach neuen Builds oder Releases), welche Tiefe der Abhängigkeiten sie abdecken sollen (transitive und direkte) und wie SBOMs verteilt werden sollen (zeitnah und mit Zugriffskontrollen).

Heute sind zwei vollwertige SBOM-Formate gebräuchlich: SPDX (System Package Data Exchange, früher Software Package Data Exchange) und CycloneDX. Beide gehören zu den drei Formaten, die die Executive Order 14028 zulässt; das dritte ist SWID, das anders als CycloneDX und SPDX allerdings keine vollständige SBOM-Spezifikation ist.

Neben diesen Spezifikationen lassen sich SBOM-Informationen durchaus auch in anderen Formaten und Strukturen weitergeben. FOSSA-Nutzerinnen und -⁠Nutzer können ihre Softwarekomponenten beispielsweise zusätzlich zu SPDX und CycloneDX auch als HTML, reinen Text, Markdown, PDF und CSV ausgeben. In der Praxis erzeugen und verarbeiten die meisten Unternehmen SBOMs jedoch entweder in SPDX oder in CycloneDX.

Angriffe auf die Software-Lieferkette wie Log4Shell haben deutlich gemacht, wie wichtig es ist, schnell feststellen zu können, ob und wo ein Unternehmen bestimmte Softwarekomponenten einsetzt. SBOMs entwickeln sich rasch zu einem unverzichtbaren Werkzeug, nicht nur für die Reaktion auf Zero-Day-Schwachstellen, sondern auch für weitere Sicherheitsaufgaben.

Die wichtigsten Wege, auf denen SBOMs Sicherheitsteams unterstützen:

Transparenz über Schwachstellen schaffen

Die allermeisten modernen Anwendungen setzen in großem Umfang Open Source ein, und SBOMs helfen dabei, den Überblick über mögliche Schwachstellen in diesem Code zu behalten.

Das funktioniert auf zwei Wegen. Zum einen sollte die SBOM selbst aktuelle Angaben zu Komponentenname, Version und einer eindeutigen Kennung enthalten. Wird eine neue Schwachstelle mit hohem Risiko bekannt, lässt sich in der SBOM nachsehen, ob das Produkt eine betroffene Version der Komponente enthält. Zum anderen führen Tools wie FOSSA die SBOMs all Ihrer Anwendungen zusammen und ermöglichen die Suche nach CVE oder nach Komponente und Version, um Schwachstellen im gesamten Open-Source-Bestand aufzuspüren.

Wichtig ist außerdem: SBOMs helfen nicht nur dabei, Schwachstellen in der eigenen Codebasis zu finden. Wer SBOMs von seinen Softwarelieferanten einliest, kann auch Risiken in der Software-Lieferkette verstehen und eindämmen, die von Dritten ausgehen.

VEX und Behebung unterstützen

VEX (Vulnerability Exploitability eXchange) bezeichnet eine Reihe von Formaten, die angeben, ob eine Schwachstelle in einem bestimmten Produkt tatsächlich ausnutzbar ist. Häufiger noch enthalten sie eine begründete Feststellung, dass das Produkt nicht betroffen ist. Da die allermeisten der Zehntausenden jährlich gemeldeten Schwachstellen nicht ausnutzbar sind, hilft VEX dabei, die Behebung auf die tatsächlich ausnutzbaren zu konzentrieren.

Sowohl CycloneDX als auch SPDX unterstützen VEX. Sie können VEX-Informationen direkt in die SBOM einbetten oder auf ein externes VEX-Dokument verweisen, was in den meisten Fällen zu empfehlen ist.

Neben der Frage der Ausnutzbarkeit unterstützen SBOMs und SBOM-Tools auch die eigentliche Behebung. Ein Tool wie FOSSA zeigt zur Schwachstelle den zugehörigen Kontext an: CVSS-Wert, EPSS-Wert, Herkunftspfad der Komponente und Hinweise zur Behebung, einschließlich der nächsten sicheren Version.

Die Wurzeln heutiger SBOMs reichen bis 2011 zurück, als die erste Fassung der SPDX-Spezifikation erschien. Damals war SPDX vor allem für Anwendungsfälle der Lizenz-Compliance gedacht: Die Linux Foundation, die SPDX betreut, stellte das Format als Baustein ihres Open Compliance Program vor.

Und obwohl SBOMs heute häufig für Sicherheit und regulatorische Compliance erstellt werden, bleibt die Open-Source-Lizenz-Compliance ein wichtiger Anwendungsfall.

SPDX kennt eigens für Lizenzangaben gedachte Eigenschaften: License Identifiers und License Expressions. License Identifiers sind standardisierte Kurzformen gängiger Lizenzen, etwa „Apache-2.0“ für die Apache License 2.0. License Expressions liefern zusätzlichen Kontext für Feinheiten wie Mehrfachlizenzierung oder ein Wahlrecht zwischen Lizenzen.

Auch CycloneDX unterstützt SPDX License Expressions und Identifiers sowie vollständige Lizenznamen, was die Lizenz-Compliance über Formate hinweg vereinheitlicht.

Für viele Unternehmen beginnt die Erstellung von SBOMs für die Lizenz-Compliance bereits auf Tool-Ebene. Wenn Sie etwa in FOSSA eine SBOM erzeugen, können Sie eine ganze Reihe von Lizenzdatenfeldern ein- oder ausschließen, darunter den vollständigen Lizenztext, deklarierte und erkannte Lizenzen. Richtet sich Ihre SBOM vor allem an Compliance-Verantwortliche, empfehlen wir, diese Daten aufzunehmen.

Unternehmen können die SBOM-Management-Plattform von FOSSA für eine ganze Reihe von SBOM-Aufgaben einsetzen. Hier ein kurzer Überblick. (SBOMs lassen sich auch über die CLI und die API von FOSSA verwalten.)

SBOMs erstellen (in kostenlosen und kostenpflichtigen Konten)

• Schritt 1: Falls noch nicht geschehen, legen Sie ein FOSSA-Konto an und importieren Sie Ihre Projekte.
• Schritt 2: Öffnen Sie das FOSSA-Projekt oder die Release Group, die Ihre SBOM abbilden soll. Wählen Sie dann im Menü auf der rechten Seite „Generate SBOM Report“.
• Schritt 3: Passen Sie Ihre SBOM an: Wählen Sie das Format und legen Sie fest, welche Datenfelder und welche Angaben zu Abhängigkeiten enthalten sein sollen.
• Schritt 4: Entscheiden Sie, wie Sie Ihre SBOM verteilen. Sie können sie selbst herunterladen und weitergeben, sie von FOSSA hosten lassen und die Live-URL teilen oder sie über unser SBOM Portal bereitstellen.

SBOMs von Dritten einlesen und auswerten (nur in kostenpflichtigen Konten)

Mit einem kostenpflichtigen FOSSA-Konto können Sie SBOMs von Drittanbietern in SPDX oder CycloneDX importieren, zusammenführen und auswerten. So geht es:

• Schritt 1: Klicken Sie oben rechts in Ihrem FOSSA-Dashboard auf „Add Projects“. Laden Sie Ihre SBOM anschließend über „Import SBOM“ hoch.
• Schritt 2: Fügen Sie Ihre SBOM-Datei im JSON- oder XML-Format auf der Upload-Seite hinzu. Auch ein Massenimport mehrerer Dateien auf einmal wird unterstützt.
• Schritt 3: Nach dem Hochladen erscheint die SBOM in Ihrer FOSSA-Projektliste. Von dort aus können Sie sie wie ein eigenes Projekt auswerten, also Lizenzen und Schwachstellen prüfen, Hinweise zur Behebung ansehen und so weiter.