Wissen, was drin ist: Die SBOM zwischen CRA, NIS2 und DORA

Die eigentliche Frage lautet nicht „Sind wir sicher?”, sondern „Sind wir betroffen?”

Im Dezember 2021 kostete Log4Shell die meisten Organisationen nicht deshalb Nerven, weil das Patchen so schwierig gewesen wäre. Es kostete Nerven, weil niemand sagen konnte, wo überall log4j-core steckte. Zwei Wochen Telefonate mit Lieferanten, Excel-Listen, Rückfragen an Dienstleister, die selbst ihre Zulieferer fragen mussten. Im März 2024 wiederholte sich das Muster bei der Backdoor in xz-utils, diesmal mit dem zusätzlichen Reiz, dass die Schwachstelle absichtlich und geduldig eingeschleust worden war.

In beiden Fällen war die teuerste Ressource nicht der Patch. Es war die Zeit bis zur Antwort auf eine erschreckend einfache Frage: Ist das bei uns drin?

Genau an diesem Punkt setzt die Software Bill of Materials (SBOM) an — und genau deshalb taucht sie inzwischen in drei europäischen Regelwerken auf, einmal ausdrücklich und zweimal durch die Hintertür. Dieser Beitrag ordnet ein, was der Cyber Resilience Act, NIS2 und DORA tatsächlich verlangen, und übersetzt das in drei Praxisperspektiven: Sie kaufen Software ein, Sie nutzen SaaS, Sie entwickeln selbst. Meist trifft mehr als eine davon zu.

1. Was eine SBOM ist — und was sie nicht ist

Eine SBOM ist eine maschinenlesbare Stückliste eines Softwareprodukts: welche Komponenten enthalten sind, in welcher Version, von wem, in welchem Abhängigkeitsverhältnis zueinander. Das Bild von der Zutatenliste auf der Lebensmittelverpackung ist gängig und trägt bis zu einem gewissen Punkt — es verschweigt allerdings, dass eine typische Anwendung nicht sieben, sondern zwischen 200 und mehreren tausend „Zutaten” hat, viele davon transitiv über mehrere Ebenen eingeschleppt.

Formate

Zwei Formate haben sich durchgesetzt und werden von allen relevanten Regelwerken akzeptiert:

• SPDX (Linux Foundation), in Version 2.2.1 als ISO/IEC 5962 normiert; die BSI TR-03183-2 verlangt allerdings mindestens Version 3.0.1
• CycloneDX (OWASP), als ECMA-424 standardisiert; die BSI TR-03183-2 verlangt mindestens Version 1.6

Beide sind gleichwertig einsetzbar und werden in der internationalen Baseline von 2026 ausdrücklich als die beiden breit genutzten Formate benannt. Die Wahl folgt in der Praxis dem Ökosystem: Wer viel mit Container-Images und Sicherheitswerkzeugen arbeitet, landet meist bei CycloneDX; wer aus dem Lizenz-Compliance-Umfeld kommt, oft bei SPDX. Für die Komponentenidentifikation ist zusätzlich relevant, dass auch Package-URL (PURL) inzwischen als ECMA-427 normiert ist — neben CPE der Standardschlüssel für den automatisierten Abgleich.

Mindestinhalte: Was sich Ende Juli 2026 geändert hat

Wer sich bisher an den NTIA Minimum Elements von 2021 orientiert hat — Lieferant, Komponentenname, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehungen, Autor, Zeitstempel — muss umstellen. Am 29. Juli 2026 haben die CISA und 17 Partnerbehörden aus 14 Staaten die „2026 Minimum Elements for a Software Bill of Materials” veröffentlicht und damit die Fassung von 2021 abgelöst. Das BSI ist Mitautor, ebenso ANSSI, NCSC-NL, ACN, NÚKIB, NASK und weitere. Vorausgegangen war ein Entwurf vom August 2025 und ein öffentliches Kommentierungsverfahren.

Für den europäischen Kontext bemerkenswert: Die Generaldirektion CONNECT der Europäischen Kommission hat am Dokument mitgewirkt — mit der ausdrücklichen Fußnote, dass es weder EU-Recht auslegt noch die Kommission bindet und für Unionsrechtsadressaten nur Informationszwecken dient. Das ist genau die richtige Einordnung: ein starkes Konvergenzsignal, keine Rechtsquelle.

Fünf Punkte sind für die Praxis relevant.

1. Zehn neue Datenfelder. Der Sprung ist größer, als die Berichterstattung nahelegt. Neu sind:

Insgesamt umfasst der Katalog jetzt 17 Datenfelder, ergänzt um sieben Elemente unter „Practices and Processes”.

2. Umbenennungen und eine Streichung. Supplier Name → Component Producer, Author of SBOM Data → SBOM Author, Version of the Component → Component Version, Other Unique Identifiers → Component Identifiers, Depth → Coverage, Known Unknowns → Explicitly Identifying Unknown Information, Automation Support → Machine-Processable Data. Das Element Access Control entfällt und geht in Distribution and Delivery auf.

Für CRA-Adressaten wichtig — und das Dokument sagt es selbst in einer Fußnote: „Component Producer” ist nicht gleichbedeutend mit dem europäischen „Hersteller”. Jeder Hersteller im Sinne des CRA ist ein Producer, aber nicht jeder Producer ist Hersteller. Wer die Begriffe in Verträgen vermischt, produziert Auslegungsstreit.

3. Aus „Depth” wird „Coverage” — die inhaltlich schwerwiegendste Änderung. Die alte Definition erfasste ausdrücklich nur Abhängigkeiten der obersten Ebene; das spiegelte den Werkzeugstand von 2021, nicht den Informationsbedarf. Der neue Text ist unmissverständlich: Eine SBOM soll alle Komponenten der Zielsoftware einschließlich transitiver Abhängigkeiten enthalten, und es gibt keine Mindesttiefe mehr. „Coverage” meint zudem horizontale wie vertikale Breite. Existieren mehrere Instanzen einer Komponente mit unterschiedlichen Metadaten, ist jede einzeln zu listen.

Zwei praktisch wichtige Präzisierungen, die in den Zusammenfassungen meist untergehen: Nicht-Code-Dateien dürfen ausgeschlossen werden, sicherheitsrelevante Dateien wie Konfigurationsdateien dürfen enthalten sein — beides ist eine Kann-Regelung, keine Pflicht. Und: Die Verlinkung auf separate SBOMs für Teilkomponenten erfüllt das Coverage-Element ebenfalls, sofern der Empfänger Zugriff auf alle verlinkten Dokumente hat. Der zweite Halbsatz gehört in jede Vertragsklausel, sonst bekommen Sie eine Kette von Verweisen ins Leere.

