Transparenz und Sicherheit durch automatisierte Software-Stücklisten

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

1. Einleitung

Moderne Software besteht längst nicht mehr nur aus eigenem Quellcode. In nahezu jedem Projekt werden große Mengen externer Bibliotheken, Frameworks und Open-Source-Komponenten genutzt. Wie auch bei physischen Lieferketten sind jedoch auch die einzelnen Komponenten von Software-Produkten sowohl für Unternehmen als auch deren Kunden nicht immer klar ersichtlich.

Je nach Projekt kommen schnell Hunderte von Abhängigkeiten zusammen, viele davon mit weiteren, indirekten Abhängigkeiten, die sich über verschiedene Versionen, Quellen und Lizenzmodelle erstrecken. Diese komplexe Struktur macht es schwierig den Überblick zu behalten und erschwert es, Sicherheitslücken, Schwachstellen oder Lizenzkonflikte rechtzeitig zu erkennen. Gleichzeitig steigt der Druck auf Unternehmen für mehr Transparenz in ihren Software-Lieferketten zu sorgen, um potenzielle Risiken besser einschätzen und minimieren zu können.

Die Notwendigkeit, die Herkunft, Vertrauenswürdigkeit und Aktualität aller eingesetzten Komponenten nachvollziehbar zu dokumentieren, rückt deshalb zunehmend in den Mittelpunkt moderner Softwareentwicklung sowohl im Hinblick auf Sicherheit als auch auf Qualität und Compliance.

2. Was sind SBOMs

An dieser Stelle setzt das Konzept der Software Bill of Materials (SBOM) an: Eine strukturierte Liste sämtlicher Bestandteile einer Software, welche mit einer Stückliste in der industriellen Fertigung vergleichbar ist [1]. SBOMs helfen Unternehmen somit, die Software-Lieferkette ihrer Produkte besser zu kontrollieren, um Sicherheitsrisiken rechtzeitig zu erkennen und Lizenzverpflichtungen einzuhalten.

Eine SBOM listet dabei nicht nur die direkt verwendeten Bibliotheken oder Frameworks auf, sondern schließt auch deren indirekte Abhängigkeiten ein also alle Komponenten, von denen ein Projekt auf irgendeine Weise abhängt. Die Informationen innerhalb einer SBOM umfassen typischerweise Name, Version, Herkunft (z. B. Registry oder Git-Repository), Lizenztyp sowie häufig auch Hashwerte zur Integritätsprüfung. Je nach Format und Standard etwa SPDX (Software Package Data Exchange), CycloneDX oder SWID (Software Identification Tags) können SBOMs noch zusätzliche technische und rechtliche Informationen enthalten.

Der große Vorteil einer SBOM liegt in der verbesserten Nachvollziehbarkeit: Unternehmen und Organisationen wissen zu jedem Zeitpunkt, welche externen Komponenten in einem Produkt enthalten sind. Im Falle einer neu entdeckten Schwachstelle, beispielsweise in einer weit verbreiteten Bibliothek, kann dadurch schnell identifiziert werden, ob und wo genau betroffene Versionen verwendet werden. So lassen sich Sicherheitslücken schneller schließen, Risiken minimieren und Reaktionszeiten deutlich verkürzen.

Darüber hinaus leisten SBOMs einen wichtigen Beitrag zur Lizenz-Compliance. In vielen Projekten werden Open-Source-Komponenten mit unterschiedlichen Lizenzbedingungen kombiniert. Eine vollständige und aktuelle SBOM ermöglicht es, mögliche Konflikte frühzeitig zu erkennen und rechtliche Konsequenzen zu vermeiden, etwa durch die versehentliche Verletzung von Copyleft-Bestimmungen oder fehlende Lizenznennungen.

Nicht zuletzt fördern SBOMs auch die Zusammenarbeit zwischen verschiedenen Akteuren in der Softwareentwicklung. Gerade in größeren Projekten mit mehreren Teams oder externen Dienstleistern sorgt eine zentral gepflegte Software-Stückliste für Transparenz und ein gemeinsames Verständnis über den Aufbau und die Abhängigkeiten eines Produkts.

2.1 Welche Informationen sind darin enthalten?

SBOMs enthalten dabei Informationen über:

• Namen und Versionen verwendeter Bibliotheken
• Typ (z.B. library, container, file, …)
• Herkunft (Quelle/Hersteller)
• Hash / Checksumme
• Package URL
• Lizenzinformationen
• Beziehungen und Abhängigkeiten zwischen Komponenten

2.2 Welchen Nutzen haben SBOMs?

Eine Software Bill of Materials kann Software-Entwicklern helfen:

