In Prüfung: offene Fragen in docs/open-questions.md, nicht veröffentlicht

← Ratgeber

TechnikStand René HerzerMit KI erstellt

Software-Stückliste (SBOM): was drinsteht, wer sie verlangt und wie Sie sie prüfen

Eine Software-Stückliste (SBOM) listet maschinenlesbar alle Bausteine einer Software auf: Name, Version, Hersteller, Lizenz, Abhängigkeiten und Prüfwert. Gängige Formate sind CycloneDX und SPDX. Der Cyber Resilience Act verpflichtet Hersteller ab dem 11. Dezember 2027, für ihre Produkte eine SBOM zu führen. Betreiber nach NIS2 nutzen sie, um Lieferanten zu bewerten und bei einer neuen Sicherheitslücke in Minuten zu wissen, ob sie betroffen sind.

Was ist eine Software-Stückliste?

Eine Software-Stückliste, englisch Software Bill of Materials (SBOM), ist das Inhaltsverzeichnis einer Software. Sie führt jeden Baustein auf, aus dem ein Produkt besteht: eigene Programmteile des Herstellers, Open-Source-Bibliotheken, eingekaufte Komponenten und deren Abhängigkeiten. Das Prinzip kennt man aus der Industrie: Wer ein Gerät baut, weiß aus der Stückliste, welche Schraube von welchem Zulieferer stammt. Bei Software ist das schwerer, weil moderne Anwendungen oft aus Hunderten Bausteinen bestehen, die ihrerseits weitere Bausteine nachladen.

Eine SBOM ist maschinenlesbar. Sie ist keine PDF-Liste zum Durchlesen, sondern eine Datei, die Werkzeuge auswerten. Erst dadurch lässt sie sich mit Schwachstellendatenbanken oder Lizenzlisten abgleichen.

Was steht in einer SBOM?

Für jeden Baustein stehen dort mindestens:

Angabe Wozu sie dient
Name des Bausteins eindeutige Bezeichnung, etwa einer Bibliothek
Version entscheidet, ob eine bekannte Lücke betrifft
Hersteller oder Herausgeber wer für den Baustein verantwortlich ist
Eindeutige Kennung etwa Package-URL (purl) oder CPE, für den Abgleich mit Datenbanken
Lizenz welche Bedingungen für Nutzung und Weitergabe gelten
Abhängigkeiten welcher Baustein welchen anderen enthält oder braucht
Prüfwert (Hash) belegt, dass die gelieferte Datei die beschriebene ist

Dazu kommen Angaben zur SBOM selbst: wer sie erstellt hat und wann.

Welche Formate gibt es: CycloneDX und SPDX?

Zwei Formate haben sich durchgesetzt:

  • CycloneDX: entstanden in der OWASP-Gemeinschaft für Sicherheitsfragen, genormt als ECMA-424. Kann neben Software auch Dienste, Hardware und KI-Modelle beschreiben und VEX-Angaben in einer eigenen Datei tragen.
  • SPDX: entstanden bei der Linux Foundation mit Schwerpunkt Lizenzen, in der Fassung 2.2.1 genormt als ISO/IEC 5962:2021; aktuell ist die Fassung 3.

Beide gibt es als JSON oder XML, beide lesen die gängigen Werkzeuge. Für Sie als Kunde zählt weniger das Format als die Frage, ob Ihr eigenes Werkzeug es verarbeitet und ob die Pflichtfelder gefüllt sind.

Was gehört mindestens hinein: NTIA und BSI TR-03183-2?

