SBOM erstellen im Sondermaschinen- und Anlagenbau: Woher die Daten kommen, wenn es keinen Quellcode gibt

Werkzeuge zur SBOM-Erstellung laufen über den Build und lesen die Paketmanager-Metadaten aus. Eine Verpackungsmaschine aus SPS, HMI, Antrieben, Industrie-PCs und Sensorik von Dutzenden Lieferanten hat weder das eine noch das andere. Warum die gängigen Werkzeuge damit ins Leere laufen, behandelt ein eigener Beitrag zur Tool-Auswahl. Hier geht es um die Gegenfrage: Woher kommen die Daten, wenn kein Quellcode vorliegt und die Anlage nach der Auslieferung nicht mehr erreichbar ist?

Die SBOM beschreibt Geräte mit Firmware-Stand, keine Bibliotheken

Eine SBOM aus dem Software-Build beschreibt Pakete und Bibliotheken – eine Ebene, die dem Anlagenbauer für Zukaufkomponenten nicht zugänglich ist. Was er beschreiben kann, ist die Geräteebene: welches Gerät von welchem Hersteller mit welcher Software-Version in der Anlage steckt. Auf dieser Ebene arbeiten auch die Industrie-Advisories. Ein Hersteller meldet nicht „Bibliothek X in Version Y ist verwundbar", sondern „Produkt Z bis einschließlich Firmware 2.4.7 ist betroffen". Eine geschlossene Zukaufkomponente wird damit als Grenzknoten behandelt und nicht weiter zerlegt – die Begründung dafür steht im Leitfaden zu CRA und Maschinenverordnung. Abzugrenzen ist die reine Hardware-Stückliste: Sie sagt, welches Gerät verbaut ist, aber nicht, welche Software darauf läuft. Schwachstellen hängen an Software-Versionen, nicht an Bauteilen.

Damit ist auch die Frage nach der Tiefe beantwortet, die über den halben Aufwand entscheidet: Eine flache Liste der Geräte mit ihren Firmware-Ständen genügt, die Software-Zusammensetzung jeder Komponente gehört nicht darunter. Der Verordnungstext verlangt sie nicht – nach Anhang I Teil II Nr. 1 CRA muss die Software-Stückliste „zumindest die obersten Abhängigkeiten der Produkte" ausweisen –, und drei weitere Gründe sprechen für die flache Form:

• Die Tiefe ist nicht erhebbar. Was in der Firmware einer zugekauften SPS steckt, weiß nur deren Hersteller. Ohne dessen Build und dessen SBOM bleibt nur Raten, und eine geratene Abhängigkeitsliste sieht im Audit wie ein Befund aus.
• Die Tiefe ändert die Reaktion nicht. Steckt in der Firmware eines Antriebs eine verwundbare Bibliothek, bleibt die einzige Handlung dieselbe: auf das Firmware-Release des Lieferanten warten und es einspielen.
• Advisories kommen auf Produktebene an. „Produkt Z bis Firmware 2.4.7 betroffen" matcht direkt auf eine Geräteliste; die Übersetzung von der Bibliothek zur betroffenen Produktversion hat der Lieferant erledigt. Wer stattdessen Sub-Komponenten-Feeds selbst auswertet, handelt sich Rauschen ein – die Größenordnung, Tausende Kernel-CVEs pro Jahr aus einem einzigen Modul, der überwiegende Teil ohne Score, ist im Leitfaden zu CRA und Maschinenverordnung beziffert.

Zwei Grenzen hat das Prinzip. Für eigene Software – den eigenen SPS-Code, ein selbst gebautes IPC-Image – gibt es einen eigenen Build und damit eine echte, tiefe SBOM; dort ist der klassische Werkzeugkasten richtig. Und wo mehr Tiefe nötig ist, kommt sie über den Liefervertrag: eine Klausel, die je Release ein maschinenlesbares CSAF/VEX zusichert.

