goSecurity BLOG

1. Einleitung

Transparenz spielt in der modernen Softwareentwicklung eine zentrale Rolle. Anwendungen bestehen heute aus Hunderten von Komponenten, Bibliotheken und Frameworks, die oft aus offenen Quellen stammen oder von Drittanbietern geliefert werden. Ohne genaue Kenntnisse darüber, welche Bausteine im Einsatz sind, kann bereits eine kleine Schwachstelle in einer externen Bibliothek enorme Sicherheitsrisiken verursachen [1] [2].

Supply-Chain-Attacken wie bei SolarWinds im Jahr 2020 oder die Log4J-Schwachstelle im Jahr 2021 haben eindrücklich gezeigt, wie gefährlich es sein kann, die eigene Software-Lieferkette nicht vollständig im Blick zu haben [3] [4]. Die Unternehmen sahen sich plötzlich mit der Herausforderung konfrontiert, eine grosse Anzahl an Software-Komponenten zu prüfen – oft ohne genaue Kenntnis darüber, welche Versionen verwendet wurden oder ob diese von den Problemen betroffen waren.

Genau hier setzt die Software Bill of Materials (SBOM) an. Sie ist im Prinzip eine transparente Inventarliste aller verwendeten Software-Komponenten inklusive Versionen, Lizenzen und Prüfsummen [5], die Aufschluss darüber gibt, welche Komponenten eingesetzt werden. Die Erstellung einer SBOM ermöglicht eine schnellere Identifizierung von Risiken, die Erfüllung von Compliance-Anforderungen und ein proaktives Management von Sicherheitsvorfällen. Damit werden zugleich auch die Anforderungen des EU Cyber Resilience Act (CRA) erfüllt, im Hinblick auf die Transparenz und Nachvollziehbarkeit von Software-Komponenten sowie die Sicherheitsnachweise. Für die Erfüllung der CRA-Anforderungen werden fünf Kategorien benötigt: Sicherheitsanforderungen über den gesamten Lebenszyklus (SDLC), Vulnerability Management (Schwachstellenmanagement), die Pflicht zur Bereitstellung von Sicherheitsupdates, Dokumentations- und Transparenzpflichten (SBOM) sowie Meldepflichten bei Sicherheitsvorfällen (ENISA).

Der CRA schreibt das Erstellen einer SBOM vor. Diese muss jedoch nicht veröffentlicht werden. Zudem wird verlangt, dass die SBOM aktuell ist, versioniert wird und bis zu zehn Jahre lang aufbewahrt wird. Weiter muss Folgendes abgedeckt sein:

• Maschinenlesbares Format: CycloneDX oder SPDX (nur JSON oder XML, kein YAML)

• Abdeckung transitiver Abhängigkeiten, nicht nur direkter Abhängigkeiten

• Rekursive Abhängigkeitsauflösung für jede Komponente im Lieferumfang

Ein konkretes Format gibt die CRA für die SBOM nicht vor, doch das BSI hat hierzu die technische Richtlinie BSI TR-03183–2 (v2.1.0, August 2025) veröffentlicht und ist derzeit die detaillierteste öffentliche Auslegung der CRA-SBOM-Anforderungen in der EU.

Der CRA ist seit dem 11. Dezember 2024 in Kraft. Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle verpflichtend gemeldet werden. Ab dem 11. Dezember 2027 wird der CRA in vollem Umfang verbindlich sein und sämtliche bestehenden sowie neuen Produkte (bspw. wie IoT oder Software) müssen die umfassenden Cybersicherheitsanforderungen erfüllen.

2. Was ist eine SBOM?

Eine Software Bill of Materials (SBOM) ist vergleichbar mit einer Stückliste in der Fertigung – nur eben für Software [6]. Sie listet alle Bestandteile einer Software, wie beispielsweise Bibliotheken, Frameworks und Module, sowie deren Versionen auf. Zusätzlich enthält sie oft Informationen über Lizenzen, Prüfsummen und Abhängigkeiten, sodass man genau nachvollziehen kann, aus welchen Komponenten eine Software besteht und wo mögliche Risiken liegen.

Man kann sich eine SBOM wie ein Inhaltsverzeichnis oder eine Inventarliste vorstellen. Sie beantwortet zentrale Fragen:

• Welche Komponenten werden in meiner Software genutzt?

• Welche Versionen sind im Einsatz?

• Wo liegen potenzielle Sicherheits- oder Lizenzrisiken?

