Was gehört in eine OT-SBOM? Pflicht, Normentwurf, Empfehlung

In Projektbesprechungen kommt die Frage inzwischen regelmäßig: Der Kunde verlangt eine SBOM, aber was muss darin stehen? Die Antworten reichen von einer Excel-Liste der Geräte bis zu einer CycloneDX-Datei mit allen Bibliotheken jeder Firmware. Keine der beiden Antworten lässt sich aus dem Verordnungstext ableiten.

Dieser Beitrag trennt deshalb in jedem Abschnitt, was Pflicht ist, was der Normentwurf vorsieht und was wir empfehlen. Woher die Daten für eine Anlagen-SBOM kommen, steht im Beitrag zum SBOM-Erstellen im Anlagenbau. Hier geht es nur um den Inhalt.

Was verlangt der CRA-Text von der SBOM?

Die Pflicht steht in einem einzigen Satz. Nach Anhang I Teil II Nr. 1 CRA müssen Hersteller „Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“. Art. 3 Nr. 39 definiert die Software-Stückliste als „formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten“, die in den Softwareelementen eines Produkts enthalten sind. Anwendbar ist das ab dem 11. Dezember 2027 (Art. 71 Abs. 2).

Mehr steht dort nicht. Der Text nennt kein bestimmtes Format, verlangt aber eines, das gängig und maschinenlesbar ist. Er enthält keine Feldliste, keine Pflicht zu transitiven Abhängigkeiten und keine Hashwerte. Wer im Lastenheft liest, der CRA verlange „eine SBOM nach TR-03183“, liest eine Anforderung des Kunden, nicht des Gesetzgebers.

Wer bekommt die SBOM zu sehen?

Die SBOM ist Teil der technischen Dokumentation: Anhang VII Nr. 2 Buchst. b nennt sie bei den Verfahren zur Behandlung von Schwachstellen. Vorzulegen ist sie nach Anhang VII Nr. 8 der Marktüberwachungsbehörde, und zwar auf begründetes Verlangen, soweit die Behörde sie zur Prüfung der grundlegenden Anforderungen braucht. Daneben kann die Marktüberwachung SBOMs für eine unionsweite Abhängigkeitsbewertung der ADCO anfordern (Art. 13 Abs. 25).

Gegenüber dem Kunden ist der Text ausdrücklich zurückhaltend. Erwägungsgrund 77 hält fest, dass Hersteller nicht verpflichtet sein sollten, die Software-Stückliste zu veröffentlichen. Anhang II Nr. 9 regelt nur den Fall, dass der Hersteller sie dem Nutzer zur Verfügung stellt: Dann muss die Nutzerinformation angeben, wo sie abrufbar ist. Die Forderung „SBOM mitliefern“ im Liefervertrag ist deshalb eine Vertragsfrage. Sie kann sinnvoll sein, folgt aber nicht aus dem CRA.

Gibt es einen Durchführungsrechtsakt zu Format und Feldern?

Art. 13 Abs. 24 CRA erlaubt der Kommission, Format und Elemente der SBOM per Durchführungsrechtsakt festzulegen. Ein solcher Rechtsakt wäre verbindlich. Stand Oktober 2026 ist uns kein solcher Rechtsakt bekannt; die Übersicht der Kommission zur CRA-Umsetzung (Stand 27. Juli 2026) führt ihn weder als erlassen noch als geplant.

Auch die Auslegungsdokumente der Kommission schweigen zum Inhalt. Die Kommissions-FAQ v1.4 vom 4. September 2026 erwähnen die SBOM nur bei der Sorgfaltspflicht für zugekaufte Komponenten: Die SBOM einer Komponente zu prüfen, „when available“, ist dort ein Beispiel für Due Diligence (Nr. 4.4.2). Die Leitlinien C(2026) 5252 vom 27. Juli 2026 behandeln die SBOM nicht. Beide Dokumente sind Auslegung und nicht bindend. Wie Lieferanten in dieses Raster passen, die nicht einmal maschinenlesbare Advisories liefern, beschreibt der Beitrag zu Lieferanten ohne CSAF.

Was sieht der Normentwurf prEN 40000-1-3 vor?

Konkret wird erst der Entwurf der harmonisierten Norm zur Schwachstellenbehandlung, prEN 40000-1-3 von CEN/CENELEC JTC 13, der sich in der CEN-Umfrage befindet. Abschnitt 5.2.8 verlangt für jede Software-Komponente Hersteller, Name und Version (PRE-7-RQ-02), dazu je Komponente die Abhängigkeitsbeziehung und einen eindeutigen Identifikator; CPE, PURL und SWHID nennt der Entwurf als Beispiele (PRE-7-RQ-07). Die SBOM selbst braucht ein strukturiertes maschinenlesbares Format mit SPDX und CycloneDX als Beispielen (PRE-7-RQ-04), Metadaten mit Autor, Version und Zeitstempel (PRE-7-RQ-06) und je neuem Build oder Release eine neue Fassung (PRE-7-RQ-05).

Zwei Punkte, die in Diskussionen oft als Pflicht gelten, sind im Entwurf nur risikoabhängige Zusatzanforderungen (requirement enhancements). Transitive Abhängigkeiten sind aufzunehmen, „when technically feasible“ (PRE-7-RQ-03-RE); eine Anmerkung räumt ein, dass Lieferanten die nötigen Angaben oft nicht liefern können. Den Hash einer Komponente verlangt der Entwurf nur, wenn der Lieferant ihn bereitstellt (PRE-7-RQ-07-RE). Für Hardware-Komponenten sieht Abschnitt 5.2.9 eine eigene Liste vor: Hersteller, Bezeichnung, Komponenten-Identifikator und, falls zutreffend, Firmware-Version (PRE-8-RQ-02).