Die drei Datenquellen

Die benötigten Daten liegen an drei Orten, und die unterscheiden sich nicht nur im Inhalt, sondern im Wahrheitsgehalt: Die Stückliste sagt, was bestellt wurde. Das Engineering-Projekt sagt, was projektiert wurde. Nur der Scan sagt, was tatsächlich läuft. In dieser Reihenfolge steigen Aufwand und Belastbarkeit der Aussage.

Quelle 1: der Stücklisten-Export aus ERP, PDM und ECAD

Die kaufmännische und konstruktive Sicht liegt bereits im Haus, meist im ERP, teils im PDM- oder PLM-System. Sie liefert je Position die Artikelnummer des Herstellers – bei Siemens die MLFB, bei anderen die jeweilige Bestell- oder Typnummer –, Bezeichnung, Menge, Lieferant, Baugruppenposition und die Zuordnung zu Projekt, Auftrag und Anlage. Mit der Artikelnummer benennen Hersteller-Advisories ihre betroffenen Produkte; sie ist der Schlüssel zum späteren Abgleich. Welche Firmware auf dem Gerät läuft, weiß das ERP dagegen nicht: Ein Wareneingang bucht eine Artikelnummer, keinen Software-Stand.

Erhoben wird das über einen Export aus einem System, das ohnehin läuft – die drei üblichen Systeme sind unterschiedlich gut geeignet:

• ERP. Liefert die auftragsbezogene Stückliste mit Lieferant und Anlagenzuordnung. Schwäche: Der Einkauf führt Bestellbezeichnungen, nicht durchgängig normierte Herstellerartikelnummern.
• ECAD, in der Regel EPLAN. Für den Schaltschrank die präzisere Liste: Betriebsmittelkennzeichen plus echte Herstellerartikelnummer je Gerät. Wo beides existiert, ist die EPLAN-Artikelsummenstückliste der bessere Ausgangspunkt für den Advisory-Abgleich und der ERP-Export die Quelle für Auftrag, Lieferant und Zuordnung.
• PDM/PLM. Ergänzt die Baugruppenstruktur – nützlich, sobald ein Baureihen-Modell gepflegt wird, verzichtbar für die erste Anlage.

Eine CSV- oder Excel-Ausleitung mit den genannten Feldern reicht; der Aufwand liegt darin, sie reproduzierbar und je Anlage abrufbar zu machen.

Quelle 2: das Engineering-Projekt und sein Hardware-Export

Das Engineering-Projekt ist bei den meisten Maschinenbauern vollständig vorhanden und wird trotzdem selten genutzt. TIA Portal bei Siemens, TwinCAT bei Beckhoff, Studio 5000 bei Rockwell, Automation Studio bei B&R – jedes dieser Projekte enthält für jedes projektierte Gerät die Bestell- oder Typnummer und die projektierte Firmware-Version, also genau das Feld, an dem die Stückliste endet. Der Export sieht je Hersteller anders aus; der Inhalt ist derselbe.

Am besten dokumentiert ist der Weg bei Siemens. Der CAx-Export schreibt die projektierte Hardware als AutomationML-Datei heraus; die Geräte tragen dort einen Typbezeichner der Form OrderNumber:6ES7 510-1DJ01-0AB0/V2.9 – Bestellnummer, Schrägstrich, projektierter Firmware-Stand. Über TIA Openness lassen sich dieselben Angaben je Gerät auslesen.

Verlässlich ist das für Geräte aus dem Hardware-Katalog, die mit einem konkreten Firmware-Stand projektiert wurden. Bei GSD-/GSDML-basierten Fremdgeräten steht im Typbezeichner die GSD-Datei statt einer Bestellnummer, und Geräte, die nur als Platzhalter angelegt sind, tragen keinen belastbaren Versionsstand. Wie hoch dieser Anteil im eigenen Projektstandard ausfällt, zeigt der erste Export einer realen Anlage in fünf Minuten.

