Was ist eine Software Bill of Materials (SBOM)?

Eine Software Bill of Materials (SBOM) ist eine strukturierte Auflistung aller Software-Komponenten, aus denen ein Softwareprodukt besteht. Die SBOM dient als eine Art Software-Stückliste oder Inventar und bietet einen vollständigen Überblick über die Bestandteile einer Anwendung oder eines Systems.

Eine SBOM enthält typischerweise Informationen wie:

• Namen der Komponenten
• Versionen
• Lizenzen
• Herkunft (Anbieter oder Repository)
• Abhängigkeiten untereinander
• Prüfsummen
• Sicherheitsinformationen
• Lebenszyklusdaten

Der Hauptzweck einer SBOM ist es, Transparenz über die Zusammensetzung eines Softwareprodukts zu schaffen. Sie hilft allen Beteiligten - Entwicklern, Anwendern, Prüfern und Regulierern - zu verstehen, was genau in einem Softwareprodukt enthalten ist. Diese Transparenz ist eine wichtige Grundlage für Sicherheit, Compliance und Wartbarkeit in zunehmend komplexen Software-Lieferketten.

Einschlägige Standards für das Format und den Inhalt von SBOMs sind beispielsweise SPDX (Software Package Data Exchange), CycloneDX und SWID (Software Identification Tags). Diese Standards ermöglichen den einheitlichen Austausch und die maschinelle Verarbeitung von SBOM-Daten über Organisationsgrenzen hinweg.

Warum sind SBOMs wichtig für die Cybersicherheit?

Die Bedeutung von SBOMs hat in den letzten Jahren stark zugenommen. Ein Hauptgrund dafür ist die wachsende Komplexität moderner Softwaresysteme und ihrer Lieferketten. Anwendungen bestehen heute oft aus hunderten oder tausenden Komponenten, die aus verschiedensten Quellen stammen - eigene Entwicklung, Open-Source-Komponenten, Dritthersteller, Cloud-Dienste.

Dieser hohe Grad an Komponentisierung und Wiederverwendung bringt viele Vorteile, aber auch neue Herausforderungen. Es wird zunehmend schwierig, den Überblick über alle Bestandteile und Abhängigkeiten zu behalten und deren Sicherheit und Compliance zu gewährleisten. Ohne eine SBOM weiß man oft nicht genau, was man eigentlich alles nutzt und welche Risiken damit verbunden sein könnten.

Hinzu kommen steigende regulatorische Anforderungen und Haftungsrisiken. Ein Meilenstein war die Executive Order 14028 des US-Präsidenten vom Mai 2021, die Bundesbehörden verpflichtet, nur noch Software mit SBOMs zu beschaffen. Auch Gesetze wie der EU Cyber Resilience Act enthalten Vorgaben zur Transparenz und Nachverfolgbarkeit von Software-Lieferketten. Unternehmen, die keine SBOMs bereitstellen, laufen Gefahr, Aufträge und Reputation zu verlieren.

SBOMs sind ein zentrales Werkzeug, um diesen Herausforderungen zu begegnen. Sie schaffen die nötige Transparenz, um Sicherheitsrisiken und Compliance-Verstöße in Softwareprodukten frühzeitig zu erkennen und zu beheben. Gleichzeitig erleichtern sie die Zusammenarbeit zwischen allen Beteiligten in der Software-Lieferkette, vom Komponentenhersteller bis zum Endanwender.

SBOMs zur Verbesserung der Cybersicherheit

Ein Hauptnutzen von SBOMs liegt in der Verbesserung der Cybersicherheit. Sie ermöglichen es, Schwachstellen und Risiken in den verwendeten Komponenten schnell zu identifizieren und zu beheben. Denn viele erfolgreiche Cyberangriffe nutzen bekannte Sicherheitslücken in veralteten oder fehlkonfigurierten Softwarekomponenten aus.