Der Maßstab, den das Dokument selbst formuliert, ist der eigentliche Prüfstein:

Der Empfänger einer SBOM soll aus dem Nichtvorhandensein einer Komponente schließen dürfen, dass eine neu gemeldete Schwachstelle ihn nicht betrifft. Wer das nicht garantieren kann, hat keine belastbare SBOM.

4. Lücken müssen benannt werden — und die Fehlertoleranz ist weg. Fehlende Angaben sind ausdrücklich als unbekannt oder als zurückgehalten zu kennzeichnen; die beiden Fälle sind zu unterscheiden. Der SBOM-Autor soll einen Prozess vorhalten, über den Empfänger zu geschwärzten sicherheitsrelevanten Angaben nachfragen können, und eine SBOM darf als unvollständig gelten, wenn wesentliche Komponentendaten zurückgehalten werden.

Bemerkenswerter noch ist die stillschweigende Verschärfung: Das alte Element „Accommodation of Mistakes” — 2021 als Zugeständnis an die Unreife des Ökosystems gedacht — ist ersatzlos gestrichen. An seiner Stelle steht die Aussage, dass Empfänger inzwischen korrekte SBOM-Daten erwarten dürfen und Fehler in die Risikobewertung des Lieferanten einfließen können. Aus „Fehler passieren” ist „Fehler sind ein Lieferantenrisiko” geworden. Für Beschaffung und Lieferantenbewertung ist das die praktisch folgenreichste Zeile des Dokuments.

5. Formatpolitik. SPDX und CycloneDX sind als die beiden breit genutzten Formate benannt; SWID-Tags wurden aus der Liste gestrichen. Organisationen sollen jedes verbreitete, interoperable und maschinenverarbeitbare Format akzeptieren — aber für neue Software keine SBOMs mehr annehmen, die in abgekündigten Formatversionen erzeugt wurden.

Der Geltungsbereich umfasst nun ausdrücklich Open Source, KI-Software und SaaS; dazu unten mehr.

Zur Einordnung, und das gehört zur Ehrlichkeit dazu: Das Dokument stellt selbst klar, dass die Mindestelemente keine neuen Pflichten begründen, sondern präzisieren, wie SBOMs erzeugt und angefordert werden sollen — und dass es keine Compliance- oder Rechtsberatung darstellt. Es ist eine international abgestimmte Spezifikation, belastbar als Referenz in Verträgen und Ausschreibungen, nicht als Rechtsgrundlage.

Und die deutsche Sicht: die TR-03183-Reihe

Für den europäischen Kontext bleibt die Technische Richtlinie BSI TR-03183 die konkretere Orientierung. Sie umfasst inzwischen vier Teile:

Teil 1 ist die jüngste Ergänzung: Das BSI hat ihn am 5. August 2026 in Version 1.0.0 bekanntgegeben, das Dokument selbst trägt den 31. Juli 2026 und wird als Living Document geführt. Er bündelt die Anforderungen aus Artikeln und Anhängen des CRA und bietet einen strukturierten Ansatz zur risikobasierten Auswahl von Cybersicherheitsmaßnahmen. Das BSI ordnet ihn ausdrücklich als Orientierung für die Klasse der Standardprodukte des CRA ein — also für den Regelfall unterhalb der wichtigen und kritischen Produktkategorien. Hersteller sollen auf Basis ihrer eigenen Risikoanalyse ableiten, welche Maßnahmen für ein angemessenes Sicherheitsniveau erforderlich sind.

Praktisch interessant ist die Beigabe: Eine initiale Auswahl von Cybersicherheitsmaßnahmen stellt das BSI im maschinenlesbaren Format OSCAL bereit. Wer Maßnahmenkataloge ohnehin werkzeuggestützt verwaltet, kann sie direkt einlesen, statt sie aus einem PDF abzutippen.

Teil H verdient besondere Aufmerksamkeit, weil er in der Diskussion fast durchgängig übersehen wird. Das BSI beschreibt darin, wie sich das Konformitätsbewertungsverfahren „Modul H” über ein ISO/IEC-27001-konformes Informationssicherheits-Managementsystem realisieren lässt — einschließlich IT-Grundschutz. Hersteller können also bestehende Cybersicherheitsprozesse auf Produktentwicklung und Schwachstellenbehandlung ausweiten, statt ein separates Verfahren aufzubauen. Wer ein funktionierendes ISMS betreibt und Produkte in Verkehr bringt, sollte diesen Weg prüfen, bevor er andere Konformitätspfade kalkuliert.

Teil 2 (v2.1.0 vom 20.08.2025) übersetzt die CRA-Anforderungen an die SBOM in prüfbare technische Vorgaben. Konkret verlangt die Richtlinie:

• CycloneDX mindestens in Version 1.6 (angehoben von 1.5) oder SPDX mindestens in Version 3.0.1 (angehoben von 2.2.1)
• den SHA-512-Hashwert der auslieferbaren Komponente — also der Komponente in der Form, in der sie als Datei auf einem Datenträger vorliegt; der Hashwert des Quellcodes ist als optionales Feld vorgesehen
• eine Reihe verpflichtender Datenfelder einschließlich tatsächlichem Dateinamen sowie Kennzeichnung ausführbarer, archivierter und strukturierter Komponenten

Version 2.1.0 ergänzte zudem eine Zuordnungsempfehlung zwischen den Datenfeldern der Richtlinie und beiden Formaten, überarbeitete den Lizenzabschnitt und führte logische sowie identifizierte Komponenten ein. Ergänzend hat das BSI eine eigene, bei CycloneDX registrierte Property-Taxonomie veröffentlicht, die die Erstellung Teil-2-konformer SBOMs erleichtert.

Die Vorgabe zu SPDX hat eine unterschätzte Konsequenz: Die als ISO/IEC 5962 normierte SPDX-Fassung 2.2.1 genügt der TR-03183-2 nicht mehr. Wer sich in Verträgen auf „SPDX nach ISO/IEC 5962” beruft, formuliert damit unterhalb des BSI-Mindeststandards. Und SPDX 3.0.1 ist jung genug, dass die Werkzeugunterstützung in der Breite noch nicht überall trägt — ein Punkt, den Sie in Ausschreibungen realistisch einplanen sollten.

