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

Anmerkung: Dieser Blogpost wurde während dem Sommersemester 2025 für das Modul Enterprise IT (113601a) verfasst.

„I cant fix what I cant see“
Ohne Kenntnisse über die benutzten Komponenten und Libraries agieren Softwareentwickler wie im Blindflug bezüglich ihrer Software-Sicherheit. Bekannte Supply Chain Angriffe wie SolarWinds oder die Log4shell Lücke haben genau dies gezeigt. Wie verheerend fehlende Transparenz der Abhängigkeiten in Softwareprojekten sein können und wie sie Millionen Nutzer beeinflussen. Große Unternehmen benötigen Wochen und Monate, um die betroffenen Komponenten zu identifizieren. Oftmals durch fehlender Software Bill of Materials. [1] [2] [3]

1. Einleitung

Cyberangriffe auf Softwarelieferketten nehmen zu. Damit auch der Druck auf Unternehmen, sich wirksam dagegen zu schützen. [4] Ein zentraler Baustein dabei ist die Software Bill of Materials (SBOM). Sie sorgt für mehr Nachvollziehbarkeit, stärkt die Sicherheit und ist in einigen Bereichen bereits gesetzlich vorgeschrieben, etwa durch die US-amerikanische Executive Order 14028. [5] Oder in der EU durch die „Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products Part 2: Software Bill of Materials (SBOM)“. [6]

Doch wie weit ist die Praxis tatsächlich? Welche Tools unterstützen die automatische Erstellung von SBOMs? Und welche Herausforderungen gilt es zu bewältigen? Der folgende Beitrag gibt einen Überblick über den aktuellen Stand.

2. Was ist ein SBOM?

Ein Software Bill of Materials (SBOM) ist eine Liste, die alle Komponenten und Abhängigkeiten einer Software detailliert aufzeigt. Ähnlich wie eine Stückliste in der industriellen Fertigung oder eine Zutatenliste, dokumentiert ein SBOM, welche Open-Source-Bibliotheken, Frameworks und proprietären Module in einem Softwareprodukt enthalten sind. [11]

Ziel ist es, vollständige Transparenz über die Bausteine einer Software zu schaffen, inklusive Versionsangaben, Lizenzinformationen und Bezugsquellen. Dadurch lassen sich Risiken wie Sicherheitslücken aber auch Lizenzverstöße schneller erkennen und gezielt beheben.

Am weitesten verbreitet sind derzeit die Formate SPDX (entwickelt von der Linux Foundation) und CycloneDX (von OWASP). Beide definieren strukturierte Standards zur Beschreibung und Weitergabe dieser Informationen und ermöglichen eine effiziente Verarbeitung durch automatisierte Tools. [12] [13] [14]

3. Fallbeispiel SolarWinds

Der SolarWinds-Hack (2020) war einer der schwerwiegendsten Supply-Chain-Angriffe der Geschichte. Dabei kompromittierten Hacker die Software-Update-Funktion von SolarWinds Orion, einer weit verbreiteten IT-Überwachungssoftware. Diese Malware Infizierung betraf die US-Regierung und ihre Behörden. Aber auch Unternehmen wie Microsoft oder FireEye. [7] [8]

3.1 Ablauf

1. Infiltration der Build-Umgebung (2019–2020):
   • Angreifer drangen in die Netzwerke von SolarWinds ein und infiltrierten die Software-Entwicklungspipeline.
   • Sie fügten bösartigen Code in die Orion-Software ein (SUNBURST-Backdoor).
2. Verteilung des kompromittierten Updates (März–Juni 2020):
   • SolarWinds verteilte automatisch ein scheinbar legitimes Update (Orion Plattform Version 2019.4–2020.2.1).
   • Über 18.000 Unternehmen luden das Update herunter, darunter US-Behörden (u. a. Finanzministerium, Heimatschutzministerium) und große Tech-Firmen wie Microsoft.
3. Aktivierung der Malware (SUNBURST):
   • Die Backdoor wartete bis zu zwei Wochen, bevor sie Kontakt mit den C2-Servern (Command-and-Control) der Angreifer aufnahm.
   • Die Malware tarnte sich als legitimer Orion-API-Traffic, um Entdeckung zu vermeiden.
4. Lateral Movement & Datenexfiltration:
   • Die Angreifer nutzten die Backdoor, um sich in den Netzwerken der Opfer weiter auszubreiten.
   • Sie stahlen sensible Daten, darunter E-Mails von US-Regierungsbehörden. [9]

3.2 Mögliche Verhinderung durch SBOM