Fertige Werkzeuge dafür gibt es vor allem für die Betreiberseite: octoplant (AUVESY-MDT) zieht zyklisch Backups von den Steuerungen, das aufgesetzte Octovision wertet sie zu einem Asset-Inventar mit CVE-Bezug aus; OTbase (Langner) führt Engineering-Daten und Netzwerk-Discovery in einem Inventar zusammen. Beide setzen voraus, dass die Software dort läuft, wo die Anlage steht. Werkspilot arbeitet direkt mit den Quellen, die ohnehin vorliegen: Der Export geht so hinein, wie das Engineering-System ihn ausgibt, und wird laufend gegen die Advisories der Lieferanten gehalten – je ausgelieferter Anlage.

Drei Gründe machen das Engineering-Projekt zur zweitbesten Quelle. Erstens beschreibt es den Soll-Zustand: Projektiert wird häufig „Firmware ab Version x", geliefert und getauscht wird, was der Lieferant gerade ausliefert. Zweitens kennt es das eigene Lager nicht: Komponenten, die eine Weile im Lager standen, gehen mit einem älteren Firmware-Stand in die Anlage, und aktualisiert wird vor dem Einbau selten. Drittens deckt es nur den Automatisierungsumfang ab: Der Industrie-PC mit dem Vision-System, das Kamerasystem, der Router des Fernwartungszugangs existieren für diese Quelle nicht. Als Startpunkt taugt es trotzdem, weil es Bestellnummer und erste Versionsannahme in einem Datensatz liefert.

Quelle 3: der Netzwerkscan bei Abnahme oder Inbetriebnahme

Ein Scan des Anlagennetzes hält fest, was tatsächlich verbaut ist. Er liefert je erreichbarem Teilnehmer typischerweise Hersteller, Typbezeichnung, Firmware- beziehungsweise Software-Stand, Adressierung und Netzstruktur. Der Firmware-Stand steht in keinem kaufmännischen System und entscheidet über Betroffenheit: Zwei Anlagen derselben Baureihe, ausgeliefert im Abstand von acht Monaten, tragen regelmäßig unterschiedliche Firmware-Stände derselben Komponente, weil der Lieferant zwischenzeitlich nachgezogen hat.

Ebenso wichtig ist, was ein Scan nicht sieht:

• Nicht vernetzte Komponenten. Ein rein verdrahtetes Sicherheitsrelais oder ein Antrieb ohne Ethernet-Anbindung taucht im Scan nicht auf – auch wenn er Firmware trägt.
• Geräte hinter Feldbus oder Safety-Kreis. Was nicht direkt am IP-Netz hängt, ist bestenfalls indirekt über den Kopfbaugruppen-Eintrag sichtbar.
• Geräte, die nicht antworten. Nicht jedes Industriegerät gibt Typ und Version über ein Protokoll preis, das sich passiv auslesen lässt.

Ein solcher Scan gehört ins Abnahmefenster im eigenen Werk, mit Werkzeugen, die die Automatisierungsprotokolle sprechen – welche das sind, steht im Beitrag zu den SBOM-Tools. Ein Scan in einer laufenden Produktionsanlage beim Betreiber ist eine andere Sache – und keine, die man nebenbei macht.

Die drei Quellen im Vergleich

Zusammenführen zu einem Datensatz je Gerät

Keine der drei Quellen ist für sich eine SBOM. Über Typbezeichnung und Artikelnummer werden sie zu einem Datensatz je Gerät zusammengeführt: was verbaut ist aus ERP, PDM oder EPLAN, was projektiert war aus dem Engineering-Projekt, welcher Stand tatsächlich läuft aus dem Scan.