Zwei Vorgaben beschreiben, was eine SBOM mindestens enthalten soll:

  • NTIA „Minimum Elements“ (USA, Juli 2021): sieben Datenfelder, nämlich Hersteller, Name, Version, weitere eindeutige Kennungen, Abhängigkeiten, Ersteller der SBOM und Zeitstempel. Dazu die Forderung, dass die SBOM automatisch erzeugt und maschinenlesbar ist. Die US-Behörde CISA hat im August 2025 einen Entwurf zur Aktualisierung vorgelegt, der unter anderem Prüfwert und Lizenz hinzufügt.
  • BSI TR-03183-2 (Deutschland, Version 2.1.0 vom 20. August 2025): Die Technische Richtlinie des BSI bereitet auf den Cyber Resilience Act vor und ist strenger. Sie verlangt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Pflicht sind je Baustein unter anderem Ersteller, Name, Version, Dateiname, Abhängigkeiten, Lizenzen für die Weitergabe und ein Prüfwert nach SHA-512, dazu Angaben, ob es sich um ausführbaren Code oder ein Archiv handelt. Abhängigkeiten sind rekursiv aufzulösen, mindestens bis zum ersten Baustein außerhalb des Lieferumfangs. Für jede neue Version ist eine neue SBOM zu erstellen. Schwachstellen gehören ausdrücklich nicht in die SBOM.

Die TR-03183 ist eine Empfehlung des BSI, kein Gesetz. Wer sich an ihr orientiert, erfüllt aber, was Prüfer und Einkauf heute in Deutschland erwarten.

Warum verlangen Kunden eine SBOM?

Der Cyber Resilience Act verpflichtet Hersteller

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) gilt für Produkte mit digitalen Elementen, die in der EU auf den Markt kommen, also auch für Software. Anhang I Teil II Nr. 1 verpflichtet Hersteller, die Komponenten ihres Produkts zu ermitteln und zu dokumentieren, unter anderem durch eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt.

Die Fristen (Art. 71):

Ab Was gilt
11. September 2026 Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle (Art. 14)
11. Dezember 2027 alle übrigen Pflichten, darunter SBOM, Behandlung von Schwachstellen, technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung

Die SBOM muss nicht öffentlich sein (Erwägungsgrund 77). Sie gehört zur technischen Dokumentation, die die Marktüberwachungsbehörde auf begründetes Verlangen einsehen kann (Anhang VII). Gibt der Hersteller sie an Kunden weiter, nennt er in der Produktinformation, wo sie zu finden ist (Anhang II Nr. 9). Der Hersteller muss Schwachstellen über einen Unterstützungszeitraum behandeln, der mindestens fünf Jahre beträgt; kürzer nur, wenn das Produkt voraussichtlich kürzer genutzt wird (Art. 13 Abs. 8). Format und Mindestinhalt der SBOM kann die EU-Kommission noch per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Für Open-Source-Bausteine, die er einbaut, trägt er die Sorgfaltspflicht mit.

NIS2 und das BSI-Gesetz verpflichten Betreiber

Die Pflichten nach NIS2 treffen nicht das Produkt, sondern die Einrichtung, die es betreibt. Art. 21 der Richtlinie zählt die Sicherheit der Lieferkette und die Behandlung von Schwachstellen ausdrücklich zu den Risikomanagementmaßnahmen und verlangt, dabei die Schwachstellen der einzelnen Lieferanten und die Qualität ihrer Produkte zu berücksichtigen. In Deutschland ist das NIS-2-Umsetzungsgesetz seit dem 6. Dezember 2025 in Kraft; die Maßnahmen stehen in § 30 BSIG. Viele Krankenhäuser, Stadtwerke, Wasserversorger und IT-Dienstleister der Verwaltung fallen darunter. Mehr dazu: ISO 27001 und NIS2 für KI.

Eine SBOM ist kein gesetzlich vorgeschriebener Nachweis für Betreiber. Sie ist aber der naheliegende Beleg, dass Sie die Bestandteile Ihrer Lieferanten kennen und deren Schwachstellen verfolgen.

B3S Krankenhaus, KRITIS und Ausschreibungen

Krankenhäuser weisen ihre Maßnahmen meist nach dem Branchenstandard B3S Krankenhaus nach (aktuell Version 1.3.1, Eignung vom BSI im November 2025 festgestellt). Im Audit fragen Prüfer in der Regel, wie das Haus Dienstleister, Updates und Schwachstellen steuert; eine aktuelle SBOM je Produkt macht diese Antworten belegbar. Für KRITIS-Betreiber gilt dasselbe beim Nachweis gegenüber dem BSI.