Teil 3 ist der oft übersehene Zwilling der SBOM: Ohne funktionierenden Umgang mit eingehenden Schwachstellenmeldungen bleibt die Komponententransparenz folgenlos. Wer sich auf die CRA-Meldepflichten ab September 2026 vorbereitet, braucht beide Teile.

Das BSI stellt für die gesamte Reihe klar: Sie ist eine Hilfestellung ohne verpflichtenden Charakter, kann nicht für eine Konformitätsvermutung genutzt werden und wird durch die korrespondierenden harmonisierten europäischen Normen ersetzt, sobald diese vorliegen. Als Zielgruppe nennt das BSI ausdrücklich Hersteller ohne ausgereifte IT-Sicherheitsprozesse — die TR ist also als Einstiegshilfe gedacht, nicht als Obergrenze.

Die beiden Referenzwerke stehen nicht im Widerspruch — die internationale Fassung von 2026 verweist ausdrücklich auf die TR-03183-2 wie auch auf den CRA. Bemerkenswert ist die Bewegungsrichtung: Beim Thema Hashwerte und Formatversionen war das BSI voraus, während der neue Rahmen bei Coverage, Lizenzangaben, Generierungskontext und Dokumentversionierung über den bisherigen Stand hinausgeht. Teil 2 stammt vom August 2025 und ist damit knapp ein Jahr älter als die neue Baseline; ob und wann eine angepasste Fassung folgt, ist offen. Dass Teil 1 Ende Juli 2026 als Living Document in Version 1.0.0 herausgegeben wurde — zwei Tage nach der neuen Baseline —, zeigt immerhin, dass die Reihe aktiv gepflegt wird und das BSI sich ein laufendes Nachziehen ausdrücklich vorbehält. Wer heute Anforderungen formuliert, sollte pragmatisch die Vereinigungsmenge beider Werke verlangen und die Klausel versionsoffen halten.

SBOM-Typen: der am häufigsten übersehene Punkt

Eine SBOM ist nicht gleich eine SBOM. Die CISA unterscheidet sechs Typen nach Entstehungszeitpunkt, und dieser Unterschied entscheidet über den praktischen Wert:

Wenn ein Lieferant Ihnen eine SBOM zusagt, ist die Rückfrage nach dem Typ die erste sinnvolle Qualitätsprüfung. Eine „Analyzed SBOM”, die jemand nachträglich über ein Container-Image hat laufen lassen, ist etwas fundamental anderes als ein signiertes Build-Artefakt aus der Pipeline.

Diese Rückfrage können Sie sich seit Juli 2026 teilweise sparen: Das neue Pflichtfeld SBOM Generation Context verlangt genau diese Angabe im Dokument selbst. Damit wird aus einer Vertrauensfrage ein prüfbares Datenfeld — vorausgesetzt, Ihr Lieferant füllt es korrekt.

Was eine SBOM ausdrücklich nicht ist

Hier entstehen die meisten Missverständnisse:

• Kein Schwachstellenbericht. Die TR-03183 hält Schwachstelleninformationen bewusst aus der SBOM heraus. Die SBOM sagt, was drin ist; die Verknüpfung mit CVE-Daten passiert nachgelagert.
• Keine Aussage zur Ausnutzbarkeit. Dafür gibt es VEX (Vulnerability Exploitability eXchange), in Europa üblicherweise als CSAF-2.0-Profil. Eine verwundbare Bibliothek, die in einem Codepfad liegt, der nie erreicht wird, ist ein anderes Risiko als eine im Request-Handler.
• Kein Ersatz für Asset-Management. Die SBOM beschreibt ein Produkt. Sie sagt nichts darüber, auf wie vielen Ihrer Systeme dieses Produkt in welcher Version läuft.
• Kein Sicherheitsgewinn an sich. Eine SBOM, die niemand einliest und gegen nichts abgleicht, ist ein PDF im SharePoint. Dazu später mehr.

2. Der regulatorische Dreiklang

2.1 Cyber Resilience Act: ausdrücklich, aber später als gedacht

Der CRA (Verordnung (EU) 2024/2847) ist das einzige der drei Regelwerke, das die SBOM beim Namen nennt. Anhang I Teil II Nr. 1 verpflichtet Hersteller, die im Produkt enthaltenen Komponenten zu identifizieren und zu dokumentieren, einschließlich einer SBOM in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene erfasst. Die SBOM wird damit Teil der technischen Dokumentation nach Anhang VII und ist Voraussetzung für die CE-Kennzeichnung.

Der Zeitplan, Stand August 2026:

Marktaufsichtsbehörde in Deutschland ist das BSI.

Drei Punkte, die regelmäßig falsch verstanden werden:

Erstens: „Mindestens Top-Level” ist ein Minimum, kein Ziel. Wer die Meldepflicht ab September 2026 erfüllen will, muss innerhalb von 24 Stunden wissen, ob eine aktiv ausgenutzte Schwachstelle das eigene Produkt betrifft. Bei transitiven Abhängigkeiten in Tiefe 4 hilft eine Top-Level-Liste dabei nicht. Die Meldepflicht ist der eigentliche Treiber, nicht das CE-Zeichen.

Hier klafft inzwischen eine sichtbare Lücke zwischen Regulierung und Fachstand: Der CRA-Verordnungstext lässt die oberste Ebene genügen, die internationale Baseline von Juli 2026 hat genau diese Beschränkung gestrichen. Rechtlich reicht Top-Level bis auf Weiteres; fachlich ist es seit Ende Juli 2026 unterhalb des anerkannten Standes der Technik. Für Auditierung und Vertragsgestaltung ist das ein relevanter Unterschied — Sorgfaltsmaßstäbe orientieren sich nicht nur am Mindesttext.

Zweitens: Der CRA verpflichtet nicht zur Herausgabe der SBOM an Kunden. Die SBOM ist Bestandteil der technischen Dokumentation und der Marktüberwachungsbehörde auf begründetes Verlangen vorzulegen. Eine Veröffentlichungspflicht — oder auch nur eine Pflicht zur Weitergabe an Abnehmer — enthält der CRA ausdrücklich nicht. Wenn Sie als Kunde eine SBOM haben wollen, brauchen Sie einen Vertrag, kein Gesetz.