Mit einer SBOM hat man einen aktuellen Überblick, welche Versionen welcher Komponenten im Einsatz sind. Dadurch kann man beispielsweise gezielt nach Komponenten mit bekannten Schwachstellen suchen, Sicherheitsupdates einspielen oder riskante Komponenten austauschen. Auch für forensische Analysen nach Sicherheitsvorfällen sind die Informationen aus SBOMs oft entscheidend.

Die Nutzung von SBOMs trägt auch dazu bei, Sicherheit und Datenschutz bereits in den Entwicklungsprozess zu integrieren (Secure Development Lifecycle, Privacy by Design). Durch den Abgleich von SBOM-Daten mit Schwachstellendatenbanken und Best Practices können Sicherheitsrisiken schon bei der Komponentenauswahl und im Architekturentwurf vermieden werden.

In Verbindung mit modernen DevSecOps-Ansätzen lässt sich die SBOM-Erstellung und -Prüfung weitgehend automatisieren und in den CI/CD-Prozess integrieren. Gleichzeitig unterstützen SBOMs Konzepte wie Zero Trust Architekturen und Least Privilege, indem sie die Angriffsfläche transparent machen und die Vergabe von Zugriffsrechten erleichtern.

SBOMs für effizientes Lizenz- und Compliance-Management

Neben der Sicherheit ist das Lizenz- und Compliance-Management ein wichtiges Einsatzfeld für SBOMs. Da Softwareprodukte heute oft eine Vielzahl von Open-Source- und Drittanbieter-Komponenten enthalten, ist die Einhaltung der damit verbundenen Lizenzbedingungen eine komplexe Herausforderung.

Eine SBOM schafft hier die nötige Transparenz, indem sie alle in einem Produkt enthaltenen Lizenzen auflistet. So lassen sich Konflikte zwischen Lizenzen sowie rechtliche und finanzielle Risiken frühzeitig erkennen und vermeiden. Auch die Erfüllung von Dokumentationspflichten wie Urheberrechtshinweise und Attributionen wird erleichtert.

Für Unternehmen, die Software anbieten oder nutzen, sind SBOMs eine wichtige Grundlage für Due-Diligence-Prüfungen und Compliance-Nachweise. Sie helfen beispielsweise bei der Bewertung der Rechtssicherheit von Softwareprodukten im Einkaufsprozess oder bei der Vorbereitung von Audits. Durch standardisierte, maschinenlesbare SBOM-Formate lassen sich solche Prüfungen weitgehend automatisieren.

Auch für die Einhaltung von Branchenstandards und Zertifizierungen wie ISO 27001 oder SOC 2 sind SBOMs oft eine Voraussetzung. Sie belegen, dass ein Unternehmen seine Software-Lieferkette im Griff hat und die Herkunft und Sicherheit der verwendeten Komponenten nachweisen kann.

Wie erstellt man eine SBOM?

Es gibt verschiedene Möglichkeiten, eine SBOM zu erstellen, je nach Art und Umfang der Software, verfügbaren Werkzeugen und gewünschtem Detailgrad. Grundsätzlich kann die Erstellung manuell oder automatisiert erfolgen und sich auf den Quellcode und/oder die kompilierten Binärdateien beziehen. Im Folgenden finden Sie eine Schritt-für-Schritt-Anleitung zur Erstellung einer SBOM:

1. Identifizieren Sie alle Komponenten Ihrer Software:
   • Erfassen Sie sämtliche Open-Source- und Drittanbieter-Komponenten, die in Ihrem Softwareprodukt verwendet werden.
   • Berücksichtigen Sie dabei Bibliotheken, Frameworks, Tools und andere Abhängigkeiten.
2. Sammeln Sie relevante Informationen zu jeder Komponente:
   • Notieren Sie den Namen, die Version und den Anbieter oder die Herkunft jeder Komponente.
   • Ermitteln Sie die zugehörigen Lizenzen und prüfen Sie auf mögliche Konflikte oder Einschränkungen.
   • Erfassen Sie weitere Metadaten wie Beschreibungen, Änderungsprotokolle und bekannte Schwachstellen.
