SBOM-Tools für den Anlagenbau: womit Stückliste, Engineering-Projekt und Netzwerkscan erhoben werden

Die Suche nach einem „SBOM-Tool" führt zuverlässig zu Werkzeugen, die einen Build oder wenigstens ein Dateisystem voraussetzen. Für eine Verpackungsmaschine aus SPS, HMI, Antrieben, Industrie-PCs und Sensorik von Dutzenden Lieferanten greift keines davon: Es gibt keinen Build, der diese Anlage erzeugt, und keinen Paketmanager, der sie beschreibt. Woher die Daten stattdessen kommen, behandelt der Beitrag zur SBOM-Erstellung im Anlagenbau; welche Plattformkategorie das Schwachstellenmanagement danach trägt, der Beitrag zur Tool-Auswahl. Hier geht es um den Schritt dazwischen: Womit werden die Daten tatsächlich erhoben?

Stückliste, Engineering-Projekt und Netzwerkscan sind drei getrennte Quellen

Die Werkzeuge sortieren sich nach der Quelle, die sie auslesen. Die Stückliste enthält den bestellten Umfang, das Engineering-Projekt den projektierten und der Scan den tatsächlich laufenden Stand.

Weg 1: Die Stückliste kommt aus ERP, ECAD oder PDM

Für die kaufmännisch-konstruktive Hälfte geht es um 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 und ist damit die Pflichtbasis. 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, weil die Elektrokonstruktion mit Herstellerdaten arbeitet. 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.

Ein eigenes Werkzeug braucht dieser Weg nicht. Eine CSV- oder Excel-Ausleitung mit Artikelnummer, Bezeichnung, Menge, Lieferant und Einbauort reicht. Arbeit macht erst der Anspruch, sie je Anlage reproduzierbar abrufen zu können.

Weg 2: Der Hardware-Export des Engineering-Projekts liefert die Firmware-Version

Die Quelle, die bei den meisten Maschinenbauern vollständig vorhanden ist und trotzdem selten genutzt wird. Jedes Engineering-Projekt – TIA Portal bei Siemens, TwinCAT bei Beckhoff, Studio 5000 bei Rockwell, Automation Studio bei B&R – 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. Wie der Export aussieht, unterscheidet sich je Hersteller; 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.

Werkzeuge, die diesen Schritt fertig anbieten, gibt es inzwischen – allerdings für die Betreiberseite. octoplant (AUVESY-MDT) zieht als Versionsmanagement zyklisch Backups von den Steuerungen; das aufgesetzte Octovision wertet diese Daten zu einem Asset-Inventar mit CVE-Bezug aus. Wie die kontinuierlichen Monitoring-Plattformen setzt das voraus, dass die Software dort läuft, wo die Anlage steht – für den Blick des Anlagenbauers auf ausgelieferte Anlagen greift das Modell nicht. OTbase (Langner) führt Engineering-Daten und Netzwerk-Discovery in einem Inventar zusammen und deckt damit Weg 2 und Weg 3 im selben Werkzeug ab.

Werkspilot arbeitet direkt mit diesen Quellen: Hardware-Export aus dem Engineering-System, Artikelliste aus EPLAN oder Stückliste aus dem ERP – die Datei geht so hinein, wie das jeweilige System sie ausgibt. Ein Netzwerkscan aus der Abnahme lässt sich ergänzend verarbeiten, ist aber keine Voraussetzung. Die Geräte werden normalisiert, gegen die Advisories der Lieferanten abgeglichen und je ausgelieferter Anlage nachgehalten – im Einsatz heute bei Anlagenbauern und Komponentenherstellern, die genau diesen Abgleich laufen haben. Der Blickwinkel ist der des Anlagenbauers auf seine Feldbasis, nicht der eines Betreibers auf ein überwachtes Netz.

Trotzdem bleibt das Engineering-Projekt die zweitbeste Quelle:

• Es beschreibt den Soll-Zustand. Projektiert wird häufig „Firmware ab Version x", eingebaut wird der Stand, den der Lieferant zu diesem Zeitpunkt versendet.
• Es kennt das Lager nicht. Komponenten, die eine Weile im eigenen Lager standen, tragen bei der Auslieferung oft einen älteren Firmware-Stand als das aktuelle Werksmuster, und niemand aktualisiert sie vor dem Einbau.
• Es deckt nur den Automatisierungsumfang ab. Der Industrie-PC mit dem Vision-System, das Kamerasystem und der Router des Fernwartungszugangs existieren für diese Quelle nicht.

Weg 3: Für den Netzwerkscan taugt ein Inbetriebnahme-Werkzeug besser als ein Sicherheitsprodukt

Die besten Werkzeuge fürs Abnahmefenster liegen bereits auf dem Engineering-Notebook. Welches das richtige ist, hängt an zwei Fragen: Wie viele Steuerungswelten stecken in der Anlage, und ist der Scan ein Einzelfall oder ein Prozessschritt? Die Tabelle ordnet die Werkzeuge diesen beiden Fragen zu. Die kontinuierlichen OT-Monitoring-Plattformen stehen mit darin, weil sie in jeder Recherche zuerst auftauchen; gebaut sind sie für den Betreiber, der sein Werk dauerhaft überwacht.

