Eine Maschine ist heute ein Verbund aus Komponenten unterschiedlicher Hersteller. Ein Maschinenbauer integriert diese Komponenten und verantwortet nach dem CRA das Gesamtprodukt. Solange er die Software auf einer zugekauften Komponente nicht selbst verändert, muss er deren Innenleben nicht selbst aufschlüsseln; die Stücklistenpflicht des CRA verlangt mindestens die Top-Level-Abhängigkeiten des Produkts. Was er aber wissen und mit der gebotenen Sorgfalt prüfen muss, ist, welche Komponente in welchem Firmwarestand verbaut ist. Erst diese Angabe erlaubt die Prüfung, ob für dieses Gerät in dieser Version eine bekannte Schwachstelle vorliegt. Wer beim Zulieferer nachfragt, erhält Datenblätter und Handbücher, im besten Fall eine Firmware-Versionsnummer, selten eine maschinenlesbare Auflistung. Die Angaben verteilen sich über Projektdateien, Exporte einzelner Geräte und Unterlagen unterschiedlicher Hersteller, jeweils in deren eigenem Format. Zusammengetragen wird das meist einmalig in einer Tabelle, mit erheblichem Aufwand und ohne dass die Arbeit beim nächsten Maschinentyp wiederverwendbar wäre. Die Frage lautet daher: Woher kommen diese Daten?
Nachweis zum Inverkehrbringen
Verbindlich wird diese Frage mit der CE-Kennzeichnung. Der CRA verlangt von Herstellern, Produkte ohne bekannte ausnutzbare Schwachstellen in Verkehr zu bringen, und fordert dafür eine Software-Stückliste, (Software Bill of Materials, SBOM), in einem gängigen maschinenlesbaren Format als Teil der technischen Dokumentation. Der Nachweis ist an einen konkreten Zeitpunkt gebunden, nämlich das Inverkehrbringen, im Maschinenbau praktisch die Endabnahme der fertigen Maschine. Ab dem 11. Dezember 2027 gilt die Anforderung vollständig: Ohne nachgewiesene Konformität darf kein neues Produkt mit digitalen Elementen mehr in der EU in Verkehr gebracht werden. Schon vorher, ab dem 11. September 2026, greifen die Meldepflichten des CRA, nach denen aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden sind. Wer diese Frist halten will, muss bereits dann wissen, was in seinen Maschinen steckt.
Maschinen entwickeln ein Eigenleben
Mit der Auslieferung endet die Aufgabe nicht. Der CRA verpflichtet den Hersteller, Schwachstellen über den gesamten Supportzeitraum wirksam zu behandeln, der sich an der erwarteten Nutzungsdauer des Produkts orientiert. Eine Maschine verändert sich in dieser Zeit im Feld: Baugruppen werden im Service getauscht, Komponenten nachgerüstet, Firmware-Updates vor Ort eingespielt. Greift ein solcher Eingriff tief genug, kann die Maschine sogar als neues Produkt gelten und muss erneut eine Konformitätsbewertung durchlaufen. Bei Serienmaschinen tragen zwei Anlagen desselben Typs nach wenigen Betriebsjahren unterschiedliche Stände. Der zum Inverkehrbringen dokumentierte Zustand beschreibt die Maschine dann nicht mehr. Der CRA trägt dem Rechnung: Die technische Dokumentation ist während des Unterstützungszeitraums laufend zu aktualisieren, und wer Schwachstellen wirksam behandeln will, muss den tatsächlichen Stand seiner Maschinen kennen. Bei Laufzeiten von 15 bis 20 Jahren betrifft das nicht den Moment der Auslieferung allein: Jede ab Ende 2027 in Verkehr gebrachte Maschine trägt diese Pflicht über ihren gesamten Unterstützungszeitraum mit sich, und der so zu überwachende Bestand wächst von Jahr zu Jahr. Eine Erhebung, die nur einmal stattfindet, verfehlt diesen Zweck.
Die Antwort liegt in der Maschine
Die gesuchten Angaben sind meist vorhanden, als Artefakte an unterschiedlichen Orten und nicht in auswertbarer Form. Was keines dieser Artefakte hergibt, verrät die laufende Anlage selbst: Im Netzwerkverkehr der Maschine geben sich die Teilnehmer samt Typ und Version zu erkennen. Ein tragfähiger Ansatz muss deshalb vorhandene Artefakte auswerten. Das setzt voraus, dass die proprietären Projektformate der Steuerungshersteller gelesen werden können. Denn generische Analysewerkzeuge erkennen sie nicht und melden schlicht null Komponenten. Das Ergebnis muss zudem in einem standardisierten, maschinenlesbaren Format vorliegen, damit es sich automatisiert weiterverarbeiten lässt. Und die Erhebung muss wiederholbar sein, weil eine Stückliste ihren Wert verliert, sobald sich der Softwarestand ändert.
SBOM aus dem Steuerungsprojekt
Die Software des Unternehmens Complioty liest die Projektdateien gängiger Entwicklungsumgebungen, darunter Rockwell, B&R Automation Studio und Codesys, und löst daraus die verbauten Komponenten samt Firmware- und Bibliotheksversionen auf. Ergänzend lassen sich einzelne Zulieferdateien einlesen und bereits vorhandene Stücklisten anderer Hersteller auf ein einheitliches Schema normalisieren. Über eine Analyse des Netzwerkverkehrs erkennt der Scanner zudem die tatsächlich vorhandenen Teilnehmer im Maschinennetz. Dies ist dann nützlich, wenn Projektdaten unvollständig sind oder der Stand im Feld vom dokumentierten Stand abweicht. Aus allen Quellen entsteht eine zusammengeführte Stückliste der Maschine im Format CycloneDX oder SPDX, den beiden verbreiteten offenen Standards für Software-Stücklisten. Abbildung 1 zeigt, wie die Angaben aus den verschiedenen Quellen einer Maschine zusammengeführt werden. Der Scanner arbeitet als Kommandozeilenwerkzeug dort, wo die Projektdaten ohnehin liegen, und lässt sich in eine Build-Pipeline einbinden, sodass bei jedem Stand automatisch eine aktuelle Stückliste entsteht.
Wie sich dieser Schritt vereinfacht, wenn die Komponente selbst ‚mitspielt‘, zeigt CtrlX OS von Bosch Rexroth: Funktionen der Steuerung sind dort Apps mit eindeutigem Versionsstand, die CtrlX PLC App etwa setzt auf dem verbreiteten Codesys-V3-Laufzeitsystem auf. Was auf der CtrlX Core läuft, ist damit von Haus aus inventarisierbar, genau die Datenqualität, aus der eine belastbare Stückliste der Gesamtmaschine entsteht. Die zugehörigen Projektdateien liest der Scanner bereits.
Überwachung statt Einmalanalyse
Die erzeugte Stückliste wird in die Plattform geladen und dort dauerhaft gegen bekannte Schwachstellen abgeglichen, die als CVE-Einträge (Common Vulnerabilities and Exposures), veröffentlicht werden. Neue Einträge werden automatisch den verbauten Komponenten zugeordnet. Neben den öffentlichen CVE-Datenbanken wertet die Plattform auch Hersteller-Advisories aus. Bosch Rexroth veröffentlicht Security Advisories beispielsweise über das Bosch PSIRT mit einem eigenen, abonnierbaren Feed für Rexroth-Produkte. Die Complioty-Plattform zeigt jedoch den Sicherheitsstatus der Gesamtmaschine, vom vorbildlich dokumentierten Antriebsregler bis zur Komponente, deren Hersteller gar keine Advisories veröffentlicht. Bild 2 stellt diesen Ablauf dar.
Für die Priorisierung greift die Plattform unter anderem auf das Exploit Prediction Scoring System zurück, das für jede Schwachstelle die Wahrscheinlichkeit einer Ausnutzung innerhalb der kommenden 30 Tage schätzt, und wertet Hinweise auf verfügbare Exploits aus. So entsteht aus einer langen Trefferliste eine handhabbare Rangfolge. Aufbereitet werden betroffene Komponenten, Instanzen, Baugruppen und Maschinen, die jeweilige Schwachstelle sowie die vom Komponentenhersteller veröffentlichten Gegenmaßnahmen. Die sicherheitstechnische Bewertung im konkreten Einsatzszenario bleibt beim Maschinenbauer. Automatisiert wird die Datengrundlage, die die Bewertung überhaupt erst ermöglicht.
Von der Sonderaufgabe zum Prozess
Der Nachweis, welche Komponenten in welchem Stand in einer Maschine verbaut sind, lässt sich manuell nicht sinnvoll führen. Er entsteht in den Projektdaten des Herstellers und im Netzwerk der Maschine selbst. Wird die Stückliste automatisiert daraus erzeugt und anschließend fortlaufend gegen neue Schwachstellen abgeglichen, wird aus einer wiederkehrenden Sonderaufgabe ein mitlaufender Prozess.