Drittens: Der Anwendungsbereich ist breiter, als viele annehmen. „Produkte mit digitalen Elementen” umfasst Hard- und Software einschließlich zugekaufter Komponenten. Für Versorger relevant: Smart-Meter-Gateways sind in Anhang IV als kritische Produkte gelistet, mit entsprechend verschärftem Konformitätsbewertungsverfahren. Fernwirktechnik, Leitsystemkomponenten, Gateways und Sensorik fallen in aller Regel unter den allgemeinen CRA-Rahmen.

Die Kommission kann per delegiertem Rechtsakt Format und Elemente der SBOM näher bestimmen. Bis dahin — und bis die harmonisierten Normen vorliegen — sind BSI TR-03183 und die etablierten Formatstandards die belastbarste Orientierung.

2.2 NIS2 / BSIG: kein Wort von SBOM, und trotzdem mittendrin

Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz ist am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten. Die gesetzliche Registrierungsfrist nach § 33 BSIG lief am 6. März 2026 ab; das BSI hat den Unternehmen faktisch eine Nachfrist bis zum 31. Juli 2026 eingeräumt — eine Vollzugskulanz, keine neue Rechtslage. Von rund 29.500 betroffenen Einrichtungen waren bis Ende Mai 2026 etwa 18.500 registriert.

Das Wort „SBOM” kommt im BSIG nicht vor. Relevant ist § 30 BSIG, der zehn Bereiche von Risikomanagementmaßnahmen vorgibt — darunter ausdrücklich die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern sowie Verfahren zum Umgang mit Schwachstellen.

Damit ist die SBOM unter NIS2 nicht Pflicht, sondern Nachweismittel. Und zwar an zwei Stellen:

1. Nach außen, gegenüber Lieferanten. § 30 verlangt, Lieferantenrisiken zu steuern. Ohne Komponententransparenz steuern Sie ein Risiko, das Sie nicht kennen.
2. Nach innen, gegenüber Prüfern. Besonders wichtige Einrichtungen müssen die Umsetzung nachweisen. „Wir vertrauen unseren Lieferanten” ist keine Maßnahme, sondern deren Abwesenheit.

Der entscheidende Hebel: NIS2-Einrichtungen sind fast immer Abnehmer. Ihre Anforderungen wandern über Beschaffung und Verträge in die Lieferkette — und treffen dort auf Hersteller, die ab 2027 ohnehin CRA-konform sein müssen. Genau hier verzahnen sich die beiden Regelwerke: nicht im Gesetzestext, sondern im Vertrag.

Zur Einordnung der weiteren Entwicklung: Auf EU-Ebene laufen seit Anfang 2026 Diskussionen über Anpassungen des Cybersicherheitsrahmens, unter anderem zu Schwellenwerten und Meldewegen. Wer strukturell plant, sollte das beobachten — als Grund zum Abwarten taugt es nicht, da die Kernpflichten seit Dezember 2025 unmittelbar gelten.

2.3 DORA: das Bauteil ohne Namen

DORA (Verordnung (EU) 2022/2554) gilt seit dem 17. Januar 2025 und nennt die SBOM ebenfalls nicht. Was DORA verlangt, läuft aber auf dasselbe hinaus:

• Art. 8 — Identifizierung, Klassifizierung und Dokumentation aller IKT-Assets, einschließlich der Konfigurationen, Verknüpfungen und Interdependenzen sowie der Abhängigkeiten von Dritten.
• Art. 9/10 — Schutz-, Präventions- und Erkennungsmechanismen, einschließlich der Ermittlung potenzieller wesentlicher Schwachstellen.
• Art. 28–30 — Management des IKT-Drittparteienrisikos, Informationsregister, vertragliche Mindestinhalte.

Die technischen Regulierungsstandards zum IKT-Risikomanagementrahmen (Delegierte Verordnung (EU) 2024/1774) konkretisieren das weiter, unter anderem mit der Anforderung, Bibliotheken Dritter einschließlich Open-Source-Bibliotheken fortlaufend zu identifizieren und nachzuverfolgen. Das ist eine SBOM-Anforderung in allem außer dem Namen.

Die eigentliche DORA-Besonderheit ist die Vierte-Partei-Perspektive: Über die RTS zur Unterauftragsvergabe reicht die Nachweiskette über den direkten Dienstleister hinaus in dessen Zulieferstruktur. Wenn eine kritische oder wichtige Funktion auf einer SaaS-Plattform ruht, die ihrerseits auf einem Hyperscaler und einem halben Dutzend Managed Services aufsetzt, ist die Frage „welche Komponenten tragen diesen Dienst?” nicht mehr akademisch.

2.4 Ein Artefakt, drei Funktionen

Wer ISO 27001 betreibt, findet die Anknüpfungspunkte in Anhang A ohne Umwege: A.5.19–A.5.23 (Lieferantenbeziehungen, Cloud-Dienste), A.8.8 (Management technischer Schwachstellen), A.8.9 (Konfigurationsmanagement), A.8.28 (sicheres Codieren), A.8.30 (ausgelagerte Entwicklung). Ein sauber implementiertes ISMS liefert die Prozesshülle, in die SBOM-Verfahren hineinpassen — sofern die Erklärung zur Anwendbarkeit das Lieferkettenrisiko tatsächlich im Geltungsbereich hat.

3. Perspektive A: Sie kaufen Software ein

Dies ist der Fall mit dem besten Aufwand-Nutzen-Verhältnis — und dem, in dem am meisten falsch gemacht wird.

Der Kardinalfehler

Der häufigste Fehler ist nicht, keine SBOM zu fordern. Es ist, eine zu fordern, ohne einen Ort zu haben, an dem sie ankommt. Ich sehe regelmäßig Beschaffungsunterlagen mit der Klausel „Der Auftragnehmer stellt eine SBOM zur Verfügung” — und keinerlei Prozess dahinter. Das Ergebnis ist ein JSON-Dokument in einem Vertragsordner, das niemand je wieder öffnet. Compliance-Theater mit zusätzlichem Lieferantenärger.

Regel: Erst der Eingangsprozess, dann die Klausel. Konkret heißt das ein Werkzeug, das SBOMs einliest, gegen Schwachstellendatenbanken abgleicht und bei neuen CVEs Alarm schlägt. OWASP Dependency-Track ist dafür der pragmatische Einstieg — quelloffen, auf einer mittleren VM lauffähig, in einem Tag aufgesetzt.

Was in den Vertrag gehört

Formulieren Sie prüfbar, nicht wohlklingend:

• Referenzdokument: Verweisen Sie auf die 2026 Minimum Elements for a SBOM (CISA et al.) und die BSI TR-03183-2 in der jeweils aktuellen Fassung. Der Verweis auf die NTIA-Elemente von 2021 gehört aus Vorlagen und Sicherheitsanlagen gestrichen — er ist überholt.
• Format und Version: CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 entsprechend TR-03183-2, maschinenlesbar (JSON), nicht als PDF-Anhang. SWID-Tags sind kein gleichwertiger Ersatz. Achtung: „SPDX nach ISO/IEC 5962” bezeichnet Version 2.2.1 und liegt damit unterhalb der BSI-Vorgabe.
• Coverage statt Tiefe: alle Komponenten der gelieferten Software einschließlich transitiver Abhängigkeiten, ohne Mindesttiefe. Wenn der Lieferant über verlinkte Teil-SBOMs arbeitet: Zugriff auf sämtliche verlinkten Dokumente ausdrücklich zusichern lassen. Ohne diesen Halbsatz ist die Verlinkung ein Etikettenschwindel.
• Identifikatoren: mindestens ein gängiger Software-Identifier je Komponente, PURL (ECMA-427) und/oder CPE — ohne die ist ein automatisierter CVE-Abgleich nicht möglich. Liegen mehrere vor, sind alle anzugeben.
• Hashwert und Hash-Algorithmus je Komponente: neues Pflichtfeld der 2026-Baseline; Algorithmus nach IANA-Bezeichnung und von einer anerkannten Stelle freigegeben. Die TR-03183-2 konkretisiert das auf SHA-512 für die auslieferbare Komponente — nehmen Sie diesen Wert ausdrücklich in die Klausel auf.
• Lizenzangabe je Komponente, wo möglich als SPDX-Identifier, einschließlich Hinweis auf proprietäre Lizenzbedingungen.
• Erzeugendes Werkzeug (Name und Version), Formatname und -version, Generierungskontext und SBOM-Version im Dokument benannt.
• Signatur des SBOM-Autors (z. B. Cosign/Sigstore oder Notation), damit Sie beim Eingang prüfen können, dass Sie das unveränderte Original haben.
• Abhängigkeitsbeziehungen: ausdrücklich gefordert. Viele Generatoren liefern eine flache Komponentenliste und lassen die Struktur weg.
• Umgang mit Lücken: Fehlende Angaben sind als unbekannt oder als zurückgehalten zu kennzeichnen — die Unterscheidung ist zu treffen, stillschweigendes Weglassen gilt vertraglich als Mangel. Ergänzend: ein benannter Weg, über den Sie zu geschwärzten sicherheitsrelevanten Angaben nachfragen können. Diese Klausel ist unterschätzt; sie unterscheidet eine ehrliche von einer geschönten SBOM.
• Aktualisierung: je Version oder Update, auch bei Neubauten mit aktualisierten Abhängigkeiten. Zusätzlich Korrekturlieferung, wenn der Lieferant Fehler entdeckt oder neue Erkenntnisse über Komponenten gewinnt.
• Lieferweg: definierter Kanal (versionsspezifische URL, API, Repository), nicht E-Mail-Anhang an eine Person.
• Schwachstellenkommunikation: Advisories im CSAF-2.0-Format, benannte Kontaktstelle, Reaktionszeiten nach Schweregrad.
• Unterstützungszeitraum: Der CRA verlangt einen Zeitraum, der der erwarteten Produktlebensdauer entspricht, grundsätzlich mindestens fünf Jahre. Prüfen Sie, ob das zu Ihrem Abschreibungshorizont passt — bei Leittechnik und Sekundärtechnik tut es das oft nicht.
• Umgang mit Unvollständigkeit: Was passiert, wenn die SBOM lückenhaft ist? Nachbesserungsfrist, Mängelrechte.

Und wenn der Lieferant nein sagt?

Bis Dezember 2027 haben Sie in der Regel keinen gesetzlichen Anspruch, sondern nur Marktmacht. Nutzen Sie sie, wo sie da ist — und akzeptieren Sie, wo sie es nicht ist. Bei einem Nischenanbieter für Fernwirktechnik mit drei Wettbewerbern weltweit ist die realistische Verhandlungsposition eine andere als bei Standardsoftware.

Fallback-Optionen, wenn keine SBOM zu bekommen ist: schriftliche Auskunft zu den eingesetzten Kernkomponenten und deren Versionsständen, Zusage zur proaktiven Information bei Betroffenheit von kritischen CVEs, ein Passus zur Nachlieferung ab CRA-Geltung. Dokumentieren Sie die Ablehnung — das ist im Audit mehr wert als eine Lücke ohne Begründung.

Eingangsqualität prüfen

Nicht jede gelieferte SBOM ist brauchbar. Ein Kurz-Check, der sich automatisieren lässt:

1. Gültig gegen das Format-Schema? Formatname und -version im Dokument deklariert, Version nicht abgekündigt?
2. Mindestfelder nach der 2026-Baseline vollständig — insbesondere Hashwert und Hash-Algorithmus, Lizenz, erzeugendes Werkzeug samt Version, Generierungskontext, SBOM-Version?
3. Anteil der Komponenten mit PURL oder CPE — unter 90 % wird der Abgleich unzuverlässig
4. Sind Abhängigkeitsbeziehungen vorhanden oder nur eine flache Liste? Falls mit verlinkten Teil-SBOMs gearbeitet wird: sind alle verlinkten Dokumente für Sie erreichbar?
5. Plausible Komponentenzahl? Eine Java-Enterprise-Anwendung mit 12 Einträgen ist keine vollständige SBOM.
6. Zeitstempel (RFC 9557) und SBOM Author gesetzt, Version passend zum gelieferten Release?
7. Signatur vorhanden und verifizierbar?
8. Sind Lücken als solche gekennzeichnet — und wenn ja, als unbekannt oder als zurückgehalten? Der Unterschied ist erheblich: Unbekannt heißt, Ihr Lieferant weiß es selbst nicht. Zurückgehalten heißt, er weiß es und sagt es nicht. Nur im zweiten Fall gibt es jemanden, den Sie fragen können.

Werkzeuge: sbomqs für Qualitäts-Scoring, ntia-conformance-checker für die Mindestfelder. Kalkulieren Sie ein, dass die Prüfwerkzeuge der neuen Baseline noch hinterherlaufen — die Umstellung ist wenige Wochen alt. Bis die Checker nachgezogen haben, sind die neuen Felder manuell oder per eigenem Skript zu prüfen.