Von Hand skaliert dieser Match nicht. Eine mittlere Sondermaschine hat 80 bis 150 Netzwerkteilnehmer, ein Anlagenbauer liefert davon mehrere pro Jahr aus. Vor allem aber schreiben die Quellen dasselbe Gerät fast nie gleich: Der Scan meldet, was das Gerät über sein Protokoll von sich behauptet, das ERP führt die Bestellbezeichnung des Einkaufs. Schreibweisen, Leerzeichen und Zusätze wie Bauform- oder Optionskürzel weichen systematisch ab; das je Anlage von Hand zuzuordnen kostet mehr Zeit als Scan und Export zusammen.

Konkret wird das am schnellsten an einer echten Anlage. Exportieren Sie die Hardware aus dem Engineering-Projekt einer Anlage – wir gleichen die Geräte gegen offene Schwachstellen ab. CAx-Export aus dem TIA Portal, das Äquivalent aus TwinCAT oder Studio 5000, die Artikelliste aus EPLAN oder die Stückliste aus dem ERP: Es braucht keine fertige SBOM und kein bestimmtes Format. Sie sehen daran unmittelbar, wie viele Positionen sich sauber zuordnen lassen und wo es hakt. Export mitbringen.

Heraus kommt eine Liste je Anlage: Hersteller, Artikelnummer, Bezeichnung, Software-Stand, Einbauort, plus die Herkunft der Angabe – gemessen oder aus Stammdaten übernommen. Die Herkunft entscheidet im Audit darüber, wie belastbar eine Aussage ist.

Werkzeuge für den Abnahme-Scan

Für den Scan im Abnahmefenster eignet sich ein Inbetriebnahme-Werkzeug besser als ein Sicherheitsprodukt, und die besten liegen bereits auf dem Engineering-Notebook: bei Siemens PRONETA und die Online-Sicht des TIA Portals, bei Beckhoff, Rockwell oder B&R das jeweilige Diagnosewerkzeug, dazu Wireshark als passive Gegenprobe. Ab regelmäßigen Abnahmen lohnt ein Discovery-Werkzeug für mehrere Herstellerwelten; OT-Monitoring-Plattformen wie Claroty oder Nozomi sind für den Betreiber gebaut und für die einmalige Abnahmeerfassung die falsche Kategorie. Der Werkzeugvergleich je Erhebungsweg steht im eigenen Beitrag zu den SBOM-Tools im Anlagenbau.

IT-Scanner wie Nmap und Schwachstellenscanner in ihrer Standardkonfiguration sind für Anlagennetze in aller Regel ungeeignet. Ältere Steuerungen und Feldgeräte quittieren aggressives Port-Probing im schlimmsten Fall mit Stillstand. Werkzeuge, die in den Protokollen der Automatisierung anfragen, tun dagegen dasselbe wie jede Engineering-Station am Netz.

Was in die SBOM kommt, wenn CPE und PURL fehlen

Die etablierten Formate – CycloneDX und SPDX – erwarten üblicherweise CPE oder PURL als Identifikator. Für Industriekomponenten existieren die oft schlicht nicht.

Das ist kein Grund, das Format zu wechseln, sondern einer, den Identifikator realistisch zu wählen: Hersteller plus Artikelnummer plus Version. Genau so identifizieren Industrie-Advisories ihre betroffenen Produkte – die Belege dafür, bis hin zum ausgewerteten Hersteller-Feed ohne ein einziges CPE, stehen im Beitrag zur Tool-Auswahl. Beide Formate können solche Identifikatoren tragen; die inhaltlichen Mindestangaben orientieren sich an BSI TR-03183 Teil 2.

Eine saubere, vollständige Liste in CSV ist damit mehr wert als eine formal korrekte CycloneDX-Datei, deren Versionsangaben geraten sind. Ein eigenes Format-Werkzeug braucht es zunächst nicht: Die Konvertierung einer Geräteliste nach CycloneDX ist ein gelöstes Problem, dafür gibt es offizielle Bibliotheken, und Werkzeuge wie das CycloneDX-CLI oder sbom-utility prüfen am Ende, ob die Datei formal trägt.

