Die Software Bill of Materials (SBOM) als Governance-Instrument

Mit dem Cyber Resilience Act (CRA) schafft der europäische Gesetzgeber erstmals ein kohärentes und verpflichtendes Rahmenwerk für die Cybersicherheit von Produkten mit digitalen Elementen. Ab dem 11. Dezember 2027 dürfen solche Produkte nur noch dann in den europäischen Verkehr gebracht werden, wenn Hersteller umfangreiche Anforderungen an Sicherheit, Risikoanalyse, Schwachstellenmanagement und technische Dokumentation erfüllen. Ein wesentlicher Teil dieser Dokumentationspflichten betrifft die Transparenz über die in einem Produkt enthaltenen Software-Komponenten und Abhängigkeiten. Damit rückt die sogenannte Software Bill of Materials (SBOM) als etabliertes Instrument zur strukturierten Umsetzung dieser Vorgaben zunehmend in den Fokus und gewinnt damit für Verwaltung, Beschaffungspraxis und IT-Governance erheblich an Bedeutung.

1. SBOM im CRA: Anforderungen an Hersteller

Der CRA verpflichtet Hersteller ausdrücklich dazu,

• die in einem Produkt verwendeten Software-Komponenten, Bibliotheken und Abhängigkeiten zu identifizieren,
• diese nachvollziehbar und strukturiert zu dokumentieren, sowie
• eine Risiko- und Schwachstellendokumentation zu führen (Risk Assessment und Vulnerability Handling).

Zur strukturierten Darstellung einer solchen Komponentenübersicht haben sich branchenweit standardisierte Formate wie SPDX oder CycloneDX etabliert, die auch in der BSI-TR-03183-2 als geeignete Profile beschrieben sind.

Eine SBOM enthält typischerweise:

• verwendete Bibliotheken, Module und Frameworks,
• Third-Party-Komponenten (Open Source und proprietär),
• Versionen und Lizenzinformationen,
• sowie Identifikatoren/Metadaten, die einen Abgleich mit Schwachstelleninformationen (z. B. CVE, CSAF) ermöglichen. Schwachstelleninformationen und Aussagen zur Betroffenheit sind jedoch nicht Bestandteil der SBOM, sondern werden typischerweise über Security Advisories/CSAF/VEX bereitgestellt.

Damit wird sie zu einem zentralen Instrument für Cybersicherheit, Compliance und Transparenz entlang der Software-Lieferkette.

2. Bedeutung der SBOM für die öffentliche IT-Beschaffung

2.1 Keine Offenlegungspflicht gegenüber Auftraggebern

Der CRA sieht keine Verpflichtung vor, eine SBOM an Kunden oder öffentliche Auftraggeber herauszugeben. SBOMs können öffentlich oder zugangsbeschränkt bereitgestellt werden; Umfang und Detailtiefe variieren. In der Praxis bestehen regelmäßig legitime Schutzinteressen (u. a. Angriffsflächen-/Lieferketten-Transparenz, Geschäftsgeheimnisse, Operational Security), sodass sich eine zweckgebundene, abgestufte Bereitstellung (Need-to-know) anbietet. SBOMs und die zugehörige technische Dokumentation sind primär interne Herstellerunterlagen, die im CRA nur für Konformitätsbewertung und Marktüberwachung vorgesehen sind; sie bleibt damit grundsätzlich vertraulich.

Für die öffentliche Beschaffung bedeutet dies zweierlei:

a. Keine automatische Übermittlung

Öffentliche Auftraggeber erhalten eine SBOM nicht „automatisch“ als Standard-Bestandteil mit dem Angebot. Und eine ausdrückliche Anforderung als Teil der Angebotsunterlagen ist nur in technisch und vergaberechtlich eng begründbaren Ausnahmefällen sachgerecht.

b. Keine gesetzlichen Einsichtsrechte

Der CRA begründet auch keine späteren gesetzlichen Einsichts- oder Herausgaberechte zugunsten von Auftraggebern. Transparenz lässt sich daher ausschließlich über vertraglich vereinbarte Einsichts- oder Auditrechte herstellen.

2.2 Technisch-juristische Relevanz für Betrieb und Compliance

Eine SBOM ist im öffentlichen Sektor jedoch für Auftraggeber zunehmend unverzichtbar, um:

• herstellerseitige CRA-Anforderungen (Risk Assessment, Vulnerability Handling) im laufenden Betrieb nachvollziehen und berücksichtigen zu können,
• ggf. eigene Betreiberpflichten aus NIS-2, IT-Sicherheitsrecht und interner IT-Governance zu unterstützen (insb. Schwachstellen- und Patchmanagement),
• Lizenzrisiken (z. B. AGPL) verlässlich zu bewerten,
• nachhaltige Wartbarkeit und Lebenszyklusentscheidungen zu ermöglichen,
• Architekturen und technische Abhängigkeiten nachvollziehbar zu machen, und
• Abhängigkeiten gegenüber einzelnen Herstellern transparent zu bewerten und dadurch Vendor-Lock-in-Risiken zu reduzieren.

In der praktischen IT-Governance ergänzt oder ersetzt die SBOM vielfach klassische Escrow-Konzepte: Sie wirkt präventiv, ist maschinenlesbar und liefert die Transparenz, die moderne Systeme und regulatorische Anforderungen verlangen.

3. SBOM-Anforderungen im Vergabeverfahren

3.1 Wann kann eine SBOM bereits mit dem Angebot verlangt werden?

Der CRA verpflichtet Hersteller umfassend zur internen Dokumentation der im Produkt enthaltenen Software-Komponenten und Abhängigkeiten; eine Offenlegung gegenüber Kunden oder öffentlichen Auftraggebern ist nicht vorgesehen.

Ob und unter welchen Voraussetzungen öffentliche Auftraggeber eine SBOM bereits als Bestandteil des Angebots verlangen dürfen, ist derzeit gesetzlich nicht ausdrücklich geregelt und im Einzelfall vergaberechtlich zu prüfen. Die nachfolgenden Fallgruppen stellen keine abschließende oder verbindliche Positivliste dar, sondern spiegeln eine rechtliche Bewertung wider, in welchen Konstellationen eine solche Anforderung ausnahmsweise sachlich gerechtfertigt sein kann.

• Open-Source-Software, wenn der konkrete Beschaffungsgegenstand eine Weiterentwicklung, Integration in eigene Systeme oder die Übernahme von Wartungs- und Betreiberverantwortung vorsieht und die Beurteilung von Lizenz-, Lieferketten- oder Upstream-Risiken ohne Kenntnis der eingesetzten Komponenten nicht möglich ist,
• kritischen oder hochkomplexen IT-Architekturen, bei denen Integrationsrisiken nur anhand einer Komponentenübersicht belastbar bewertet werden können,
• sicherheitskritischen Bereichen (KRITIS, Polizei, Justiz), wenn der Auftraggeber objektiv eine erhöhte Transparenz über Komponenten und Abhängigkeiten benötigt,
• erkennbare Lizenzrisiken (z. B. Copyleft-Lizenzen), die ohne Komponentenkenntnis nicht geprüft werden können.

Unabhängig von der Vorlage einer vollständigen SBOM können öffentliche Auftraggeber jedoch bereits im Vergabeverfahren insbesondere Anforderungen an SBOM-Fähigkeit (Erstellungs-/Aktualisierungsprozess und Toolchain), Lieferketten-Transparenz und den Umgang mit Open-Source-Komponenten stellen, etwa in Form von Konzepten, Nachweisen zu Community-/Herstellerbezug und Upstream-Strategie, oder der Darstellung von Update- und Schwachstellenmanagementprozessen.

In allen anderen Fällen wäre die Forderung nach einer vollständigen SBOM bereits mit dem Angebot nach hier vertretener Auffassung regelmäßig unverhältnismäßig und potenziell wettbewerbsbeschränkend. Stattdessen sollten Auftraggeber notwendige Transparenz im Wege vertraglich vereinbarter Einsichts- oder Auditmechanismen absichern.

3.2 Vertragsgestaltung: SBOM-Einsichtsrechte

SBOM-Transparenz kann vertraglich abgesichert werden, insbesondere durch:

• Einsichtsrechte bei Sicherheitsvorfällen oder Integrationsfragen,
• Auditrechte für sicherheitskritische Komponenten,
• Pflichten zur Aktualisierung der relevanten Komponentenübersicht,
• Nachweise zur Unterstützung der nach CRA und NIS-2 geforderten Lieferketten- und Schwachstellentransparenz, sowie nachhaltiger Beschaffung.

