Tools zur automatischen Erstellung von Software Bill of Materials (SBOM)

Anmerkung: Dieser Blogpost wurde für das Modul Enterprise IT (113601a) verfasst.

1. Einleitung

Die fortschreitende Digitalisierung und die zunehmende Vernetzung von Softwaresystemen haben Cybersicherheit zu einem zentralen Thema für Unternehmen, Behörden und Endnutzer gemacht. Transparenz über die eingesetzten Softwarekomponenten ist dabei essenziell, um Sicherheitslücken zu identifizieren und regulatorische Anforderungen zu erfüllen. 

Ein bewährtes Konzept zur Verbesserung dieser Transparenz ist die Software Bill of Materials (SBOM).

Eine SBOM ist eine detaillierte Auflistung aller in einer Software enthaltenen Komponenten, einschließlich Open Source und proprietärer Bibliotheken. Diese Liste hilft Unternehmen, Sicherheitsrisiken frühzeitig zu erkennen und geeignete Maßnahmen zur Behebung von Schwachstellen zu ergreifen. Die manuelle Erstellung einer SBOM ist jedoch zeitaufwändig und fehleranfällig, weshalb automatisierte Tools zunehmend an Bedeutung gewinnen.

2. Bedeutung der SBOM für Cybersicherheit

Eine SBOM bietet einen vollständigen Überblick über alle Softwarekomponenten und erleichtert die schnelle Identifizierung und Behebung von Sicherheitslücken. Besonders Schwachstellen in Drittanbieter-Bibliotheken lassen sich dadurch effizient verwalten und patchen.

Durch die transparente Dokumentation der verwendeten Komponenten und deren Herkunft ermöglichen SBOMs eine schnelle Reaktion auf Sicherheitsvorfälle und sorgen für eine hohe Nachvollziehbarkeit.

Dies wird insbesondere durch zunehmende regulatorische Anforderungen, wie sie in der EU und den USA bestehen, verstärkt. Unternehmen sind verpflichtet, ihre Softwarekomponenten genau zu dokumentieren, und SBOMs bieten eine effektive Lösung, um diese Anforderungen zu erfüllen. [1][2][3]

2.1 Fallbeispiel: Log4j-Sicherheitslücke (CVE-2021-44228)

Ein bekanntes Beispiel für die Bedeutung von SBOMs ist die Log4j-Sicherheitslücke, die Ende 2021 entdeckt wurde. Die Schwachstelle ermöglichte es Angreifern, aus der Ferne beliebigen Code auf verwundbaren Systemen auszuführen (Remote Code Execution, RCE). Da Log4j in vielen Anwendungen und IT-Systemen integriert war, standen Unternehmen vor der Herausforderung, schnell herauszufinden, ob sie betroffen waren.

Unternehmen, die eine SBOM führten, konnten automatisiert überprüfen, ob Log4j in ihren Softwarekomponenten enthalten war. Dies ermöglichte ihnen:

• Eine schnelle Identifikation der betroffenen Systeme und sofortige Einleitung von Sicherheitsmaßnahmen.
• Gezielte Patches und Updates, um Angriffe zu verhindern.
• Transparenz gegenüber Kunden und Partnern, indem sie nachweisen konnten, dass ihre Software sicher ist oder bereits aktualisiert wurde.

Unternehmen ohne eine SBOM hatten hingegen Schwierigkeiten, ihre Abhängigkeiten vollständig zu analysieren, wodurch wertvolle Zeit verloren ging und das Risiko von Angriffen erhöht wurde. Dieses Beispiel verdeutlicht, wie SBOMs helfen können, Sicherheitsrisiken proaktiv zu minimieren und die Reaktionszeit auf Cyberbedrohungen erheblich zu verkürzen. [4]

3. Standards für SBOMs

Für die Erstellung und den Austausch von SBOMs haben sich verschiedene Standards etabliert, die eine einheitliche Darstellung von Software-Komponenten und deren Beziehungen ermöglichen. Zu den prominentesten zählen:

3.1 CycloneDX: 