In einer Ausschreibung nehmen Sie die SBOM als Anforderung an Bieter in die Leistungsbeschreibung auf und vereinbaren Lieferung und Aktualisierung im Vertrag, auch wenn Sie die Vertragsbedingungen EVB-IT verwenden. Wie Sie eine KI-Plattform ausschreiben: Leitfaden.

Wie nutzen IT und Informationssicherheit eine SBOM?

Abgleich mit bekannten Schwachstellen

Erscheint eine neue Sicherheitslücke in einer verbreiteten Bibliothek, ist die erste Frage im Haus: Sind wir betroffen? Ohne SBOM heißt das, jeden Hersteller anzuschreiben und auf Antwort zu warten. Mit SBOM gleicht ein Werkzeug die Bausteine aller Produkte mit den Datenbanken bekannter Schwachstellen (CVE) ab und zeigt in Minuten, welche Systeme die betroffene Version enthalten.

Der Abgleich liefert oft mehr Treffer, als tatsächlich gefährlich sind: Eine Bibliothek kann enthalten sein, ohne dass die verwundbare Funktion je aufgerufen wird. Hier helfen zwei Ergänzungen des Herstellers:

  • CSAF: ein maschinenlesbares Format für Sicherheitshinweise (OASIS-Standard, Version 2.0). Hersteller veröffentlichen darin, welche Produkte und Versionen betroffen sind und was zu tun ist.
  • VEX (Vulnerability Exploitability eXchange): eine Aussage des Herstellers je Lücke und Produkt, mit einem von vier Zuständen: nicht betroffen, betroffen, behoben oder in Prüfung. „Nicht betroffen“ braucht eine Begründung.

SBOM, VEX und CSAF zusammen trennen echte Risiken von Fehlalarmen. Wie ein Ablauf für Sicherheitsupdates aussieht: Patch-Management.

Lizenzen prüfen

Die SBOM nennt die Lizenz jedes Bausteins. Damit sieht Ihre Rechtsabteilung oder Ihr Lizenzmanagement, ob Bausteine mit Bedingungen enthalten sind, die für Ihren Einsatz relevant werden, etwa bei Weitergabe an Dritte oder Betrieb als Dienst für andere Einrichtungen. Für eingekaufte Produkte trägt der Hersteller die Lizenzpflichten; bei selbst gebauten Lösungen liegen sie bei Ihnen. Mehr dazu: Lizenzrisiko bei Open-Source-Werkzeugen.

Aktualität je Release

Eine SBOM beschreibt genau eine Version. Nach jedem Update ist sie veraltet, wenn nicht eine neue kommt. Prüfen Sie deshalb drei Dinge:

  1. Passt die Version? Die SBOM nennt die Produktversion, die bei Ihnen läuft.
  2. Ist sie vollständig? Auch Abhängigkeiten der Abhängigkeiten sind aufgeführt, nicht nur die oberste Ebene.
  3. Ist sie plausibel? Stichproben: Stimmen Prüfwerte, sind Lizenzen angegeben, fehlen offensichtliche Bausteine wie Datenbank oder Anmeldedienst?

Worauf achtet der Einkauf?

Punkt Was Sie vereinbaren
Format maschinenlesbar, CycloneDX oder SPDX in aktueller Fassung; Orientierung an BSI TR-03183-2
Tiefe alle ausgelieferten Bausteine mit ihren Abhängigkeiten, nicht nur die oberste Ebene
Häufigkeit neue SBOM mit jedem Release, auch bei Sicherheitsupdates
Zugang wo und wie Sie sie bekommen: im Produkt, im Kundenportal oder auf Anfrage; vor dem Kauf zur Prüfung
Vertraulichkeit SBOM zeigt die innere Struktur eines Produkts; eine Vertraulichkeitsvereinbarung ist üblich und berechtigt
Schwachstellen Meldeweg für Sicherheitslücken (etwa security.txt), Sicherheitshinweise, möglichst als CSAF, und VEX-Angaben
Unterstützungszeitraum wie lange der Hersteller Sicherheitsupdates liefert

Ein Hersteller, der noch keine SBOM nach allen Feldern der TR-03183-2 liefert, ist nicht automatisch ungeeignet: Die Pflicht nach dem Cyber Resilience Act beginnt erst im Dezember 2027, und viele Hersteller stellen gerade um. Fragen Sie nach dem Stand und lassen Sie sich einen Termin nennen. Weitere Fragen für die Auswahl: Checkliste KI-Anbieter bewerten.