4. Perspektive B: Sie nutzen SaaS

Der unbequemste Fall. Hier kollidiert der SBOM-Gedanke mit der Realität des Betriebsmodells.

Die Abgrenzung, die Sie kennen sollten

Reines SaaS ist kein Produkt mit digitalen Elementen im Sinne des CRA. Der CRA erfasst Fernverarbeitungslösungen nur, soweit sie integraler Bestandteil eines Produkts sind — das Cloud-Backend, ohne das der Sensor nicht funktioniert. Eine eigenständige Softwaredienstleistung fällt stattdessen unter NIS2, wo der Anbieter als digitale Infrastruktur oder Managed Service selbst reguliert sein kann.

Genau hier hat sich die Lage im Juli 2026 verschoben — aber weniger eindeutig, als es zunächst klingt. Die neuen Mindestelemente gelten ausdrücklich auch für SaaS. Zugleich widmet das Dokument dem Fall einen eigenen Diskussionsabschnitt und räumt dort mehr Probleme ein, als es löst: Die geteilte Verantwortung zwischen SaaS-Anbieter und -Betreiber erschwert die Übertragung des Modells aus der On-Premises-Welt und begrenzt einzelne Anwendungsfälle. Die hohe Änderungsfrequenz moderner Cloud-Software kann beide Seiten überfordern, wenn SBOMs entsprechend häufig geliefert werden sollen. Und die Lieferfrequenz für SaaS bedarf nach eigener Einschätzung der Autoren weiterer Spezifikation. Als pragmatischer Weg wird die Auslieferung per API mit Momentaufnahmen aus der CI/CD-Kette genannt.

Regulatorisch ändert das nichts — die Baseline ist keine Rechtsnorm und der CRA-Anwendungsbereich bleibt, wie er ist. Was sich ändert, ist die Verhandlungsposition: Die Antwort „für SaaS gibt es keine SBOM-Erwartung” ist seit Ende Juli nicht mehr haltbar. Es existiert eine international mitgetragene Spezifikation, die den Fall abdeckt, und auf die können Sie sich in Ausschreibungen berufen.

Zugleich bleibt die praktische Einschränkung bestehen, und sie ist erheblich: Selbst wenn Sie wüssten, dass in Version 4.2 der Plattform eine verwundbare Bibliothek steckt — patchen können Sie nicht. Sie haben keinen Zugriff auf das Deployment, und morgen ist es ohnehin Version 4.3. Eine SaaS-SBOM ist eine Momentaufnahme eines Systems, das sich Ihrer Kontrolle vollständig entzieht.

Die vernünftige Schlussfolgerung ist deshalb nicht „SBOM fordern” oder „SBOM vergessen”, sondern eine Priorisierung: Fordern Sie die SBOM, wo der Dienst eine kritische oder wichtige Funktion trägt und Sie ein Interesse an Vierte-Partei-Transparenz haben — und regeln Sie dann Lieferfrequenz und Zustellweg explizit, weil genau das die offene Stelle ist. Verzichten Sie darauf beim Ticketsystem der Poststelle. Und machen Sie in keinem Fall die SBOM zum Hauptkriterium; die folgenden Punkte sind wichtiger.

Die richtige Frage verschiebt sich

Bei On-Premises lautet die Frage „Was ist drin, und wann patchen wir?”. Bei SaaS lautet sie: „Wie schnell reparieren Sie, und wie erfahre ich davon?” Der Nachweis verlagert sich vom Artefakt auf den Prozess.

Was Sie stattdessen verlangen sollten und realistisch bekommen können:

• Schwachstellen-SLAs mit Zahlen. Nicht „zeitnah”, sondern: kritisch ≤ 72 h, hoch ≤ 14 Tage, gemessen ab Verfügbarkeit des Fixes. Mit Reporting über die Einhaltung.
• Verpflichtung zur proaktiven Betroffenheitsmeldung bei branchenweit relevanten Schwachstellen — auch dann, wenn der Anbieter nicht betroffen ist. Genau diese Negativauskunft ist im Ernstfall Gold wert und ersetzt Ihre eigene Recherche.
• Subunternehmerliste mit Änderungsanzeige. Unter DORA über die RTS zur Unterauftragsvergabe ohnehin Pflicht, unter Art. 28 DSGVO für Auftragsverarbeiter etabliert, unter NIS2 über § 30 begründbar. Wer nicht sagt, auf wem er aufsetzt, ist keine belastbare Grundlage für eine kritische Funktion.
• Zertifikate mit gelesenem Geltungsbereich. Ein ISO-27001-Zertifikat, dessen Scope die betriebene Plattform nicht abdeckt, ist eine Urkunde, kein Nachweis. Lesen Sie die Anlage zum Zertifikat, nicht das Zertifikat.
• Zusammenfassungen von Penetrationstests und Aussagen zum sicheren Entwicklungslebenszyklus.
• Statuskommunikation im Vorfall: Wo steht die Statusseite, wer wird wie schnell informiert, gibt es eine Eskalationsstufe für Sie als Kunden.
• Exit-Strategie und Datenrückgabe — unter DORA Art. 28 ohnehin verpflichtender Vertragsinhalt, unter NIS2 aus dem Kontinuitätsgedanken abzuleiten.

Wenn ein SaaS-Anbieter eine SBOM anbietet, oft unter NDA und für die vom Kunden genutzten Komponenten: nehmen Sie sie. Aber messen Sie den Anbieter nicht daran, ob er sie liefert, sondern an den sieben Punkten oben. Bei SaaS ist die SBOM ein Indikator für die Reife des Anbieters — nicht Ihr Steuerungsinstrument.

5. Perspektive C: Sie entwickeln selbst

Erst die Rollenfrage klären

Bevor Sie ein Werkzeug auswählen, klären Sie den Status. Der Unterschied ist erheblich:

Sie entwickeln ausschließlich für den Eigenbedarf — interne Fachanwendung, Auswertungsplattform, Automatisierungsskripte im Netzleitbereich. Dann liegt kein Inverkehrbringen vor, der CRA greift nicht. NIS2, DORA und Ihr ISMS greifen sehr wohl: Es ist Ihre Software, in Ihrem Asset-Inventar, mit Ihrem Schwachstellenrisiko.