• Ungeplante und unvorhergesehene Arbeiten zu reduzieren
• Code-Bloat (Übermäßige Codegröße durch unnötige Abhängigkeiten) zu verringern
• Abhängigkeiten in komplexen Projekten besser zu verstehen
• Lizenzverpflichtungen zu kennen und einzuhalten
• Komponenten auf Sicherheitslücken zu überprüfen
• Komponenten mit abgelaufenem Support (End of Life) zu identifizieren
• Codequalität zu verbessern und Code-Reviews zu erleichtern
• Unzulässige oder verbotene Komponenten durch Blacklists auszuschließen
• Notwendige Informationen an Kunden oder Partner weiterzugeben

2.3 Wie SBOMs aufgebaut sind

Derzeit werden hauptsächlich zwei SBOM-Formate genutzt – Software Package Data Exchange (SPDX) und CycloneDX [2]
. Bei beiden Formaten handelt es sich um maschinenlesbare Open-Source-Formate, welche sich jedoch in ihrer Zielsetzung, Struktur und dem bevorzugten Einsatzbereich unterscheiden [3]
. Ihre Gemeinsamkeiten und Unterschiede sind in folgender Tabelle zusammengefasst:

2.4 SPDX vs. CycloneDX – Unterschiede im Überblick

Neben SDPX und CycloneDX wurden auch noch sogenannte Software identification (SWID) tags entwickelt, die als Teil eines ISO-Standards Software-Komponenten mithilfe von Metadaten identifizierbar machen sollen. Die Nutzung dieser SWIDs hat sich jedoch nicht weitgehend durchgesetzt. Die Nutzbarkeit dieser SWIDs kann jedoch bei Vergleichen verschiedener SBOM-Tools erwähnt werden [4].

3. Warum automatische SBOM-Tools wichtig sind

Während manche SBOMs für die Öffentlichkeit zugänglich sind, können auch Zugangsbeschränkungen vorliegen, bei denen nur bestimmte Stakeholder

Da die stetig steigende Komplexität moderner Software die manuelle Erstellung solcher Stücklisten unrealistisch macht, gewinnen Tools zur automatischen Erstellung von SBOMs mehr und mehr an Bedeutung.

3.1 Vorteile automatischer SBOM-Tools:

• Effizienz: Automatisierte Analysen sparen Zeit und Aufwand
• Aktualität: Tools können bei jedem Build oder Release automatisch eine aktuelle SBOM erzeugen
• Konsistenz: Manuell gepflegte SBOMs werden oft veraltet oder unvollständig
• Fehlervermeidung: Tools erkennen alle relevanten Abhängigkeiten systematisch (auch transitive Dependencies)
• Integration in DevOps / CI/CD: Tools lassen sich direkt in Build-Prozesse einbinden. Manuelle Erstellung ist nicht skalierbar für Continuous Delivery.
• Bessere Sicherheitsüberwachung: Tools können SBOMs direkt mit Schwachstellen-Datenbanken (CVEs) abgleichen
• Skalierbarkeit: Automatische Lösungen funktionieren auch für große Projekte mit tausenden Abhängigkeiten.

3.2 Welche SBOM-Tools gibt es?

Da die beiden SBOM-Formate SPDX und CycloneDX open-source-Formate sind große Mengen verschiedener SBOM-Tools auf dem Markt erhältlich. Diese Tools unterscheiden sich unter anderem in ihrem bevorzugten Einsatzgebiet, unterstützten Formaten oder in ihren angebotenen Funktionen.

Abbildung 1: Vergleich von Funktionalitäten verschiedener SBOM-Tools [5]

3.3 Fallbeispiel: OpenSSF SBOM Test

Wie SBOMs durch weitere Sicherheitsmaßnahmen ergänzt werden können, zeigt ein Praxistest von OpenSSF.

Hierbei wurde untersucht, inwieweit Scorecards im Zusammenspiel mit SBOMs eine genauere Analyse der Vertrauenswürdigkeit von Open-Source Software erlaub [5]t. Im Rahmen dieser Analyse wurde für die beiden Open-Source Projekte Kibana und Antrea jeweils eine SBOM angelegt und deren Sicherheits-Aspekte anhand einer Scorecard evaluiert.

Eine Regel, welche zur Bewertung dieser Scorecards genutzt wird, ist die Binary Artifacts Rule. Hierbei werden Projekte auf die Nutzung von Binären Artefakten untersucht, welche aufgrund ihrer Intransparenz als unsicher eingestuft werden. Eine Punktzahl von Zehn wird dabei bei Projekten vergeben, welche keine Binären Artefakte enthalten, während bei Zehn oder mehr Artefakten eine Punktzahl von Null vergeben wird.