Was kann eine SBOM nicht?

  • Sie sagt nichts über Ausnutzbarkeit. Ob eine Lücke im konkreten Produkt gefährlich ist, steht in VEX und Sicherheitshinweisen.
  • Sie ersetzt kein Patch-Management. Wer weiß, dass er betroffen ist, muss das Update noch einspielen.
  • Sie belegt keine Qualität. Eine vollständige Liste sagt nichts darüber, wie sorgfältig die Bausteine gepflegt werden.
  • Sie beschreibt bei KI nicht das Modell. Welches KI-Modell in welcher Version läuft, gehört in ein eigenes Verzeichnis der Modelle; CycloneDX kann Modelle zwar abbilden, üblich ist das noch nicht.

Wie ist das bei basebox?

basebox ist eine fertige Plattform mit Lizenz, Support und Updates und selbst kein Open Source. Sie baut auf Open-Source-Bausteinen auf, etwa vLLM für das KI-Modell und Keycloak für die Anmeldung; welche Bausteine enthalten sind, steht in der Software-Stückliste.

  • SBOM zu jedem Release: Sie wird automatisch erstellt und mit jedem Release aktualisiert.
  • Zugang: Kunden sehen sie vollständig in ihrer basebox: Administratoren im Bereich Sicherheit, alle Personen die Liste der Open-Source-Software unter „Über“. Vor dem Kauf schicken wir sie auf Anfrage: SBOM anfordern.
  • Prüfung vor jedem Release: Die Abhängigkeiten werden auf bekannte Schwachstellen (CVE) geprüft, dazu eine statische Code-Analyse. Bei einer bekannten Schwachstelle schlägt das Release fehl. Zu jeder Version gibt es Release Notes, Sie werden per E-Mail informiert.
  • Meldeweg: Sicherheitslücken melden Sie an security@basebox.ai; den Eingang bestätigen wir innerhalb von zwei Werktagen. Die Kontaktdaten stehen maschinenlesbar in der security.txt. Sicherheitslücken melden
  • Cyber Resilience Act: In Arbeit. Software-Stückliste und Meldeweg stehen. Die Prozesse für Schwachstellen und Sicherheitsupdates über den gesamten Unterstützungszeitraum, die technische Dokumentation und die EU-Konformitätserklärung folgen vor Ablauf der Frist am 11. Dezember 2027. Stand beim Cyber Resilience Act
  • NIS2 und Lieferkette: Entwicklung, Support und Betrieb sind in Deutschland. Für Ihre Prüfung des Lieferanten bekommen Sie das Zertifikat nach ISO 27001, die Software-Stückliste, den Meldeweg für Sicherheitslücken, Angaben zum Penetrationstest durch externe Prüfer und eine Zuordnung zu den NIS2-Maßnahmen. Antworten für Ihre Sicherheitsprüfung

Keine Rechtsberatung: Dieser Beitrag gibt einen Überblick über Vorgaben und Praxis, Stand der Recherche und Abruf aller Quellen: 13. Oktober 2026. Ob und wie die genannten Pflichten für Ihre Einrichtung gelten, klären Sie mit Ihrer Informationssicherheit, Ihrem Datenschutz oder einer Rechtsberatung. Die BSI TR-03183 ist eine Empfehlung; maßgeblich sind die Verordnung und die nationalen Gesetze.

Häufige Fragen

Muss ein Hersteller seine SBOM veröffentlichen?

Nein. Der Cyber Resilience Act verlangt, dass der Hersteller eine SBOM erstellt und als Teil der technischen Dokumentation führt. Die Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern (Anhang VII). Gibt der Hersteller sie an Kunden weiter, muss er angeben, wo sie zu finden ist (Anhang II Nr. 9). Ob und wie Kunden sie bekommen, regelt der Vertrag.

Gilt der Cyber Resilience Act auch für Cloud-Dienste?