Zwei Zuordnungen decken in der Praxis die meisten Fälle ab:

• Eine Steuerungswelt, einzelne Abnahme: das Discovery-Werkzeug des Herstellers für die Fläche (bei Siemens PRONETA), die Online-Sicht des Engineering-Systems für den Soll-Ist-Vergleich, die Feldbus-Diagnose für alles hinter der Kopfbaugruppe, Wireshark als Gegenprobe. Kosten: der Termin.
• Mehrere Auslieferungen pro Jahr, mehrere Herstellerwelten in einer Anlage: ein Discovery-Werkzeug wie OTbase, fest als Schritt in der Abnahmeprozedur. Die Lizenz rechnet sich gegen die Stunden für das Zusammenführen der Exporte.

Eine Warnung gehört dazu: 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. Genau davor warnt der verbreitete Satz „aktives Scannen ist in OT gefährlich". Für PRONETA oder die Online-Sicht des Engineering-Systems gilt er nicht: Die fragen in den Protokollen der Automatisierung an, so wie jede Engineering-Station am Netz. Entscheidend ist, ob ein Werkzeug die Sprache der Geräte spricht; aktiv oder passiv ist dafür die falsche Trennlinie.

Formatwerkzeuge sind die kleinste Sorge

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. Schwierig wird es eine Stufe früher: Die Formate erwarten CPE oder PURL als Identifikator, und für Industriekomponenten existieren die oft schlicht nicht. Der realistische Identifikator ist Hersteller plus Artikelnummer plus Version – genau so benennen Industrie-Advisories ihre betroffenen Produkte. Eine saubere Liste in CSV ist mehr wert als eine formal korrekte CycloneDX-Datei, deren Versionsangaben geraten sind.

Zusammenführen und Abgleich bleiben offen

Alle genannten Werkzeuge erzeugen Listen. Danach bleiben zwei Schritte offen, die keines von ihnen übernimmt.

Das Zusammenführen. Die Quellen schreiben 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, das Projekt die MLFB. Schreibweisen, Leerzeichen und Optionskürzel weichen systematisch ab. Das je Anlage von Hand zuzuordnen kostet mehr Zeit als der Scan und der Export zusammen. Genau diesen Schritt, aus mehreren Exporten einen Gerätebestand je Anlage zu machen, übernimmt Werkspilot.

Der Abgleich. Die SBOM zu erstellen ist selbst eine CRA-Pflicht (Anhang I Teil II Nr. 1). Mit der Liste allein ist es aber nicht getan – sie ist die Grundlage für das laufende Schwachstellenmanagement. Dafür müssen neue Lieferanten-Advisories kontinuierlich gegen diesen Bestand laufen. Das Ergebnis ist 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.

Konkret wird das am schnellsten an einer echten Anlage. Exportieren Sie, was Ihr System hergibt – CAx-Export aus dem TIA Portal, das Äquivalent aus TwinCAT oder Studio 5000, die Artikelliste aus EPLAN oder die Stückliste aus dem ERP. Wir normalisieren die Geräte und gleichen sie gegen offene Schwachstellen ab. Es braucht keine fertige SBOM und kein bestimmtes Format.

Export prüfen lassen →

Fragen aus der Praxis

Reicht ein einzelnes Werkzeug für die gesamte Erhebung?

Nein. Was kein Erhebungswerkzeug löst: die Zuordnung zu Auftrag und Lieferant (die kommt aus dem ERP), nicht vernetzte Komponenten (die sieht kein Scanner) und der laufende Abgleich gegen Lieferanten-Advisories (der beginnt erst nach der Erhebung). Der Erhebung selbst kommt OTbase am nächsten, weil es Engineering-Daten und Discovery in einem Inventar zusammenführt – auch das ersetzt keine Quelle, es spart Normalisierungsarbeit.

Was ist mit Syft, Trivy und den übrigen SBOM-Generatoren?

Sie sind richtig für eigene Software – den selbst gebauten IPC-Image, die eigene Applikation. Dort gibt es einen Build und damit eine echte, tiefe SBOM. Für zugekaufte Industriekomponenten greifen sie nicht: Was in der Firmware einer fremden SPS steckt, weiß nur deren Hersteller.

Wie oft muss der Scan wiederholt werden?

Nicht nach Kalender, sondern nach Ereignis. Der Auslieferungsstand wird bei der Abnahme erfasst; danach ändert er sich bei Retrofit, Komponententausch oder Firmware-Update im Serviceeinsatz. Jeder eigene Berührungspunkt mit der Anlage ist eine Gelegenheit, den Stand nachzuziehen. Ein permanent aktuelles Feld-Inventar über alle ausgelieferten Anlagen ist dagegen eine Fiktion – die Anlage steht beim Betreiber, häufig ohne Fernzugriff.

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. Genannte Produkte und Marken gehören ihren jeweiligen Herstellern; es besteht keine Geschäftsbeziehung zu den genannten Anbietern.