Eine Pflicht ist das nicht. Eine Konformitätsvermutung entsteht erst, wenn die Fundstelle der fertigen Norm im Amtsblatt veröffentlicht ist (Art. 27 Abs. 1 CRA), und der Wortlaut kann sich bis dahin ändern. Wer sich daran orientiert, hat trotzdem den besten verfügbaren Hinweis darauf, worauf sich die Konformitätsbewertung voraussichtlich stützen wird.

Welche Rolle spielt die BSI TR-03183-2?

Die Technische Richtlinie TR-03183-2 des BSI ist der ausführlichste Feldkatalog im deutschsprachigen Raum. Die aktuelle Version 2.1.0 vom 20. August 2025 verlangt JSON oder XML nach CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Pflichtfelder der SBOM sind der Ersteller und ein Zeitstempel, je Komponente unter anderem Ersteller, Name, Version, Dateiname, Abhängigkeiten, Distributionslizenz und ein SHA-512-Hash der auslieferbaren Komponente. Die Abhängigkeiten sind rekursiv aufzulösen, mindestens bis zur ersten Komponente außerhalb des Lieferumfangs.

Das BSI stellt selbst klar, dass die Richtlinie nicht verbindlich ist und keine Konformitätsvermutung begründet; harmonisierte Normen sollen sie ablösen. Der Normentwurf verweist nur an einer Stelle auf sie, in einer Anmerkung zur Top-level-SBOM. Für eine Anlage aus zugekauften Geräten sind Dateiname und SHA-512 je Firmware-Bestandteil in der Regel nicht zu beschaffen. Wir halten die TR deshalb für einen guten Maßstab bei eigener Software mit eigenem Build und für eine schlechte Vorlage im Lastenheft einer Anlage.

Verlangt die Maschinenverordnung eine SBOM?

Nein. Die Maschinenverordnung (EU) 2023/1230, anwendbar ab dem 20. Januar 2027, kennt keine Software-Stückliste. Am nächsten kommt Anhang III Teil B Nr. 1.1.9: Die Maschine muss die installierte Software, die für den sicheren Betrieb erforderlich ist, kenntlich machen und diese Information jederzeit in leicht zugänglicher Form bereitstellen können. Das betrifft die sicherheitsrelevante Software und ihren Stand, nicht die Komponenten und Lieferkettenbeziehungen, die der CRA meint. Wir sehen darin trotzdem einen Anknüpfungspunkt, weil die Software-Stände der Sicherheitstechnik damit ohnehin auslesbar sein müssen.

Wie lesen wir die Pflicht für eine Anlage?

Ab hier beginnt die Auslegung. Wir lesen das so, als Einschätzung von Werkspilot und nicht als Rechtsauskunft:

• Die obersten Abhängigkeiten einer Anlage sind die verbauten Geräte mit ihrer Firmware. Jedes Gerät erscheint mit Hersteller, Bestellnummer und Firmware-Stand, verbunden durch die Beziehung „Anlage enthält Gerät“. Das deckt sich mit der Hardware-Liste aus PRE-8-RQ-02 des Normentwurfs.
• Der eindeutige Identifikator ist im OT praktisch Hersteller plus Bestellnummer plus Firmware-Stand. Industrie-Advisories benennen Hardware so und nicht über CPE: Der CSAF-Feed von Siemens enthält Stand 7. Oktober 2026 841 Advisories und keine CPE. Wie das bei weiteren Herstellern aussieht, zeigt der Vergleich SBOM je Hersteller.
• Den Hash gibt es bei zugekaufter Firmware selten. Der Entwurf verlangt ihn nur, wenn der Lieferant ihn liefert; wo der Hersteller ihn veröffentlicht, gehört er hinein.
• Eine transitive SBOM für zugekaufte Komponenten ist nicht vorgeschrieben und ohne den Build des Lieferanten nicht erhebbar. Anders bei eigener Software wie einem selbst gebauten IPC-Image: Dort gibt es einen Build, und die tiefe SBOM ist machbar.
• Die Kundenforderung „SBOM mitliefern“ regelt der Vertrag. Der CRA verlangt keine Weitergabe (Erwägungsgrund 77, Anhang II Nr. 9).

Welche Felder gehören in die Anlagen-SBOM?

Die Tabelle zeigt die Form, nicht die Füllung. Jede Zeile nennt die Quelle, ihre Verbindlichkeit und woher die Angabe in einem OT-Projekt typischerweise kommt.

Was gehört heute ins Lastenheft?

Wer eine SBOM zusagt, sollte die Ebene festschreiben: Geräte mit Hersteller, Bestellnummer und Firmware-Stand, als CycloneDX oder SPDX, mit Autor, Version und Zeitstempel, neu erstellt bei jeder Abnahme und nach jedem Firmware-Update. Tiefere Abhängigkeiten, Hashes und Lizenzangaben sind Leistungen, die man anbieten kann, die der CRA aber nicht verlangt. Ob die Kommission nach Art. 13 Abs. 24 tätig wird und wie der Normentwurf am Ende formuliert ist, verfolgen wir und aktualisieren diesen Beitrag.

Werkspilot gleicht die Geräteliste ausgelieferter Anlagen laufend mit den Advisories der Komponentenhersteller ab. Dieser Beitrag gibt den Stand Oktober 2026 wieder und ist keine Rechtsberatung. Maßgeblich ist der Verordnungstext; prEN 40000-1-3 ist ein Normentwurf, Kommissions-FAQ und Leitlinien sind nicht bindend.