Gefundene Abhängigkeiten, die den Binary Artifacts Test nicht bestanden haben, können weitergehend untersucht und bewertet werden, um mögliche Sicherheitsrisiken zu finden.

Dieser Proof-of-Concept zeigt laut OpenSSF das Potenzial kombinierter Nutzung von SBOMs mit Scorecard-Daten zur Bewertung von Sicherheitsrisiken.

4. Zukunftsausblick

Mit zunehmender Verlagerung von Softwareentwicklungs-Prozessen in die Cloud und wachsendem Einsatz von Open-Source-Komponenten wird die Transparenz in Hinblick auf eingesetzte Software-Bestandteile verpflichtend. Die Bedeutung von Software Bill of Materials wird sich daher in den kommenden Jahren weiter verstärken.

4.1 Regulatorische Entwicklungen

Behörden weltweit machen SBOMs zur verbindlichen Anforderung für Software:

• In den USA wurde SBOMs mit der Executive Order 14028 (2021) zur Software Supply Chain Security zum gesetzlichen Standard für staatlich bezogene Softwareprojekte erklärt [6]. Weiter wurden Mindestanforderungen an SBOMs definiert.
• Auch in der EU treten strengere Auflagen für Produkte mit Software-Komponenten in Kraft, welche bessere Cyber-Security über den gesamten Lebenszyklus von Produkten garantieren sollen [7].

4.2 Automatisierung statt manueller Pflege

Die stetig steigende Komplexität von Softwareprojekten macht eine manuelle Erstellung von SBOMs inklusive Abhängigkeitslisten nahezu unmöglich. Tools wie Syft, Trivy, Tern oder ORT werden sich vermutlich nicht nur als Best Practice, sondern als zwingende Voraussetzung zur Einhaltung von Compliance und Cyber-Security-Auflagen durchsetzen.

4.3 Integrierung in den Software-Lifecycle

Unternehmen werden SBOMs nicht separat durch Drittanbieter erstellen lassen müssen, sondern die nötigen Tools werden in Plattformen wie GitHub, GitLab oder Azure DevOps integriert sein. Bereits heute fördern Unternehmen wie GitHub, Google oder Amazon aktiv SBOM-Initiativen und entwickeln neue APIs und Standards.

4.4 AI Bill of Materials

Durch die stark zunehmende Nutzung von künstlicher Intelligenz (KI) in der Software- Entwicklung rückt auch die Nutzung von AI Bill of Materials (AI-BOM) in den Vordergrund [9]
. Als Ergänzung zu SBOMs werden in ihnen Datensätze, Modelle, Software, Hardware und Abhängigkeiten über den gesamten Lifecycle von KI-Systemen dokumentiert.  Auch durch die breite Nutzung von KI in nicht-produzierenden Bereichen von Unternehmen werden AI-BOMs in Zukunft mehr und mehr an Bedeutung gewinnen.

“It won’t be long until SBOMs become table stakes for anyone operating an online business” – Josh Bressers, Anchore (2025) [9]

Literaturverzeichnis

Literaturverzeichnis [1] National Telecommunications and Information Administration, „Software Bill of Materials,“ o.D.. [Online]. Available: https://www.ntia.gov/page/software-bill-materials. [Zugriff am 20 Juli 2025].

[2] Scribe Security, „SBOM Example: a Sample of SBOM File Explained,“ Dezember 2023. [Online]. Available: https://scribesecurity.com/sbom/sample-sbom/#sbom-samples. [Zugriff am 22 Juli 2025].

[3] Scribe Security, „SPDX vs. CycloneDX: SBOM Formats Compared,“ Februar 2023. [Online]. Available: https://scribesecurity.com/blog/spdx-vs-cyclonedx-sbom-formats-compared/. [Zugriff am 23 Juli 2025].

[4] J. Walker, „Generating SBOM,“ Earthly, 29 Dezember 2023. [Online]. Available: https://earthly.dev/blog/generating-sbom/. [Zugriff am 23 Juli 2025].

[5] OpenSSF, „Assessing Product Risk Using SBOMs and OpenSSF Scorecard,“ OpenSSF, 14 April 2023. [Online]. Available: https://openssf.org/blog/2023/04/14/assessing-product-risk-using-sboms-and-openssf-scorecard/. [Zugriff am 23 Juli 2025].

[6] PWC, „US Executive Order 14028: Open Source users,“ 13 September 2021. [Online]. Available: https://www.pwc.de/en/digitale-transformation/open-source-software-management-and-compliance/us-executive-order-14028-what-it-means-for-open-source-users.html. [Zugriff am 23 Juli 2025].

[7] European Commission, „Cyber Resilience Act,“ 6 März 2025. [Online]. Available: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act. [Zugriff am 23 Juli 2025].