Softwarehersteller, Betreiber und Auditoren profitieren in vielerlei Hinsicht von der Nutzung von SBOMs [7]. Während Hersteller die SBOMs nutzen, um Transparenz über ihre Software zu schaffen, hilft sie Betreibern bei der Einschätzung von Sicherheits- und Compliance-Risiken und erleichtert Auditoren die Prüfung der Einhaltung regulatorischer Anforderungen.

Für SBOMs gibt es verschiedene Formate. Diese unterscheiden sich in ihrer Struktur und ihrem Detaillierungsgrad. Sie stellen die zentrale Information über die Zusammensetzung einer Software auf standardisierte Weise bereit, was ein entscheidender Schritt ist, um die Software-Lieferkette sicherer und nachvollziehbarer zu machen.

Drei der bekanntesten sind SPDX (ISO Standard ISO/IEC 5962:2021) [6], CycloneDX (OWASP) [5] und SWID (Software Identification ISO/IEC 19770-2:2015) [8]:

SPDX	CycloneDX (Format: JSON und XML)	SWID
Die von der Linux Foundation eingeführten SPDX-Formate werden verwendet, um Anwendungen zu scannen und zu überprüfen, ob das Unternehmen über die erforderlichen Lizenzen zur Ausführung dieser Anwendungen verfügt. Lizenzverletzungen können für Unternehmen, die Anwendungen nutzen, ohne zu wissen, ob diese für kommerzielle Zwecke verwendet werden dürfen, schwerwiegende Folgen haben. Einige Anwendungen können von Privatpersonen kostenlos genutzt werden, bei kommerzieller Nutzung fallen jedoch Kosten an. Da verschiedene Softwarelizenzstrukturen existieren, wird es für Unternehmen zunehmend schwieriger, sicherzustellen, dass sie die Vorschriften ordnungsgemäss einhalten. Eine SBOM ermittelt die installierten Anwendungen und hilft Unternehmen festzustellen, ob diese mit der Lizenzierung kompatibel sind. Die Linux Foundation verfügt über ein Git-Repository mit Open-Source-Tools zur SPDX-Generierung. [9]	Das CycloneDX-Format dient in erster Linie der Dokumentation der Cybersicherheit der Software. Da es sich um einen flexiblen Standard handelt, kann der Ersteller des Dokuments ein benutzerdefiniertes Format generieren, das optimal auf die Kunden zugeschnitten ist. OWASP bietet ein Open-Source-Tool zur Erstellung von SBOMs in mehreren Sprachen an. Die Hauptausgabe des Generierungstools erfolgt in den Formaten JSON und XML. Entwickler können diese Ausgabe nutzen, um ein eigenes Dokumentationsformat zu erstellen. Die Dokumentation muss jedoch alle erforderlichen Datenfelder enthalten, damit sie als konforme SBOM gilt. Da das Generierungstool für Entwickler konzipiert wurde, ist es für Nutzer ohne Entwicklungserfahrung nur schwer bedienbar. [9]     .	Das SWID-Format wurde im Jahr 2009 erstellt. 2015 wurde es aktualisiert. In der Regel wird es in Entwicklungsumgebungen verwendet. Damit kann überprüft werden, ob Software keine unbefugten Änderungen enthält. Ausserdem kann es dazu verwendet werden, die Installation unbefugter Software zu verhindern, indem es Änderungen an installierter Software erkennt. Schliesslich kann es Schwachstellen in Software identifizieren, die gepatcht werden müssen. In grossen Unternehmen, in denen mehrere Entwickler in einer vertrauenswürdigen Umgebung zusammenarbeiten, werden SBOMs in diesem Format in den Softwareentwicklungslebenszyklus integriert. Das NIST hat die Richtlinien NISTIR 8060 (Guidelines for the Creation of Interoperable Software Identification (SWID) Tags) eingeführt. Damit soll das Format für Sicherheitsanwendungsfälle nutzbar gemacht und die Verantwortlichkeit während des gesamten Entwicklungsprozesses aufgezeigt werden. [9]
Quelle: Overview – SPDX .	Quelle: Security Use Cases and Examples | CycloneDX	Quelle: NTIA .

3. Woraus besteht eine SBOM?

Typische Bestandteile einer SBOM sind:

• Komponenteninformationen (Name, Version, Typ)

• Abhängigkeiten zu anderen Modulen

• Lizenz Informationen (z. B. MIT, Apache 2.0, etc.)

• Prüfsummen & Signaturen (Hash-Werte wie z.B. SHA-256, um die Integrität der Komponenten zu prüfen)

