Kurz gefasst · Stand: September 2026
Die meisten CRA-Tools sind für Software-Hersteller gebaut, die ihren Code selbst schreiben. Im Anlagenbau steckt das Risiko dagegen in zugekaufter Firmware von Dutzenden Lieferanten, viele davon ohne maschinenlesbaren CSAF-Feed. Vier Fragen entscheiden die Auswahl: Datenweg hinein und hinaus, Feldbasis aus Auslieferungsstand und Servicehistorie, Abgleich gegen die konkreten Firmware-Stände und eine im Audit begründbare Betroffenheitsbewertung inklusive VEX. Die Checkliste dazu steht weiter unten.
Werkzeuge fürs Schwachstellenmanagement sind überwiegend für Software-Hersteller gebaut, die ihren Code selbst schreiben. Das Risiko eines Anlagenbauers steckt dagegen fast vollständig in zugekaufter Firmware über einen langen Lieferantenschwanz. Werkspilot ist für diesen zweiten Fall gebaut; die vier Auswahlfragen unten sind neutral gehalten und taugen, um jeden Anbieter zu prüfen, uns eingeschlossen.
Ihr Risiko sitzt in der Firmware von Siemens, SICK und Pilz, nicht im eigenen Code
Seit dem 11. September 2026 gilt die Meldepflicht nach Artikel 14 des Cyber Resilience Act; Fristen und Pflichten behandelt ein eigener Beitrag. Für die Tool-Auswahl ist vorher zu klären, welche von zwei Aufgaben hinter „CRA-Schwachstellenmanagement" gemeint ist.
Ein Software-Hersteller baut sein Produkt selbst; seine Schwachstellen stecken in Open-Source-Bibliotheken aus dem eigenen Build. Dafür gibt es einen reifen Werkzeugkasten: SCA, SBOM-Erzeugung aus dem Build, Abgleich gegen CVE-Datenbanken, VEX für die Statusaussage. Diesen Teil haben viele Anlagenbauer für ihre eigene Softwareentwicklung bereits im Griff, etwa mit Dependency-Track.
Ein Anlagenbauer baut sein Produkt zum größten Teil aus Zukaufteilen: SPS, HMI, Antriebe, Industrie-PCs und Sensorik von Siemens, Beckhoff, B&R, SICK, Pilz, Phoenix Contact, Schneider, Rockwell und Dutzenden kleinerer Lieferanten. Der eigene sicherheitskritische Code ist der kleinere Teil, die zugekaufte Firmware will über 15 bis 20 Jahre Feldeinsatz beobachtet sein. Seine Kernfrage lautet deshalb: Wie erfahren Sie von einer Schwachstelle in einer zugekauften Komponente, und welche Ihrer ausgelieferten Anlagen sind konkret betroffen?
Warum Dependency-Track bei einer zugekauften SPS null Treffer zeigt
Dependency-Track steht hier für die ganze Werkzeugklasse: eine SBOM aus dem eigenen Build entgegennehmen und deren Pakete gegen CVE-Datenbanken abgleichen. Beim Zukauf fehlen die Voraussetzungen dafür.
- Zukauf-Firmware hat keinen Paket-Identifikator. Der Abgleich gegen CVE-Datenbanken läuft über PURL für Ökosystem-Pakete oder CPE für die NVD. Zugekaufte Firmware hat keinen davon: Es gibt kein Paket-Ökosystem, das ihr ein PURL gäbe, und die CPE-Abdeckung ist gerade bei den kleineren Herstellern lückenhaft, bei denen das Risiko sitzt. Seit Anfang 2024 bekommt zudem ein spürbarer Teil neuer CVEs gar kein CPE mehr.
- Es gibt keinen Build, aus dem eine SBOM fallen könnte. Für eine zugekaufte SPS oder einen Sicherheits-Laserscanner gibt es keinen eigenen Build, und der Komponentenhersteller liefert nur selten eine SBOM mit. Vorhanden sind Artikelnummer und Firmware-Stand. Wer daraus von Hand eine Geräte-SBOM baut (CycloneDX kann das abbilden), verschiebt das Problem nur zum Abgleich.
- Das Datenmodell kennt keine ausgelieferten Anlagen. Hunderte Anlagen mit unterschiedlichen Firmware-Ständen, Retrofits und Jahrzehnten im Feld passen nicht in ein Modell aus Software-Projekten und Abhängigkeiten.
Konsequenz
Für zugekaufte Komponenten findet ein CPE-/PURL-basiertes Tool keine einzige Schwachstelle – auch dann nicht, wenn der Lieferant Dutzende Advisories dazu veröffentlicht hat. Die Null im Dashboard heißt dann nur, dass nichts geprüft wurde.
Dashboard zeigt
0 offene Schwachstellen
Tatsächlich abgeglichen
keine SPS, kein Antrieb, kein Scanner
Wer Dependency-Track für die eigene Softwareentwicklung nutzt, sollte dabei bleiben. Die Zukauf-Frage beantwortet es nicht.
Siemens allein veröffentlicht 821 Advisories, und keines davon ist über CPE auffindbar
Der öffentliche CSAF-Feed von Siemens enthält Stand Juli 2026 821 Advisories mit über 5.000 verschiedenen CVEs. Das ist ein einziger Lieferant, und einer, der seine Advisories maschinenlesbar, signiert und automatisiert abrufbar bereitstellt. Nebenbei mitlesen kann das niemand.
Zugleich verzichtet dieser Feed vollständig auf CPE und PURL. Ein betroffenes Produkt heißt dort „SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (6ES7518-4AX00-1AB0)", identifiziert über die Artikelnummer, mit Versionsbereichen in Siemens-eigener Notation. Ein rein CPE-basiertes Tool kann mit diesem Feed nichts anfangen, obwohl er formal alles richtig macht. Ihm fehlt schlicht der Schlüssel, über den es Produkte wiedererkennt.
In einer typischen Anlage stecken daneben Komponenten von Dutzenden weiteren Herstellern, und die wenigsten machen es wie Siemens. Maschinenlesbare Feeds im CSAF-2.0-Format sind die Ausnahme: Die vielen kleineren Komponentenlieferanten verschicken Advisories per PDF, per E-Mail an einen Verteiler oder stellen sie verstreut auf die eigene Website. Aggregatoren wie CERT@VDE füllen einen Teil der Lücke. Ob ein Tool diese Lieferanten abdeckt, sieht man dem Datenblatt nicht an, und genau darauf kommt es an.
Welches OpenSSL in der S7-1500 steckt, weiß nur Siemens
Eine Binäranalyse ist stark, wenn man tief in eine einzelne Firmware hineinsehen und deren Komponenten ohne Herstellerangaben aufdecken will; ihre Berechtigung liegt bei Linux-basierten Geräten mit eigenem Build. Ein advisory-zentrierter Ansatz aus Herstellermeldungen, Aggregatoren und aktiver Erfassung auch der kleinen Hersteller passt, wenn das Risiko über viele Zukauf-Lieferanten verteilt ist. Verknüpft wird dann über die Produktidentifikation des Herstellers selbst: Artikelnummern und Produktbäume, wie sie in CSAF-Advisories stehen, mit Versionsbereichen in dessen eigener Logik.
Das ist auch kein Provisorium, das sich erledigt, sobald die CPE-Kataloge besser gepflegt werden. Welche OpenSSL-Version in der Firmware einer S7-1500 steckt, kann der Anlagenbauer nicht wissen und muss es auch nicht. Der Komponentenhersteller kennt seine interne Stückliste, prüft selbst und meldet das Ergebnis auf Produktebene, etwa „CPU-Firmware vor V3.1.5 betroffen". Hersteller, Artikelnummer und Firmware-Stand sind damit die einzige Ebene, auf der Sie überhaupt eigene Daten haben können. Ein besseres CPE-Matching würde daran nichts ändern.
Vier Fragen, die kein Datenblatt beantwortet
Die Reihenfolge entspricht der Priorität im Serien- und Sondermaschinenbau. Alle vier lassen sich in einer Demo innerhalb einer Stunde prüfen.
| Frage | Konkret prüfen | Warnsignal |
|---|
| 1. Datenwege | Excel-/CSV-Import aus dem ERP ohne Abtippen; dokumentierte API oder Export ins Ticketsystem | Konnektor-Katalog, in dem die eigene Systemlandschaft nicht vorkommt |
| 2. Feldbasis | Abnahme-Scan als Auslieferungsstand je Anlage; Serviceeinsätze als Ereignisse; Baureihe als ein Modell | Zusage eines permanent aktuellen Feld-Inventars |
| 3. Firmware-Abgleich | Advisory zu einer real verbauten Komponente einspielen und die Trefferliste ansehen | Ergebnis bleibt „Produkt X betroffen" ohne Anlagen- und Baureihenliste |
| 4. Bewertung | Begründung je Treffer exportierbar; VEX maschinenlesbar; KI-Einschätzung überstimmbar mit Nutzer und Zeitstempel | Score ohne nachvollziehbare Grundlage |
An der zweiten Frage bleiben die meisten Projekte hängen. Welche Firmware heute in einer Anlage läuft, die seit 15 Jahren beim Betreiber steht, weiß niemand; wenn ein Anbieter trotzdem ein permanent aktuelles Feld-Inventar verspricht, fragen Sie nach, woher die Daten kommen sollen. Was Sie sicher kennen, ist der Auslieferungsstand aus dem Netzwerkscan bei der Abnahme (FAT). Danach bekommen Sie die Anlage nur noch zu sehen, wenn Ihr Service vor Ort war, ein Retrofit lief oder ein Ersatzteil rausging, und genau diese Ereignisse muss das Tool je Anlage nachführen können. Wie der Bestand initial hineinkommt, aus ERP, PLM oder dem CAx-Export des TIA Portals, zeigt der Beitrag zu SBOM-Werkzeugen im Anlagenbau.
Ein echtes Advisory in der Demo zeigt in fünf Minuten, ob das Tool Anlagen nennt oder nur Produkte
Spielen Sie ein Advisory zu einer real verbauten Komponente ein. Beispiel: ein Sicherheits-Laserscanner, betroffen bis Firmware 2.4.7, behoben ab 2.5.0, über acht Jahre in mehreren Baureihen bei rund 200 Betreibern verbaut. Antwortet das Tool nur „Produkt betroffen", sucht Ihr Service anschließend von Hand. Antwortet es 140 Anlagen betroffen (2.3.x–2.4.7), 60 nicht betroffen (bereits ≥ 2.5.0), aufgeschlüsselt nach Baureihe und Betreiber, hat er eine Arbeitsliste. Der Test dauert fünf Minuten und lässt sich bei jedem Anbieter wiederholen.
Eine Stückliste sagt mehr als jeder Anbietervergleich
Bringen Sie die Stückliste einer einzigen Anlage mit, wir scannen sie im Gespräch auf offene Advisories. Ein Excel-Export aus dem ERP reicht, es braucht keine SBOM und kein besonderes Format. Sie sehen an Ihren eigenen Komponenten, wo der Firmware-Stand über die Betroffenheit entscheidet. Bringen Sie eine Stückliste mit ins Gespräch.
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.