Sie geben Software weiter — als Produkt, als Bestandteil einer Anlage, als Firmware, als Software auf einem Gerät, auch unentgeltlich im Rahmen einer geschäftlichen Tätigkeit. Dann sind Sie ab Dezember 2027 Hersteller im Sinne des CRA, mit allem, was dazugehört. Das trifft mehr Organisationen, als sich selbst so einordnen: Wer eine Open-Source-Komponente unter eigenem Namen weitergibt oder ein Gerät mit eigener Firmware verkauft, ist Hersteller.

Ein Sonderfall, der Versorger betrifft: Wenn Sie im Rahmen von Dienstleistungen Software an Dritte ausliefern — etwa an Kommunen oder Verbundpartner — lohnt eine saubere juristische Einordnung. Die Grenze zwischen Dienstleistung und Inverkehrbringen verläuft nicht dort, wo das Bauchgefühl sie vermutet.

Die Toolkette

Der technische Teil ist der einfachste. In der Pipeline:

1. Erzeugung je Build: syft (breit, sprachübergreifend, gut für Container), cdxgen (viele Ökosysteme, CycloneDX-nativ), trivy (SBOM plus Scan in einem), oder sprachnative Generatoren.
2. Anreicherung: PURL-Vollständigkeit sicherstellen, Lizenzangaben normalisieren, Hashes ergänzen.
3. Signatur: cosign / Sigstore. Eine unsignierte SBOM ist eine Behauptung.
4. Ablage: je Release, unveränderlich, versioniert. Nicht überschreiben — die SBOM zu Version 3.1.4 muss in zwei Jahren noch auffindbar sein.
5. Monitoring: OWASP Dependency-Track als Sammelstelle. Alle SBOMs — eigene und die Ihrer Lieferanten — landen hier und werden fortlaufend gegen neue CVEs geprüft.
6. Advisory-Pipeline: CSAF-2.0-Dokumente für Ihre eigenen Produkte, Editor Secvisogram, Veröffentlichung über security.txt mit CSAF:-Eintrag. Für den Umgang mit eingehenden Meldungen ist TR-03183 Teil 3 die passende Vorlage. Ab September 2026 brauchen Sie ohnehin einen funktionierenden Meldeweg.

Das ist in einer Woche eingerichtet. Die Schwierigkeit liegt woanders.

Wo es wirklich hakt

Der Mengeneffekt. Ein Container-Image auf Basis eines vollen Betriebssystem-Images liefert schnell 500 bis 1.500 Komponenten, davon der Großteil aus Systempaketen, die Sie nie anfassen. Ihr erster Scan wird Ihnen dreistellig viele „kritische” Findings anzeigen. Wer darauf mit Panik reagiert, verliert das Team; wer mit Ignorieren reagiert, verliert den Zweck. Der Ausweg ist zweistufig: minimale Basis-Images (Distroless, Alpine, chainguard-artig) und ein VEX-Prozess, der begründet dokumentiert, warum eine Komponente nicht ausnutzbar ist.

Die blinden Flecken. Statisch gelinkte Binaries, einkopierter Fremdcode („vendoring”), heruntergeladene JAR-Dateien ohne Paketmanager, Firmware-Blobs — all das taucht in einer Source-SBOM nicht auf. Wenn Ihre Build-Kette solche Elemente enthält, brauchen Sie ergänzende Binäranalyse.

Die Eigentümerfrage. Das ist die eigentliche Hürde. Wem gehört das Triage-Ergebnis? Wenn die Pipeline morgens 40 neue Findings meldet, wer entscheidet innerhalb welcher Frist über Relevanz und Behebung? Ohne benannte Rolle, definierte Fristen je Schweregrad und eine Eskalation für Überfälliges entsteht ein System, das Arbeit produziert und Risiko nicht reduziert.

Ein kleines Reifegradmodell

Stufe 2 ist für die meisten Mittelständler das richtige Ziel für die nächsten zwölf Monate. Stufe 3 brauchen Sie, wenn Sie CRA-Hersteller sind oder Finanzunternehmen beliefern.

6. Der ehrliche Teil: Wo die SBOM (noch) nicht liefert

Ein Beitrag, der hier aufhört, verkauft eine Lösung. Diese Punkte gehören dazu:

Es gibt keinen etablierten Verteilungsweg. Die TR-03183 beschreibt, wie eine SBOM aussehen muss, nicht wo sie liegt. In der Praxis: E-Mail-Anhänge, Kundenportale mit Einzellogin, gelegentlich ein API-Endpunkt. Für einen Betreiber mit 80 Softwarelieferanten ist das ein Beschaffungsproblem, kein Sicherheitsproblem — aber eines, das den Nutzen deutlich schmälert.

Die Qualität ist heterogen. Viele automatisch erzeugte SBOMs verlieren die Abhängigkeitsstruktur oder liefern Komponenten ohne saubere Identifikatoren. Beides macht den automatisierten Abgleich unzuverlässig — und ein unzuverlässiger Abgleich ist schlimmer als keiner, weil er falsche Sicherheit erzeugt.

Transparenz ohne Triage-Kapazität ist Lärm. Die SBOM erzeugt Sichtbarkeit. Sichtbarkeit erzeugt Arbeit. Wenn Sie 40.000 Komponenten über Ihr Portfolio sehen, aber keine halbe Personalstelle für die Bewertung haben, haben Sie ein neues Risiko geschaffen: dokumentierte, unbearbeitete Kenntnis. Im Schadensfall ist das juristisch ungünstiger als Unwissenheit.

VEX ist die Antwort und noch nicht verbreitet. Ohne Ausnutzbarkeitsinformation bleibt die Priorisierung Schätzung. Die Verbreitung nimmt zu, ist aber weit von flächendeckend entfernt — und VEX-Aussagen sind nur so belastbar wie der Hersteller, der sie ausstellt.

KI-Komponenten sind angefasst, aber nicht gelöst. Die 2026-Baseline bezieht KI-Software ausdrücklich in ihren Geltungsbereich ein — mit der Begründung, dass KI auch nur Software ist und die Standardfelder viele relevante Komponenten sichtbar machen. KI-spezifische Felder wurden bewusst nicht aufgenommen. Für das, was Fachleute unter „model cards” und „data cards” diskutieren, verweist das Dokument auf die gemeinsame Leitlinie „Software Bill of Materials (SBOM) for Artificial Intelligence – Minimum Elements”, die CISA und die G7-Partner — darunter Deutschland und die EU — im Mai 2026 veröffentlicht haben (wir haben sie im Frühjahr eingeordnet). Praktisch heißt das: Ihr Standard-SBOM-Prozess erfasst Inferenz-Bibliotheken und Frameworks, aber nicht das Modell selbst. Wer KI-Komponenten in Produkte integriert, braucht dafür einen zweiten, separaten Nachweispfad.