Erhoben wird bei der Abnahme

Das Zeitfenster für die Erhebung ist schmal. Bei Abnahme oder Inbetriebnahme ist die Anlage vollständig, bestromt, zugänglich und im eigenen Zugriff. Danach steht sie beim Betreiber, häufig ohne Fernzugriff, und jede Nacherhebung wird zur Rekonstruktion aus Schaltplänen und Lieferscheinen – also zu genau der Hardware-Stückliste, die den Firmware-Stand nicht kennt. Der Scan gehört deshalb als Schritt in die Abnahmeprozedur, neben Funktionsprüfung und Dokumentation. Wird er dort verankert, entsteht die SBOM jeder künftigen Anlage nebenbei.

Der Kostenhebel dahinter greift früher, als die verbreitete Jahreszahl 2027 vermuten lässt. Die Verordnung gilt in der Breite ab dem 11. Dezember 2027, die Meldepflicht des Artikels 14 jedoch bereits ab dem 11. September 2026 (Art. 71 Abs. 2 CRA). Nach Art. 69 Abs. 3 CRA erfassen die Pflichten des Artikels 14 ausdrücklich alle in den Anwendungsbereich fallenden Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Für den Bestand bleibt es dabei bei der Meldung – die übrigen Pflichten, etwa die Schwachstellenbehandlung, greifen dort nicht (Kommissions-FAQ, Abschnitt 5.3). Melden können Sie aber nur, was Sie zuordnen können, und Art. 14 Abs. 8 verlangt zusätzlich, die betroffenen Nutzer zu informieren. Das setzt voraus, dass Sie wissen, in welchen ausgelieferten Anlagen die betroffene Komponente steckt.

Erhoben werden diese Daten also ohnehin, nur später und teurer: Eine Anlage, die ohne Scan durch die Abnahme geht, muss aus Schaltplänen, Lieferscheinen und Erinnerung rekonstruiert werden – mit einem Vielfachen des Aufwands, ohne die Firmware-Stände und mit einem schwächeren Ergebnis als das einmal Gemessene. Bei zehn Auslieferungen pro Jahr entscheiden die nächsten Abnahmen darüber, wie groß der Rekonstruktionsberg 2027 ist.

Für den Bestand gilt gleichzeitig: Ein permanent aktuelles Feld-Inventar über alle ausgelieferten Anlagen ist eine Fiktion. Was es gibt, ist der dokumentierte Auslieferungsstand plus die eigenen Berührungspunkte – Serviceeinsatz, Retrofit, Ersatzteillieferung. Warum dieses Modell trägt und ein Live-Inventar nicht, ist dort ausführlich hergeleitet.

Ziel ist der laufende Abgleich, nicht die einmalige Liste

Die SBOM zu erstellen ist selbst eine Pflicht des Cyber Resilience Act (Anhang I Teil II Nr. 1). Mit der Liste allein ist es aber nicht getan – sie ist die Grundlage für das eigentliche Ziel: laufendes Schwachstellenmanagement. Erst wenn neue Lieferanten-Advisories kontinuierlich gegen diesen Bestand laufen, entsteht daraus eine Aussage – meist die Entwarnung, dass die eigenen Anlagen nicht betroffen sind. Gebraucht wird sie, wenn der Endkunde nachfragt oder eine Meldung ansteht. Das maschinenlesbare Format dafür ist ein VEX-Statement. Den CRA erfüllt erst dieser laufende Abgleich, nicht die einmal abgelegte Datei.

Fünf Fragen aus der Praxis

Reicht das TIA-Projekt als SBOM?

Als Startpunkt ja, als Nachweis nein. Das Projekt kennt den Soll-Zustand des Automatisierungsumfangs – nicht den realen Firmware-Stand nach Auslieferung, Tausch und Serviceeinsatz, und nicht die Geräte außerhalb des Projekts. Wer nur eine einzige Quelle nutzen kann, nimmt den Scan.