NIS-2 verlangt ausdrücklich Risikoanalysen, Lieferkettentransparenz, Schwachstellen- und Patchmanagement, Anforderungen, die ohne Komponentenübersichten faktisch nicht erfüllbar sind.

Diese vertraglichen Mechanismen bedeuten nicht zwingend die Offenlegung einer vollständigen SBOM. In der Praxis geht es meist um auszugsweise oder anlassbezogene Transparenz über sicherheitsrelevante oder integrative Komponenten. Umfang und Tiefe der SBOM-Einsicht sind regelmäßig vertraglich festzulegen; vollständige SBOM-Einsichten bleiben, außerhalb ausdrücklich vereinbarter Konstellationen, hochkritischen Ausnahmefällen vorbehalten.

4. SBOM als unsichtbare Grundlage vieler Leistungsanforderungen

Auch wenn eine SBOM in Vergabeunterlagen häufig nicht explizit genannt wird, wird sie inhaltlich oft dennoch vorausgesetzt.

Dies gilt immer dann, wenn Auftraggeber Anforderungen stellen wie:

• Lizenz- und Compliance-Nachweise,
• Schwachstellen- und Patchmanagement,
• Risikobewertungen,
• Architektur- und Komponenten-Transparenz,
• Sicherheits- und Updatekonzepte,
• Dokumentation der Lieferkette,
• oder Pflichten aus CRA, NIS-2 und nachhaltiger Beschaffung.

Solche Pflichten kann ein Anbieter in der Praxis nur erfüllen, wenn er intern eine strukturierte Komponentenübersicht führt – also de facto eine SBOM vorhält.

Nach den bislang öffentlich bekannten Informationen hat der IT-Planungsrat Ende 2025 die Veröffentlichung einer aktualisierten Fassung der EVB-IT beschlossen, um die Standardvertragsmuster künftig besser für die Beschaffung von Open-Source-Software nutzbar zu machen. In diesem Zusammenhang ist vorgesehen, SBOM-bezogene Regelungen in einzelnen Vertragsmustern bzw. Vertragsanlagen optional abzubilden.

Aus den angekündigten Anpassungen ergibt sich keine generelle vergaberechtliche Verpflichtung, eine SBOM bereits im Vergabeverfahren oder als Bestandteil des Angebots zu verlangen. Vielmehr unterstreichen die geplanten Regelungen die Bedeutung einer sachgerechten vertraglichen Ausgestaltung von Transparenz- und Einsichtsmechanismen, die im Einzelfall unter Berücksichtigung des Beschaffungsgegenstands sowie der vergabe- und vertragsrechtlichen Rahmenbedingungen zu prüfen ist.

5. Fazit

Mit dem Cyber Resilience Act wird die Transparenz über Software-Komponenten zu einem zentralen Baustein moderner IT-Sicherheit und IT-Beschaffung. Eine SBOM schafft die Nachvollziehbarkeit, die für Risikoanalysen, Schwachstellen-/Patchmanagement und Lieferkettenbewertungen regelmäßig erforderlich ist und damit die Umsetzung der CRA-Anforderungen sowie (wo einschlägig) NIS-2-bezogener Sicherheits- und Governance-Pflichten wirksam unterstützt.

Für die öffentliche Hand bedeutet dies:

Eine vollständige SBOM wird im Vergabeverfahren regelmäßig nicht als vom Bieter einzureichende Unterlage verlangt werden, weil sie für Eignungsprüfung und Wertung typischerweise nicht erforderlich ist und eine pauschale Forderung häufig unverhältnismäßig bzw. wettbewerbsbeschränkend wäre. Stattdessen kommen im Verfahren eher Anforderungen an SBOM-Fähigkeit, Lieferketten-Transparenz sowie Schwachstellen-/Updateprozesse in Betracht.

Für den späteren sicheren, wartbaren und regelkonformen Betrieb ist sie jedoch von hoher praktischer Relevanz.

SBOM-basierte Transparenz wird daher Gegenstand der Vertragsgestaltung: über klar definierte, zweckgebundene und abgestufte Einsichts-, Audit- und Aktualisierungsmechanismen, die sowohl den Informationsbedürfnissen der Auftraggeber als auch den berechtigten Schutzinteressen der Hersteller Rechnung tragen.

Damit wird die SBOM zu einem wirksamen Governance-Instrument: als Grundlage für verantwortungsvolle, nachhaltige und sicherheitsbewusste IT-Beschaffung.