3. Wählen Sie ein geeignetes SBOM-Format:
   • Entscheiden Sie sich für ein standardisiertes Format wie SPDX oder CycloneDX, um Interoperabilität und Austauschbarkeit zu gewährleisten.
   • Legen Sie den gewünschten Detailgrad fest, z.B. ob Hashwerte, Konfigurationen oder Sicherheitsinformationen enthalten sein sollen.
4. Erstellen Sie die SBOM:
   • Bei manueller Erstellung pflegen Sie die gesammelten Informationen in einer strukturierten Liste, z.B. einer Tabellenkalkulation oder einem Textdokument.
   • Nutzen Sie für die automatisierte Erstellung Tools wie Software Composition Analysis (SCA) Scanner, die den Quellcode oder die Binärdateien analysieren und eine SBOM generieren.
   • Integrieren Sie die SBOM-Erstellung möglichst in Ihre Build-Prozesse und CI/CD-Pipelines, um stets aktuelle SBOMs zu erhalten.
5. Überprüfen und aktualisieren Sie die SBOM regelmäßig:
   • Gleichen Sie die SBOM mit den tatsächlich verwendeten Komponenten ab, um Vollständigkeit und Korrektheit sicherzustellen.
   • Aktualisieren Sie die SBOM bei Änderungen an den Komponenten, z.B. durch Updates oder Erweiterungen.
   • Prüfen Sie regelmäßig auf neu bekannt gewordene Schwachstellen oder Lizenzprobleme in den erfassten Komponenten.
6. Nutzen Sie die SBOM für Sicherheits- und Compliance-Zwecke:
   • Analysieren Sie die SBOM, um potenzielle Sicherheitsrisiken oder Lizenzkonflikte zu identifizieren und zu beheben.
   • Verwenden Sie die SBOM als Nachweis für die Einhaltung von Compliance-Anforderungen und für Audits.
   • Stellen Sie die SBOM Ihren Kunden und Partnern zur Verfügung, um Transparenz und Vertrauen zu schaffen.

Die Erstellung einer SBOM erfordert zunächst etwas Aufwand, lohnt sich aber langfristig durch bessere Kontrolle über die verwendeten Komponenten und deren Risiken. Durch Automatisierung und Integration in bestehende Prozesse lässt sich der Aufwand deutlich reduzieren und die Aktualität der SBOM gewährleisten. Eine gut gepflegte SBOM ist ein wertvolles Werkzeug für die Sicherheit und Compliance Ihrer Software-Lieferkette.

Best Practices zur SBOM-Erstellung

• Einbindung aller relevanten Stakeholder wie Entwicklung, Security, Einkauf und Rechtsabteilung, um Anforderungen und Verantwortlichkeiten klar zu definieren.
• Etablierung standardisierter Prozesse für die Erstellung, Prüfung, Freigabe und Verteilung von SBOMs, idealerweise automatisiert innerhalb der CI/CD-Pipeline.
• Nutzung eines standardisierten, maschinenlesbaren SBOM-Formats wie SPDX oder CycloneDX für Interoperabilität und Austauschbarkeit.
• Sicherstellung der Aktualität und Vollständigkeit der SBOM-Daten durch regelmäßige Updates und Synchronisation mit den tatsächlich eingesetzten Komponenten.
• Integration von SBOM-Daten in Sicherheits- und Compliance-Prozesse wie Vulnerability Management, Lizenzprüfungen und Risikobewertungen.
• Bereitstellung von SBOMs für Kunden und Partner, um Transparenz und Vertrauen zu schaffen und deren Sicherheits- und Compliance-Anforderungen zu erfüllen.
• Schulung von Entwicklern und anderen Beteiligten im Umgang mit SBOMs und den zugrundeliegenden Konzepten wie Lizenzen und Schwachstellen.

Herausforderungen und Zukunft von SBOMs