1. Transparenz über Komponenten:
   • Eine SBOM hätte gezeigt, welche Bibliotheken und Abhängigkeiten in der Orion-Software enthalten waren.
   • Ungewöhnliche Änderungen (wie die SUNBURST-Backdoor) wären möglicherweise früher aufgefallen.
2. Automatisierte Schwachstellenscans:
   • Tools wie Dependency-Track hätten verdächtige Codeänderungen in der Build-Pipeline erkennen können.
3. Verifizierung von Software-Updates:
   • Unternehmen hätten die SBOM von SolarWinds mit früheren Versionen vergleichen können, um unerwartete Modifikationen zu identifizieren [10]

4. Relevanz für Unternehmen

SBOMs bieten Unternehmen mehrere Vorteile:

• Schwachstellenmanagement: Bei Vorfällen wie Log4Shell oder SolaWinds kann schnell überprüft werden, ob verwundbare Komponenten betroffen sind.
• Lizenzkonformität: Open-Source-Nutzung lässt sich gezielt überwachen und prüfen.
• Transparenz und Vertrauen: Kunden und Partner erhalten Einblick in die Herkunft von Software.
• Compliance: Vorgaben wie die US Executive Order 14028 verlangen SBOMs bei öffentlichen Aufträgen. [15]

Laut einer empirischen Studie von Xia et al. (2023) sehen 90 % der Praktiker Transparenz als größten Vorteil von SBOMs. Gleichzeitig gaben 87 % an, dass die Vorteile die Einführungskosten überwiegen. [16]

5. Vergleich SBOM-Tools

6. Herausforderung und Zukunftsfragen

Trotz wachsender Aufmerksamkeit für SBOMs und zahlreicher technologischer Fortschritte bestehen in der Praxis nach wie vor erhebliche Hürden, die ihre flächendeckende Einführung behindern:

• Begrenzte Verbreitung in der Praxis: Viele Unternehmen generieren SBOMs nur punktuell oder projektbezogen. Eine durchgehende Abdeckung über alle Systeme und Versionen hinweg ist selten anzutreffen. Besonders bei älteren Systemen („Legacy Code“) fehlt häufig jegliche Inventarisierung. Laut O’Donoghue et al. (2025) ist die tatsächliche Nutzung von SBOMs trotz technischer Möglichkeiten noch sehr eingeschränkt [21].
• Fehlendes Vertrauen in die SBOM-Integrität: Ohne standardisierte Validierungsmechanismen besteht die Gefahr, dass SBOMs unvollständig, veraltet oder gar manipuliert sind. Die fehlende Signierung und die seltene Nutzung von Mechanismen wie in-toto oder cosign verstärken dieses Risiko. Ozkan et al. (2024) zeigen, dass viele Tools keine Integritätsprüfung enthalten, was ein Sicherheits- und Vertrauensproblem darstellt [22].
• Sensibilität proprietärer Komponenten: Unternehmen zögern, SBOMs für intern entwickelte oder vertrauliche Software offenzulegen. Grund dafür ist die Sorge vor Know-how-Abfluss, rechtlichen Risiken oder Angriffspotenzial durch öffentlich einsehbare Abhängigkeitslisten. Kloeg et al. (2024) identifizieren diese Datenschutzbedenken als eine zentrale Barriere für die breite Akzeptanz der SBOMs[23].
• Unzureichende Konsumierbarkeit der Daten: Während SBOMs mittlerweile relativ einfach generiert werden können, mangelt es oft an Analyse-, Visualisierungs- oder Governance-Tools. Die Frage „Was mache ich mit der SBOM?“ bleibt oftmals unbeantwortet. Damit bleibt auch ihr Mehrwert ungenutzt. O’Donoghue et al. (2025) betonen, dass vor allem der Mangel an Auswertungs- und Integrationsmöglichkeiten den wirtschaftlichen Nutzen limitiert [21].

Diese strukturellen Barrieren zeigen: SBOMs sind technisch möglich, aber organisatorisch noch nicht ausreichend in Unternehmen verankert.

7. Fazit

SBOMs sind längst kein Zukunftsthema mehr, sondern ein zentraler Baustein für Transparenz, Sicherheit und regulatorische Konformität in der modernen Softwareentwicklung. Sie ermöglichen Unternehmen, Risiken frühzeitig zu erkennen, auf Sicherheitsvorfälle gezielter zu reagieren und ihre Lieferketten nachvollziehbar zu gestalten [24].

