Eine Maschine ist keine klassische IT-Anwendung. Sie läuft oft 15 bis 20 Jahre, während sich die zugrundeliegende IT-Landschaft bereits nach wenigen Jahren verändert. Gleichzeitig besteht ihre Software nicht nur aus eigenem Code, sondern umfasst auch Komponenten von Zulieferern, statische Libraries und Vendor Code. Genau hier wird die Software Bill of Materials (SBOM) im Maschinenbau zur Herausforderung.
Warum SBOM im Maschinenbau so schwierig ist
Lange Lebenszyklen und dynamische IT-Landschaften
Steuerungen im Maschinenbau haben oft eine Nutzungsdauer von mehreren Jahrzehnten. Die IT-Umgebung, in der sie betrieben werden, entwickelt sich jedoch kontinuierlich weiter. Eine SBOM muss daher über den gesamten Lebenszyklus hinweg gepflegt, versioniert und archiviert werden. Das erfordert Prozesse, die sowohl die initiale Erstellung als auch die langfristige Aktualisierung sicherstellen.
Embedded-Systeme: Kein klassisches IT-Ökosystem
Maschinensteuerungen basieren häufig auf Embedded C/C++ mit eigenen Build-Systemen, statischen Libraries und Vendor Code. Standardisierte SBOM-Scanner stoßen hier an Grenzen, da sie nicht alle Komponenten zuverlässig erkennen. Automatisierte Lösungen müssen daher an die spezifischen Anforderungen des Maschinenbaus angepasst werden.
Die Lieferkette endet nicht beim eigenen Code
Komponenten wie PLC, HMI, Frequenzumrichter oder Kommunikationsstacks stammen oft von Zulieferern. Eine vollständige SBOM muss dennoch die gesamte Software-Lieferkette abbilden – von der eigenen Entwicklung bis zu den externen Komponenten. Das erfordert eine enge Zusammenarbeit mit Lieferanten und klare vertragliche Vereinbarungen zur Bereitstellung von Software-Informationen.
Drei praktikable Ansätze für die SBOM-Erstellung
Je nach Systemarchitektur und Lebenszyklusphase der Maschine bieten sich unterschiedliche Methoden an, um eine belastbare SBOM zu erstellen:
1. Build-Time-Erfassung
Bei Embedded-Linux-Systemen mit Yocto oder Buildroot kann die SBOM direkt während des Build-Prozesses generiert werden. Dieser Ansatz bietet den Vorteil, dass genau dokumentiert wird, welche Komponenten tatsächlich im finalen Image enthalten sind. Die SBOM entsteht somit als Nebenprodukt des Build-Prozesses und ist von Anfang an aktuell.
2. Manuelle Kuratierung
Bei C/C++-basierten Systemen oder Legacy-Anlagen kann ein manuell gepflegtes Manifest zuverlässiger sein als ein automatischer Scan. Hier werden Komponenten, Vendored Libraries und Patches systematisch erfasst und anschließend in eine strukturierte SBOM überführt. Dieser Ansatz erfordert zwar initial mehr Aufwand, bietet aber insbesondere bei komplexen oder älteren Systemen eine höhere Genauigkeit.
3. Domänenspezifisches Scanning
Für bestehende Anlagen, bei denen die ursprüngliche Build-Umgebung nicht mehr verfügbar ist, kommen spezialisierte Lösungen zum Einsatz. Diese können beispielsweise Informationen aus Entwicklungsumgebungen wie TIA Portal, B&R oder CODESYS auswerten oder während des Abnahmetests die OT-Landschaft erfassen. Solche Tools sind darauf ausgelegt, die spezifischen Anforderungen des Maschinenbaus zu berücksichtigen und liefern auch bei älteren Systemen verwertbare Ergebnisse.
Der Cyber Resilience Act: SBOM wird zur Pflicht
Die theoretische Auseinandersetzung mit SBOMs reicht nicht mehr aus. Mit dem Cyber Resilience Act (CRA) werden konkrete Anforderungen verbindlich:
- Ab September 2026 gelten Meldepflichten für Schwachstellen in Produkten mit digitalen Elementen.
- Ab dem 11. Dezember 2027 werden zentrale Anforderungen des CRA rechtsverbindlich.
Die SBOM entwickelt sich damit vom „Nice-to-have“ zu einem integralen Bestandteil des Produktlebenszyklus. Sie dient nicht nur der Compliance, sondern auch der Risikominimierung und der Sicherstellung der Produktqualität über den gesamten Lebenszyklus hinweg.
Die richtige Frage stellen
Die Herausforderung besteht nicht darin, ein SBOM-Tool auszuwählen. Entscheidend ist vielmehr, wie belastbare Transparenz über die Software einer Maschine geschaffen werden kann – von der Entwicklung bis zur ausgelieferten Anlage. Eine SBOM ist kein statisches Dokument, sondern ein dynamisches Abbild der Software-Lieferkette. Sie muss kontinuierlich aktualisiert und an die spezifischen Anforderungen des Maschinenbaus angepasst werden.
Ob Embedded Linux mit Yocto/Buildroot oder PLC-Systeme mit TIA Portal/CODESYS: Die Wahl des geeigneten Ansatzes hängt von der jeweiligen Systemarchitektur und den vorhandenen Prozessen ab. Wichtig ist, frühzeitig mit der Umsetzung zu beginnen, um die Anforderungen des CRA fristgerecht zu erfüllen und gleichzeitig die eigene Software-Lieferkette abzusichern.
Schreibe einen Kommentar