Trotz der vielen Vorteile gibt es noch einige Herausforderungen bei der Einführung und Nutzung von SBOMs. Dazu gehören:

• Mangelnde Awareness und Expertise bezüglich SBOMs in vielen Unternehmen. Oft fehlt das Verständnis für den Nutzen und die notwendigen Prozesse.
• Unvollständigkeit und Inkonsistenzen in SBOM-Daten aufgrund komplexer Software-Lieferketten und häufiger Änderungen. Die Pflege aktueller und korrekter SBOMs erfordert viel Disziplin.
• Fehlende Standardisierung und Interoperabilität zwischen verschiedenen SBOM-Formaten und -Werkzeugen. Die Auswahl des richtigen Ansatzes und die Integration in bestehende Prozesse kann schwierig sein.
• Bedenken hinsichtlich der Offenlegung von SBOM-Daten, z.B. aus Wettbewerbs- oder Sicherheitsgründen. Hier sind klare Richtlinien und Schutzmaßnahmen nötig.
• Skalierbarkeit und Performanz von SBOM-Prozessen, gerade bei sehr großen und häufig aktualisierten Softwareprojekten. Automatisierung und optimierte Werkzeuge sind hier gefragt.

Trotz dieser Herausforderungen arbeiten Standardisierungsgremien, Open-Source-Initiativen und Tool-Anbieter kontinuierlich an der Weiterentwicklung des SBOM-Ökosystems. Beispiele sind die Linux Foundation mit dem SPDX-Standard, die OWASP mit CycloneDX oder das NTIA SBOM-Projekt in den USA.

Für die Zukunft ist zu erwarten, dass SBOMs auch über den klassischen Softwarebereich hinaus an Bedeutung gewinnen. Mit zunehmender Vernetzung und Automatisierung werden sie auch für IoT-Geräte, Embedded Systems oder Operational Technology (OT) relevant. Die Sicherheit und Nachvollziehbarkeit von Hard- und Software in kritischen Infrastrukturen wird immer wichtiger.

Auch die Integration von SBOM-Daten mit verwandten Bereichen wie dem Vulnerability Management, der Threat Intelligence oder dem Lizenzmanagement wird voranschreiten. Ziel ist ein ganzheitlicher Blick auf die Sicherheit und Compliance von Systemen über ihren gesamten Lebenszyklus.

Fazit

Software Bill of Materials sind zu einem unverzichtbaren Werkzeug für das Management von Software-Lieferketten und -Risiken geworden. Sie schaffen Transparenz über die Bestandteile von Softwareprodukten und helfen bei der Erkennung und Behebung von Sicherheitslücken und Compliance-Verstößen.

Die Erstellung und Nutzung von SBOMs ist noch mit einigen Herausforderungen verbunden, von der Standardisierung über die Automatisierung bis hin zum Umgang mit sensiblen Daten. Dennoch ist der Trend klar: Immer mehr Unternehmen, Behörden und Regulierer verlangen SBOMs als Voraussetzung für die Beschaffung und den Einsatz von Software.

Für Anbieter und Nutzer von Software wird es damit immer wichtiger, sich mit SBOMs auseinanderzusetzen und entsprechende Prozesse und Werkzeuge zu etablieren. Die Investition lohnt sich, denn sie schafft nicht nur mehr Sicherheit und Compliance, sondern auch mehr Vertrauen bei Kunden und Partnern. Gerade in Zeiten wachsender Cyber-Bedrohungen ist das ein entscheidender Wettbewerbsvorteil.

Mit einer konsequenten SBOM-Strategie können Unternehmen nicht nur Risiken minimieren, sondern auch ihre Agilität und Innovationskraft in der Softwareentwicklung steigern. Denn wer seine Komponenten und Abhängigkeiten im Griff hat, kann auch schneller und sicherer auf neue Anforderungen und Technologien reagieren. In diesem Sinne sind SBOMs ein wichtiger Baustein für eine zukunftsfähige und vertrauenswürdige Software-Lieferkette.