Liefert der Komponentenhersteller nicht einfach eine SBOM mit?

In den seltensten Fällen. Für eine zugekaufte SPS, ein HMI oder einen Sicherheits-Laserscanner gibt es 2026 üblicherweise keine mitgelieferte SBOM. Ab Dezember 2027 müssen Komponentenhersteller eine SBOM erstellen (Anhang I Teil II Nr. 1) – sie an ihre Kunden weiterzugeben, sind sie nicht verpflichtet. Erwägungsgrund 77 hält ausdrücklich fest, dass keine Veröffentlichungspflicht besteht; vorzulegen ist die SBOM auf begründetes Verlangen der Marktüberwachungsbehörde (Anhang VII Nr. 8). Anhang II Nr. 9 regelt lediglich, dass der Hersteller angibt, wo die SBOM zu finden ist, falls er sie bereitstellt. Für alles, was bis dahin ausgeliefert wird – und für die installierte Basis der nächsten 15 Jahre – bleibt die Erhebung beim Anlagenbauer. Vertraglich verankern lässt sich die Lieferung; verlassen kann man sich in der Breite nicht darauf.

Reicht die Hardware-Stückliste aus dem ERP?

Nein, aber sie ist die halbe Miete und der richtige Startpunkt. Ohne den Firmware-Stand lässt sich zu einem Advisory nur sagen, dass ein Produkt betroffen sein könnte. Bei einer installierten Basis von 200 Anlagen ist das der Unterschied zwischen 200 Verdachtsfällen und einer belastbaren Aussage, welche Anlagen tatsächlich betroffen sind.

Muss für jede ausgelieferte Anlage eine eigene SBOM erstellt werden?

Im Ergebnis ja, im Aufwand nein. Anlagen einer Baureihe teilen den größten Teil ihrer Stückliste; sinnvoll ist ein gepflegtes Baureihen-Modell plus die Abweichungen und Firmware-Stände je Auslieferung. Kundenspezifische Optionen und der real gemessene Stand machen die Anlage individuell – die Basis bleibt geteilt.

Wie oft muss eine SBOM aktualisiert werden?

Nicht nach Kalender, sondern nach Ereignis. Sie ändert sich, wenn die Anlage sich ändert: Retrofit, Komponententausch, Firmware-Update im Serviceeinsatz. Jeder eigene Berührungspunkt mit der Anlage ist eine Gelegenheit, den Stand nachzuziehen. Zwischen diesen Ereignissen bleibt der letzte bekannte Stand die ehrlichste verfügbare Aussage.

So starten Sie an der nächsten Abnahme

Nehmen Sie eine Anlage statt eines Konzepts für den Gesamtbestand: vorab einen CAx-Export aus dem zugehörigen Engineering-Projekt als Gerüst, den Scan als Schritt in der Abnahmeprozedur, beides einmal mit dem Stücklisten-Export zusammengeführt. Danach kennen Sie die Qualität Ihrer Stammdaten, die Zahl der Komponenten, die der Scan nicht sieht, die Zahl der Geräte ohne Versionsangabe im Projekt und den tatsächlichen Normalisierungsaufwand.

Der Takt gibt dabei nicht der Kalender 2027 vor, sondern Ihr Abnahmeplan. Jede Anlage, die vorher ohne erfassten Auslieferungsstand das Werk verlässt, ist ein Rekonstruktionsfall mehr – und die Termine dafür stehen bereits in Ihrer Planung. Im Gespräch klären, wie das an Ihren Anlagen aussieht.

Werkspilot überwacht Lieferanten-Advisories automatisiert und gleicht sie gegen die Feldbasis von Anlagenbauern und Integratoren ab. Dieser Beitrag gibt die Einschätzung von Werkspilot wieder und ersetzt keine Rechtsberatung.