• Zweck: CycloneDX ist eine Spezifikation für SBOMs, die speziell auf die Bedürfnisse der Sicherheits- und Compliance-Industrie ausgerichtet ist. Sie wurde entwickelt, um eine effiziente und einfach zu verwendende Methode zur Erstellung und Verwaltung von SBOMs zu bieten. [5]
• Ursprung: CycloneDX wurde von der Software- und Sicherheitsindustrie ins Leben gerufen und hat einen starken Fokus auf Sicherheitsaspekte, insbesondere auf die Identifikation von Schwachstellen (z. B. CVEs) in Softwarekomponenten. [5]
• Formate: JSON, XML oder Protobuf-Format. Das JSON-Format ist besonders verbreitet. [5]

3.2 Software Package Data Exchange (SPDX):

•  Zweck: SPDX ist eine Spezifikation, die darauf abzielt, Softwarelizenzen und -komponenten zu dokumentieren. Sie wird häufig in der Open-Source-Community verwendet, um die Lizenzierung von Software und deren Abhängigkeiten zu verwalten. [6][7]
• Ursprung: SPDX wurde ursprünglich von der Linux Foundation entwickelt und zielt darauf ab, die Lizenz-Compliance in der Softwareindustrie zu vereinfachen. [6][7]
• Formate: JSON, XML, YAML, RDF, XLS und tag:value (Flat-Text-Format). [6][7]

4. Regulatorische Anforderungen 

• EU Cyber Resilience Act (CRA): Der CRA betont die Bedeutung von SBOMs, indem er die Hersteller verpflichtet, detaillierte Informationen über die verwendeten Softwarekomponenten bereitzustellen. [1]
• NIST-Richtlinien (USA): Das National Institute of Standards and Technology (NIST) definiert in Executive Order 14028 Anforderungen an Software-Lieferketten und betont die Notwendigkeit maschinenlesbarer SBOMs zur Erhöhung der Cybersicherheit. [2]
• FDA-Anforderungen für Medizingeräte (USA): Die US-amerikanische Food and Drug Administration (FDA) fordert von Herstellern medizinischer Software die Bereitstellung einer SBOM, um Sicherheitsrisiken zu minimieren. [3]

5. Herausforderungen bei der Erstellung und Implementierung von SBOMs

Trotz der zunehmenden Verbreitung von SBOMs gibt es einige Herausforderungen bei der Implementierung:

• Dynamische Abhängigkeiten: In modernen Anwendungen ändern sich Softwarekomponenten häufig, was eine kontinuierliche Aktualisierung der SBOMs erfordert.
• Vertraulichkeit und Datenschutz: In bestimmten Fällen kann die Veröffentlichung eines vollständigen SBOM sensible Informationen über die verwendeten Softwarekomponenten oder deren Lizenzmodelle preisgeben. Unternehmen sollten sicherstellen, dass sensible Daten nicht versehentlich durch ein SBOM offengelegt werden.
• Komplexität der Softwarelandschaft: Moderne Softwareprojekte enthalten oft Tausende von Abhängigkeiten, einschließlich direkter und indirekter Bibliotheken. Die vollständige und genaue Erfassung all dieser Komponenten kann eine große Herausforderung darstellen, insbesondere wenn die Software aus verschiedenen Quellen und Ökosystemen stammt.
• Akzeptanz in der Industrie: Viele Unternehmen haben die Bedeutung und den Nutzen von SBOMs für die Sicherheit noch nicht vollständig erkannt. Ein Großteil der Unternehmen hat entweder keine SBOMs oder nur unvollständige SBOMs implementiert, was darauf hindeutet, dass das Bewusstsein und die Bereitschaft fehlen, die notwendigen Schritte für eine vollständige Implementierung zu unternehmen. [8]

6. Tools zur automatisierten Erstellung von SBOMs

Angesichts der Komplexität moderner Softwareprojekte ist die manuelle Erstellung einer SBOM keine gute Option. Daher gibt es zahlreiche Tools, die diesen Prozess automatisieren.