Signatur ist nicht Richtigkeit. Das neue Feld für die Autorensignatur beantwortet genau eine Frage: Haben Sie das Dokument so erhalten, wie der Autor es erstellt hat? Über Genauigkeit, Abdeckung und Vollständigkeit sagt es nichts — das Dokument grenzt diese Eigenschaften ausdrücklich aus dem eigenen Anwendungsbereich aus und verweist auf Binäranalyse und Repository-Abgleiche, um nicht gelistete Komponenten aufzuspüren. Eine signierte SBOM ist also eine überprüfbar echte Behauptung, keine überprüfte Behauptung. Der Unterschied ist im Audit erheblich.

Die Normung hinkt — und läuft inzwischen mehrgleisig. Die harmonisierten CEN/CENELEC-Normen zum CRA liegen in wesentlichen Teilen noch nicht vor; die horizontale Norm zu den technischen Anforderungen ist erst kurz vor Geltungsbeginn terminiert. Gleichzeitig existieren mit dem CRA-Text, der BSI TR-03183-2 und der internationalen 2026-Baseline drei Referenzpunkte, die sich in Details unterscheiden und nicht synchron fortgeschrieben werden. Wer heute baut, baut gegen bewegliche Ziele. Praktischer Umgang: die Vereinigungsmenge als internen Standard setzen, Vertragsklauseln versionsoffen formulieren und IEC 62443 als Brücke nutzen, die einen erheblichen Teil der produktbezogenen CRA-Anforderungen abdeckt.

Und der grundsätzlichste Einwand: Aus der Fachöffentlichkeit kam auf die neuen Minimum Elements die nüchterne Reaktion, dass verfeinerte Spezifikationen wenig bewirken, solange die Nachfrage fehlt. Die meisten Kunden fordern keine SBOM; viele, die eine bekommen, nutzen sie nicht; und die CISA selbst schafft ausdrücklich keine Verpflichtung. Ohne Käuferdruck oder Regulierung ändert eine bessere Spezifikation das Verhalten des Ökosystems nicht. Das ist der eigentliche Grund, warum der CRA — bei allen Schwächen im Detail — der entscheidende Hebel bleibt: Er erzeugt die Pflicht, die die Spezifikation allein nicht erzeugen kann.

7. Was ein Auditor fragt

Zur Vorbereitung, unabhängig vom Regelwerk:

1. Liegt das Lieferkettenrisiko im Geltungsbereich Ihres ISMS, und steht es in der Erklärung zur Anwendbarkeit?
2. Zeigen Sie mir für ein beliebiges Release aus den letzten sechs Monaten die zugehörige SBOM.
3. Welche Ihrer Lieferanten liefern SBOMs, welche nicht, und was haben Sie bei den anderen stattdessen vereinbart?
4. Auf welche Fassung der Mindestanforderungen verweisen Ihre Vertragsvorlagen — und wann haben Sie sie zuletzt geprüft?
5. Was ist passiert, als zuletzt eine kritische Schwachstelle in einer verbreiteten Bibliothek bekannt wurde? Zeigen Sie mir das Ticket.
6. Wie lange hat die Antwort auf „Sind wir betroffen?” gedauert, und wie haben Sie sie ermittelt?
7. Wer entscheidet über die Behebung, in welcher Frist, und was passiert bei Überschreitung?
8. Wie unterscheidet sich Ihr Vorgehen bei Software, die Sie betreiben, von der, die Sie ausliefern?

Frage 6 ist die aussagekräftigste. Sie lässt sich nicht mit einem Dokument beantworten.

8. Fazit

Die SBOM ist keine Sicherheitsmaßnahme. Sie ist eine Inventarpflicht — und sie hat denselben Charakter wie das Anlagenverzeichnis oder das Verarbeitungsverzeichnis: Für sich genommen schützt sie vor nichts. Sie ist die Voraussetzung dafür, dass alles andere überhaupt funktionieren kann.

Die drei Regelwerke greifen dabei ineinander, ohne aufeinander abgestimmt zu sein. Der CRA erzeugt das Artefakt beim Hersteller. NIS2 und DORA erzeugen die Nachfrage beim Abnehmer. Zusammen ergibt sich ein Markt, in dem die Komponententransparenz vom Ausnahmefall zur Grundausstattung wird — nicht wegen der Gesetze, sondern weil Verträge es verlangen werden.

Dass die internationale Mindestanforderungs-Baseline Ende Juli 2026 nach fünf Jahren überarbeitet wurde, ist dabei ein gutes Zeichen und ein unbequemes zugleich. Gut, weil sie deutlich operativer geworden ist: Hashes, Signaturen, Generierungskontext und vollständige Coverage sind genau die Felder, die man braucht, wenn man eine SBOM tatsächlich benutzt statt sie abzulegen. Unbequem, weil jede Vertragsvorlage, jede Ausschreibungsanlage und jede Prüfcheckliste, die noch auf die Fassung von 2021 verweist, jetzt veraltet ist.

Für die Praxis folgt daraus eine unspektakuläre Prioritätenliste. Wenn Sie einkaufen: Klauseln jetzt in die Verträge, weil Laufzeiten regelmäßig über 2027 hinausreichen — und vorher einen Ort schaffen, an dem SBOMs ankommen. Wenn Sie SaaS nutzen: Hören Sie auf, SBOMs zu fordern, die Sie nicht verwerten können, und verhandeln Sie stattdessen messbare Reaktionszeiten und Subunternehmertransparenz. Wenn Sie entwickeln: Automatisieren Sie die Erzeugung in dieser Woche und klären Sie danach die Frage, wer die Ergebnisse verantwortet — die zweite ist die schwierigere.

Und wenn Sie den Reifegrad in einer einzigen Zahl ausdrücken wollen, nehmen Sie nicht die Anzahl Ihrer SBOMs. Nehmen Sie die Zeit bis zur belastbaren Antwort auf „Sind wir betroffen?”. Alles andere ist Vorbereitung darauf.

Sie sind unsicher, in welcher Rolle Sie stehen — Hersteller, Betreiber oder beides? Genau diese Abgrenzung entscheidet über den Umfang Ihrer Pflichten und ist in der Praxis selten eindeutig. Sprechen Sie mich an.