• Optionale Merkmale (Hersteller, Veröffentlichungsdatum oder Build-Datum, Quellen-Repository oder Download-URL)

Mithilfe dieser Informationen können Risiken identifiziert, Updates geplant und die Compliance geprüft werden – und das alles automatisiert, wenn die SBOM in die Build- und Release-Prozesse integriert wird. [5] [6] [8]

Beispiel einer SBOM (Format: JSON) [13]

4. Wie entsteht eine SBOM? – Methoden und Tools

Die Erstellung einer SBOM kann auf unterschiedliche Arten erfolgen – von der manuellen [5] Erstellung bis hin zur vollständigen Automatisierung. Je nach Projektgrösse, Teamstruktur und eingesetzter Technologie eignen sich unterschiedliche Ansätze.

Da sich Abhängigkeiten ändern, sollten SBOMs regelmässig aktualisiert werden. Idealerweise sind sie automatisiert in den CI/CD-Prozess [5] [14] integriert, um menschliche Fehler zu minimieren. Für kritische Software können SBOMs zusätzlich signiert werden, um Manipulationen zu erkennen.

Die folgende Tabelle gibt einen Überblick über die verschiedenen Tools und ihren Einsatzbereich.

5. Wie setzt man SBOMs praktisch um?

5.1. Integration in den Entwicklungsprozess

Die Erstellung von SBOMs sollte bei jedem Build automatisch erfolgen. Dafür können die Prozesse genutzt werden, die bereits für die CI/CD-Pipelines verwendet werden. Tools wie Syft oder CycloneDX-CLI [14] lassen sich direkt in Jenkins, GitHub Actions oder GitLab CI integrieren, wodurch die Arbeit deutlich erleichtert wird.

Zur frühzeitigen Erkennung von Risiken ist die Nutzung des „Shift-Left“-Ansatzes [5] [14] empfehlenswert. Dabei werden die SBOMs möglichst früh im Entwicklungszyklus erstellt und nicht erst beim Release. Zudem sollte darauf geachtet werden, dass bei jeder neuen Version einer Bibliothek oder eines Moduls die SBOM automatisch aktualisiert wird.

5.2. Veröffentlichung von SBOMs

Je nach Projekt können SBOMs auf unterschiedliche Weise veröffentlicht werden. Idealerweise wird die SBOM als Teil des Artefakts mit dem Release-Paket ausgeliefert, beispielsweise im Container-Image oder als Begleitdatei. Alternativ können die SBOMs auch in einem Artefakt-Repository (z. B. Artifactory oder Nexus) abgelegt werden, sodass Teams und Auditoren jederzeit darauf zugreifen können.

Eine Veröffentlichung kann bei Open-Source-Projekten auch direkt im Repository erfolgen, beispielsweise auf GitHub.

5.3. Automatisierte Governance

Mithilfe von Policy-Engine-Tools wie dem Dependency-Tracker [15] können SBOMs auf lizenzrechtliche Konflikte oder bekannte Schwachstellen überprüft werden. Wird eine neue Schwachstelle oder eine veraltete Version identifiziert, wird eine Benachrichtigung ausgelöst. Auditoren können SBOMs als Grundlage für Compliance- und Sicherheitsbewertungen nutzen.

In der Praxis sollte darauf geachtet werden, die SBOM stets zu versionieren. So ist nachvollziehbar, welche SBOM zu welchem Software-Release gehört. Das Signieren der SBOM hat, wie bereits erwähnt, den Vorteil, dass Manipulationen erkannt werden können. Ausserdem sollte man die SBOM als laufendes Dokument betrachten und nicht als einmaligen Report.

Durch diese Massnahmen wird die SBOM zu einem aktiven Werkzeug im Software-Lebenszyklus, das nicht nur dokumentiert, sondern auch Risiken reduziert und die Einhaltung von Vorschriften erleichtert.

6. SBOM allein reicht nicht: VEX & weitere Artefakte

Eine SBOM ist ein hilfreiches Werkzeug, aber sie beantwortet nicht automatisch alle Sicherheitsfragen. In Kombination mit VEX (Vulnerability Exploitability Exchange) liefert die SBOM jedoch konkrete Informationen darüber, welche Schwachstellen für die jeweilige Software tatsächlich relevant sind. [14]

VEX ist ein standardisiertes Format, das beschreibt, ob eine Schwachstelle in einer bestimmten Software-Komponente tatsächlich ausgenutzt werden kann oder nicht. Als Beispiel: Eine Software-Bibliothek enthält theoretisch eine bekannte Schwachstelle, die in der Anwendung jedoch nicht aktiviert oder nicht nutzbar ist. VEX zeigt, ob ein unmittelbares Risiko besteht oder nicht.