Doch die Vision einer flächendeckend „SBOM-fähigen“ IT-Landschaft ist noch nicht Realität. Damit SBOMs ihren vollen Nutzen entfalten, braucht es:

• einheitliche Standards (z. B. SPDX, CycloneDX),
• Tools, die sowohl Generierung als auch Auswertung abdecken,
• Automatisierung entlang der DevSecOps-Pipeline,
• sowie eine organisatorische Verankerung bei Entwicklern und Führungskräften [21][24].

Werkzeuge wie Syft, Trivy oder Dependency-Track leisten bieten eine wichtige Grundlage. Doch ohne Schulungen, klare Regeln im Unternehmen und gemeinsame Vorgehensweisen in der Softwarebranche wird ihr Nutzen kaum ausgeschöpft. Der Weg zur „SBOM-Reife“ erfordert deshalb nicht nur technische Lösungen, sondern auch ein neues Verständnis für Software-Transparenz als unternehmensstrategische Aufgabe [23][25].

8. Quellenverzeichnis

[1] IBM. (2022). SolarWinds Orion CVE-2020-10148. IBM Documentation.
https://www.ibm.com/docs/en/randori?topic=2022-solarwinds-orion-cve-2020-10148

[2] NIST. (2020). CVE-2020-10148 Detail. National Vulnerability Database.
https://nvd.nist.gov/vuln/detail/CVE-2020-10148

[3] NIST. (2021). CVE-2021-44228 Detail. National Vulnerability Database.
https://nvd.nist.gov/vuln/detail/CVE-2021-44228

[4] Sonatype. (2024). State of the Software Supply Chain: A 10-Year Look.
https://www.sonatype.com/state-of-the-software-supply-chain/2024/10-year-look

[5] NIST. (2021). Software Supply Chain Security Guidance (Executive Order 14028).
https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance

[6] BSI. (2023). TR-03183: Technische Richtlinie für Software Supply Chain Security.
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html

[7] CISA. (2020). Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (AA20-352A).
https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a

[8] SolarWinds. (2020). Security Advisory: Orion Platform Vulnerabilities.
https://www.solarwinds.com/sa-overview/securityadvisory

[9] Microsoft. (2020). Analyzing Solorigate: The Compromised DLL File That Started a Sophisticated Cyberattack.
https://www.microsoft.com/en-us/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

[10] Google Cloud. (2020). Evasive Attacker Leverages SolarWinds Supply Chain Compromises with Sunburst Backdoor.
https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor

[11] NTIA. (2021). Software Bill of Materials: A Catalyst to a More Secure Software Supply Chain.
https://www.ntia.gov/page/software-bill-materials

[12] SPDX. (2023). SPDX Overview.
https://spdx.dev/about/overview/

[13] CycloneDX. (2024). Official Website.
https://cyclonedx.org/

[14] NTIA. (2021). Software Bill of Materials (SBOM) Resources.
https://www.ntia.gov/page/software-bill-materials

[15] TechTarget. (2023). The Benefits and Challenges of SBOMs.
https://www.techtarget.com/searchsecurity/post/The-benefits-and-challenges-of-SBOMs

[16] Zhang, M. et al. (2023). An Empirical Study on Software Bill of Materials: Where We Stand and the Road Ahead. arXiv.
https://arxiv.org/abs/2301.05362

[17] Anchore Syft. (2024). GitHub Repository.
https://github.com/lloydchang/anchore-syft

[18] Trivy. (2024). Documentation.
https://trivy.dev/latest/docs/

[19] CycloneDX CLI. (2024). GitHub Repository.
https://github.com/CycloneDX/cyclonedx-cli

[20] Dependency-Track. (2024). Official Documentation.
https://docs.dependencytrack.org/

[21] O’Donoghue, E. et al. (2025). Software Bill of Materials in Software Supply Chain Security: A Systematic Literature Review. arXiv.
https://arxiv.org/abs/2506.03507

[22] Ozkan, B. et al. (2024). Integrity Gaps in SBOM Generation and Consumption Tools. arXiv.
https://arxiv.org/abs/2412.05138

[23] Kloeg, R. et al. (2024). Charting the Path to SBOM Adoption. TU Delft.
https://zhauniarovich.com/publication/2024/kloeg2024charting/

[24] McKinsey & Company. (2024). SBOMs as a Cybersecurity Imperative.
https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/software-bill-of-materials-managing-software-cybersecurity-risks

[25] Interlynk / TU Delft. (2024). Top 5 Challenges to SBOM Adoption. Medium.
https://medium.com/@interlynkblog/top-5-challenges-to-sbom-adoption-0c942113e3ea