Reine Cloud-Dienste ohne Produkt beim Kunden fallen grundsätzlich unter NIS2, nicht unter den Cyber Resilience Act (Erwägungsgrund 12). Er erfasst sie nur, soweit sie als Datenfernverarbeitung zu einem Produkt gehören. Für den Betreiber ändert das wenig: Nach NIS2 bewertet er seine Lieferanten in beiden Fällen.

Stehen Sicherheitslücken in der SBOM?

Nein. Die SBOM sagt, was in der Software steckt. Ob eine bekannte Lücke darin ausnutzbar ist, steht in eigenen Dokumenten, etwa Sicherheitshinweisen im Format CSAF oder VEX-Angaben des Herstellers. Die Technische Richtlinie TR-03183-2 des BSI rät ausdrücklich, Schwachstellen nicht in die SBOM zu schreiben.

CycloneDX oder SPDX: welches Format sollten wir verlangen?

Beide sind verbreitet und von Werkzeugen gut lesbar; SPDX ist als ISO/IEC 5962 genormt, CycloneDX als ECMA-424. Wichtiger als die Wahl ist, dass Ihr eigenes Werkzeug das Format lesen kann und die Pflichtfelder gefüllt sind. In einer Ausschreibung genügt meist: „maschinenlesbar in CycloneDX oder SPDX in aktueller Fassung“.

Wie oft sollte eine SBOM aktualisiert werden?

Mit jeder neuen Version der Software. Die TR-03183-2 des BSI verlangt eine neue SBOM je Version und eine Korrektur, sobald Angaben falsch waren oder neue Angaben zu Komponenten vorliegen. Eine SBOM von vor einem Jahr beschreibt meist nicht mehr, was bei Ihnen läuft.

Quellen

  1. Verordnung (EU) 2024/2847 (Cyber Resilience Act), Erwägungsgründe 12 und 77, Art. 13, 14, 71, Anhang I Teil II, Anhang II, Anhang VII (EUR-Lex, abgerufen 13.10.2026) ↗
  2. Richtlinie (EU) 2022/2555 (NIS2), Art. 21 (EUR-Lex, abgerufen 13.10.2026) ↗
  3. § 30 BSIG: Risikomanagementmaßnahmen (gesetze-im-internet.de, abgerufen 13.10.2026) ↗
  4. BSI: NIS-2-Umsetzungsgesetz ab 6. Dezember 2025 in Kraft (Pressemitteilung, abgerufen 13.10.2026) ↗
  5. BSI: Technische Richtlinie TR-03183, Teil 2 Software Bill of Materials, Version 2.1.0 vom 20.08.2025 (abgerufen 13.10.2026) ↗
  6. NTIA: The Minimum Elements For a Software Bill of Materials (12. Juli 2021, abgerufen 13.10.2026) ↗
  7. CISA: 2025 Minimum Elements for a Software Bill of Materials, Entwurf zur Kommentierung (August 2025, abgerufen 13.10.2026) ↗
  8. CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX) (abgerufen 13.10.2026) ↗
  9. OASIS: Common Security Advisory Framework (CSAF) Version 2.0 (abgerufen 13.10.2026) ↗
  10. CycloneDX: Spezifikation, genormt als ECMA-424 (abgerufen 13.10.2026) ↗
  11. Ecma International: ECMA-424 CycloneDX Bill of Materials Specification (abgerufen 13.10.2026) ↗
  12. SPDX: Spezifikationen, Fassung 2.2.1 genormt als ISO/IEC 5962:2021 (abgerufen 13.10.2026) ↗
  13. DKG: Branchenspezifischer Sicherheitsstandard für die Gesundheitsversorgung im Krankenhaus (B3S), Version 1.3.1 (abgerufen 13.10.2026) ↗

Dieser Artikel wurde mit Unterstützung von KI erstellt, auf Grundlage der genannten Quellen. Verantwortlich für den Inhalt: basebox GmbH. Keine Rechtsberatung, keine Haftung. Stand der Recherche: 13. Oktober 2026.

Cookie-Einstellungen

Diese Website setzt keine Cookies zur Analyse oder Werbung und bindet keine Werkzeuge anderer Anbieter ein. Im Speicher Ihres Browsers liegt nur, was für die Bedienung nötig ist. Datenschutzerklärung