Das Zusammenspiel von SBOM und VEX funktioniert wie folgt:

1. Die SBOM listet alle Komponenten der Software auf und zeigt, wo potenzielle Risiken liegen.

2. VEX bewertet diese Risiken und identifiziert die tatsächlich kritischen Schwachstellen.

Gemeinsam ermöglichen sie somit gezielte und effiziente Sicherheitsbewertungen, vermeiden Fehlalarme und reduzieren unnötigen Aufwand. Dadurch ist eine angepasste Risikobewertung möglich. Sicherheitsmassnahmen lassen sich effizienter priorisieren. Schwachstellen in der Lieferkette können schneller identifiziert und behoben werden.

Mit dieser Kombination wird die SBOM nicht nur zu einer statischen Inventarliste, sondern zu einem aktiven Werkzeug für Sicherheits- und Risikomanagement in modernen Softwareprojekten.

7. Herausforderungen & Stolpersteine

In der Praxis gibt es einige Herausforderungen, die es zu kennen gilt, um realistische Erwartungen zu haben und typische Fehler zu vermeiden.

Automatische SBOM-Tools erkennen nicht immer jede Abhängigkeit korrekt. Die Gründe hierfür sind:

• Ungewöhnliche Build-Prozesse

• Dynamisch nachgeladene Komponenten

• Proprietäre Bibliotheken, die nicht standardisiert erkannt werden

Ist dadurch die SBOM unvollständig, entsteht ein falsches Sicherheitsgefühl. Nachfolgend einige häufige Herausforderungen, und wie man ihnen begegnen kann:

Ausserdem sollte festgelegt werden, wer für die SBOM verantwortlich ist. Ist es das Development-Team für die Generierung? Oder das Security-Team für Analyse & Monitoring? Oder vielleicht doch eher die Compliance-Abteilung für Lizenzthemen? Hier verhindern klar definierte Rollen, dass die SBOMs veralten oder falsch gepflegt werden.

Es existiert noch ein weiterer Stolperstein: SBOMs sind wertlos, wenn sie niemand nutzt. Darum sollten sie in das ISMS in den nachfolgend aufgeführten Bereichen eingebunden und durch interne Audits regelmässig überprüft werden:

Auf diese Weise wird die SBOM zu einem aktiven Sicherheitswerkzeug, und nicht nur zu einem Dokument.

8. Zukunft von SBOM

Mehrere Entwicklungen zeigen bereits heute, wohin die Reise geht. Regierungen und Behörden weltweit erkennen die Bedeutung von Transparenz in der Software-Lieferkette. Daher wird die Nachfrage nach SBOMs weiter steigen, wie folgende Anforderungen zeigen.

• Der EU Cyber Resilience Act (CRA) wird SBOMs für viele Produkte de facto verpflichtend machen.

• Die US-Regierung fordert SBOMs bereits für Software im öffentlichen Sektor.

• Weitere Branchen wie Medizin, Energie oder Automotive folgen mit eigenen Standards.

SBOMs werden damit zunehmend zu einem Compliance-Must-have, ähnlich wie Datenschutzrichtlinien und Penetrationstests es heute sind. Mit SBOMs als Datenbasis lassen sich Sicherheitsanalysen in Zukunft stärker automatisieren. Sie werden dann zu einem Data-Feed für Security-Intelligenz statt nur einer Dokumentation.

Mit der wachsenden Relevanz von KI-Modellen werden SBOM-Mechanismen auf KI-Bereiche übertragen. Diese Entwicklung führt zu einem neuen Konzept: der AI Bill of Materials (AI-BOM).

Die Generierung und das Management von SBOMs werden einfacher und dadurch Teil des normalen Entwicklungsworkflows, statt ein Spezialthema für Security-Teams zu sein. Dies ermöglicht einen ganzheitlichen Blick auf Risiken entlang des gesamten Entwicklungsprozesses – von der ersten Abhängigkeit bis zum ausgelieferten Release.

9. Zusammenfassung

Eine SBOM ist mehr als nur eine Inventarliste: Sie ist ein mächtiges Werkzeug, um Sicherheitsrisiken, Compliance-Anforderungen und operative Herausforderungen besser zu bewältigen. Die wichtigsten Gründe, warum SBOMs heute unverzichtbar sind, lassen sich wie folgt zusammenfassen:

Mehr Transparenz über eingesetzte Komponenten: Moderne Software besteht oft aus Hunderten Bibliotheken und Modulen. Eine SBOM zeigt genau, welche Komponenten im Einsatz sind, inklusive Versionen und Abhängigkeiten. Das ist besonders wichtig, wenn Software schnell wächst oder regelmässig aktualisiert wird.

Schnellere Reaktion auf Sicherheitsvorfälle: Wenn eine Schwachstelle wie Log4J oder eine andere kritische Sicherheitslücke entdeckt wird, ermöglicht eine SBOM eine gezielte Prüfung der betroffenen Versionen. Ohne SBOM ist die Analyse zeitaufwendig und fehleranfällig – im schlimmsten Fall können Sicherheitslücken Wochen oder Monate unentdeckt bleiben.

Unterstützung bei Lizenz-Compliance: SBOMs helfen dabei, die rechtlichen Anforderungen für Open-Source-Software einzuhalten. Sie zeigen, welche Lizenzen für welche Komponenten gelten, sodass Lizenzverstösse frühzeitig erkannt und vermieden werden können.

Grundlage für Risikoanalysen und Governance: Mit einer SBOM lassen sich Risiken entlang der Software-Lieferkette bewerten. Unternehmen können priorisieren, welche Komponenten kritisch sind, und proaktiv Gegenmassnahmen einleiten – vom Patch-Management bis hin zum Redesign kritischer Abhängigkeiten.

Einhaltung von regulatorischen Vorgaben: Zunehmend fordern Regulierungen und Standards die Nutzung von SBOMs, z. B.:

• US Executive Order on Improving the Nation’s Cybersecurity (2021) [10]

• EU Cyber Resilience Act (CRA) [11]

• FDA-Leitfaden für Medizinprodukte [12]

Eine SBOM liefert die notwendige Dokumentation, um diese Anforderungen effizient zu erfüllen.

10. Fazit

In einer Welt, in der Anwendungen aus einer Vielzahl externer Komponenten bestehen und Supply-Chain-Angriffe zunehmen, wird Transparenz über die eigenen Abhängigkeiten zum entscheidenden Erfolgsfaktor.

Mit einer SBOM werden folgende Punkte adressiert:

• Klare Sichtbarkeit über alle eingesetzten Komponenten

• Schnellere Reaktionsmöglichkeiten bei Sicherheitsvorfällen

• Bessere Compliance im Umgang mit Open-Source-Lizenzen und die Basis für effiziente, automatisierte Sicherheits- und Risikoanalysen

Zudem wird damit der Grundstein für effiziente, automatisierte Sicherheits- und Risikoanalysen gelegt.

Wichtig ist: Eine SBOM ist kein einmaliges Dokument, sondern ein lebendiger Bestandteil des Entwicklungsprozesses. Erst durch Automatisierung, regelmässige Aktualisierung und die Kombination mit Artefakten wie VEX entfaltet sie ihren vollen Nutzen.

Die Zukunft der Softwareentwicklung wird durch steigende Anforderungen, neue Standards und stärkere Regulierung geprägt sein. Unternehmen, die früh auf SBOMs setzen, schaffen nicht nur Sicherheit, sondern auch Vertrauen – bei Kunden, Partnern und Auditoren. In diesem Sinne ist eine SBOM also nicht nur ein Werkzeug, sondern ein fundamentaler Baustein für robuste und transparente Software-Lieferketten. [1] [2] [5] [16]

Quellen

[1] NIST SP 800-218 – Secure Software Development Framework (SSDF). Link

[2] NIST Cybersecurity Framework (CSF). Link

[3] SolarWinds Supply-Chain Attack Reports. Link

[4] Log4Shell Vulnerability Guidance. Link

[5] CycloneDX – SBOM Standard. Link

[6] SPDX – Software Package Data Exchange. Link

[7] OpenSSF – Open Source Security Foundation. Link

[8] SWID – Software Identification Tags, ISO/IEC 19770-2. Link

[9] Apiiro – The practical guide to software bill of materials (SBOM) Link

[10] Executive Order 14028 – Improving the Nation’s Cybersecurity. Link

[11] EU Cyber Resilience Act. Link

[12] FDA Guidance – Medical Device Cybersecurity. Link

[13] Juice-Shop: Link

[14] Syft, Trivy, CycloneDX-CLI Documentation. Link Syft, Link Trivy, Link CycloneDX-CLI

[15] Dependency-Track – SBOM Management Tool. Link

[16] CSAF / VEX – Vulnerability Exploitability eXchange. Link