6.1 Open-Source-Tools

Open-Source-Tools zur automatisierten SBOM-Generierung sind für die Gewährleistung von Transparenz und Sicherheit in Software-Lieferketten unerlässlich. Diese Werkzeuge analysieren Code, Binärdateien und Container, identifizieren Abhängigkeiten und exportieren die Ergebnisse in standardisierte Formate wie SPDX oder CycloneDX. Im Folgenden werden einige der bekanntesten Open-Source-Tools zur Generierung von SBOM vorgestellt.

6.1.1 Syft

Syft ist wahrscheinlich das am weitesten verbreite Tool zur Erstellung von SBOMs. Es ist ein Kommandozeilenwerkzeug, das SBOMs aus Container-Images und Dateisystemen generiert. Syft unterstützt gängige Container-Formate wie OCI, Docker und Singularity und erkennt automatisch die verwendete Linux-Distribution.

Unterstützte Standards: SPDX und CycloneDX [9]

6.1.2 sbom-tool

Das sbom-tool wurde von Microsoft entwickelt. Dieses Toll wurde für hohe Skalierbarkeit und Unternehmenstauglichkeit entwickelt. Es verwendet Microsofts eigene Komponentenerkennungsbibliothek, die verschiedene Paketmanager wie NuGet, Go, npm, pip und Cargo unterstützt. Das SBOM-Tool erzeugt SBOMs im SPDX-Format zur Build-Zeit.

Unterstützte Standards: SPDX [10]

6.1.3 Trivy

Trivy ist ein weiteres beliebtes Tool zur Erstellung von SBOMs, das in der Sicherheits- und Software-Management-Community weit verbreitet ist. Trivy ist bekannt für seine Fähigkeit, Container-Images, Dateisysteme und Git-Repositories auf Schwachstellen und unsichere Komponenten zu scannen. Zusätzlich bietet es auch  Schwachstellenanalyse an. Das Tool ist einfach zu bedienen und wird in vielen CI/CD-Pipelines integriert, um eine kontinuierliche Sicherheitsüberprüfung während des Build-Prozesses zu gewährleisten.

Unterstützte Standards: SPDX und CycloneDX [11]

6.1.4 cdxgen

Der CycloneDX Generator (cdxgen) ist das offizielle OWASP SBOM Tool. Er unterstützt eine Vielzahl von Programmiersprachen, darunter gängige Sprachen wie C/C++, JavaScript, Java, Python, aber auch weniger bekannte Sprachen wie Haskell. Es wird mit einer CLI geliefert, die lokal oder als Teil einer CI/CD-Pipeline scannen kann, und einem API-Server, der einen /bom-Endpunkt bereitstellt, um die SBOM bei Bedarf zu überprüfen. 

Unterstützte Standards: CycloneDX [12]

6.2 Erweiterung der SBOM-Analyse durch Tool-Kombinationen

In der Praxis werden SBOM-Generierungstools häufig miteinander kombiniert, um eine umfassendere Analyse und eine bessere Sicherheitsabdeckung zu gewährleisten. Während einige Tools primär auf die Identifikation von Softwarekomponenten spezialisiert sind, bieten andere erweiterte Sicherheitsfunktionen oder spezifische Integrationen für bestimmte Entwicklungsumgebungen.

Ein Beispiel hierfür ist die Kombination von Syft zur Erkennung von Softwarekomponenten mit OWASP Dependency-Check, das zusätzlich bekannte Sicherheitslücken in den erkannten Abhängigkeiten identifiziert. 

Diese Kombinationen ermöglichen es Unternehmen, ihre SBOM-Strategie individuell anzupassen und die Vorteile verschiedener Tools optimal zu nutzen, um eine sichere und transparente Software-Lieferkette zu gewährleisten. [13]

7. Zukunftsausblick

Die Bedeutung von SBOMs wird in den kommenden Jahren weiter zunehmen, da sie zunehmend mit regulatorischen Anforderungen und der Bekämpfung wachsender Sicherheitsrisiken verknüpft werden. Zukünftige Entwicklungen könnten die verstärkte Integration von SBOMs in Sicherheitsplattformen sowie die Nutzung von KI-gestützten Analysetools umfassen. Dies würde eine schnellere Identifizierung und Behebung von Sicherheitslücken ermöglichen und damit die Sicherheit von Softwaresystemen deutlich verbessern.

Eine wichtige Rolle spielt auch der Cyber Resilience Act (CRA), der im Dezember 2024 mit Übergangsfristen bis zur vollständigen Umsetzung am 11. Dezember 2027 in Kraft getreten ist. Dieses Gesetz wird die Anforderungen an die Sicherheit von Softwareprodukten weiter verschärfen und die Rolle von SBOMs bei der Einhaltung von Cybersicherheitsstandards weiter stärken. [1]

8. Fazit

Die SBOM ist ein wesentlicher Bestandteil zur Verbesserung der Cybersicherheit und zur Einhaltung regulatorischer Anforderungen. Sie bietet Transparenz über Softwarekomponenten und hilft, Sicherheitslücken schnell zu identifizieren und zu beheben. Automatisierte Tools wie Syft, Trivy und CycloneDX erleichtern die Erstellung von SBOMs und integrieren sie in DevSecOps-Workflows. Insgesamt werden SBOMs in Zukunft eine noch zentralere Rolle spielen, um den steigenden Anforderungen an Sicherheit und Transparenz in der Softwareentwicklung gerecht zu werden.

Literaturverzeichnis

1. Bundesamt für Sicherheit in der Informationstechnik (BSI) (o. J.): Technische Richtlinie TR-03183. URL: https://www.bsi.bund.de/dok/TR-03183 (abgerufen am 24. Februar 2025)
2. National Institute of Standards and Technology (NIST) (2024): Executive Order 14028: Improving the Nation’s Cybersecurity. URL: https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 (abgerufen am 24. Februar 2025)
3. Federal Food and Drug Administration (FDA) (2023): FDA Requirements for Medical Device Software. URL: https://www.fda.gov/media/119933/download (abgerufen am 24. Februar 2025)
4. Universität Stuttgart (2022): Kritische Schwachstellen in Log4j (CVE-2021-44228, CVE-2021-4104, CVE-2021-45046 und CVE-2021-45105). URL: https://cert.uni-stuttgart.de/blog/2021-12-13-log4j (abgerufen am 25. Februar 2025)
5. CycloneDX (o. J.): CycloneDX SBOM Specification 1.6. URL: https://cyclonedx.org/docs/1.6/json/ (abgerufen am 25. Februar 2025)
6. International Organization for Standardization (ISO) (2021): ISO/IEC 5230:2021 – Software Package Data Exchange (SPDX). URL: https://www.iso.org/standard/81870.html (abgerufen am 25. Februar 2025)
7. Software Package Data Exchange (SPDX) (o. J.): SPDX Specification v3.0.1. URL: https://spdx.github.io/spdx-spec/v3.0.1/ (abgerufen am 25. Februar 2025)
8. OneKey (2025): OT & IoT Cybersecurity Report 2024. URL: https://www.onekey.com/resource/ot-iot-cybersecurity-report-2024 (abgerufen am 26. Februar 2025)
9. Anchore (2024): Syft Documentation. URL: https://github.com/anchore/syft/wiki (abgerufen am 26. Februar 2025)
10. Microsoft (o. J.): SBOM Tool. URL: https://github.com/microsoft/sbom-tool (abgerufen am 26. Februar 2025)
11. Aqua Security (o. J.): Trivy – Vulnerability Scanner. URL: https://trivy.dev/latest/docs (abgerufen am 26. Februar 2025)
12. CycloneDX (o. J.): CDXGen – CycloneDX Generator. URL: https://cyclonedx.github.io/cdxgen/#/ (abgerufen am 26. Februar 2025)
13. OWASP Dependency-Track (o. J.): Dependency-Track Platform. URL: https://dependencytrack.org/ (abgerufen am 26. Februar 2025)