CRA-Tool-Auswahl im Anlagenbau: vier Fragen und ein Test für die Demo

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.

Software-Hersteller und Anlagenbauer lösen zwei verschiedene Aufgaben

Ab dem 11. September 2026 greift 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?

Dependency-Track deckt den eigenen Build ab, nicht den Zukauf

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.

• Kein PURL, kein verlässliches CPE. Der Abgleich gegen CVE-Datenbanken läuft über Paket-Identifikatoren: PURL für Ökosystem-Pakete, 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. Ohne Identifikator kein Treffer.
• Keine SBOM, kein Build. 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.
• Keine Feldbasis. Ausgelieferte Anlagen mit unterschiedlichen Firmware-Ständen, Retrofits und 15 bis 20 Jahren Feldeinsatz lassen sich im Modell aus Software-Projekten und Abhängigkeiten nicht abbilden.

Wer Dependency-Track für die eigene Softwareentwicklung nutzt, sollte dabei bleiben. Die Zukauf-Frage beantwortet es nicht.

Ein einziger Lieferant: 821 Advisories, über 5.000 CVEs, kein CPE

Der öffentliche CSAF-Feed von Siemens enthält Stand Juli 2026 821 Advisories mit über 5.000 verschiedenen CVEs. Das ist ein Lieferant, und einer, der es vorbildlich macht: maschinenlesbar, signiert, automatisiert einlesbar. Diese Menge liest niemand nebenbei mit.

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 also selbst den vorbildlichsten Advisory-Feed der Branche nicht verwerten: Es scheitert am Identifikator, nicht am Format.

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 Spitze des Portfolios: 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. Bei diesen Lieferanten ist der Deckungsgrad eines Tools am schwersten zu beurteilen und am wichtigsten.

Der Abgleich läuft über Hersteller, Artikelnummer und Firmware-Stand

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 trägt, 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 keine Übergangslösung, bis die Kataloge besser gepflegt sind. Welches OpenSSL in der Firmware einer S7-1500 steckt, weiß nur Siemens; der Anlagenbauer kann es 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 für die Tool-Auswahl

Die Reihenfolge entspricht der Priorität im Serien- und Sondermaschinenbau. Keine der vier Fragen lässt sich am Datenblatt beantworten.

1. Daten kommen ohne Abtippen hinein und wieder hinaus

Der teuerste Fehlkauf ist ein Tool, das neben den bestehenden Systemen steht und von Hand gepflegt werden muss. Die übliche Gegenfrage nach einem fertigen PLM/ERP-Konnektor führt selten weiter: Für die konkrete Systemlandschaft existiert er fast nie, und was der Vertrieb zusagt, wird im Projekt oft Individualaufwand. Verlässlicher sind zwei einfachere Prüfungen. Hinein: Kommen Anlagen- und Stücklistendaten ohne Abtippen ins Tool, und reicht dafür ein Excel- oder CSV-Export aus dem ERP? Hinaus: Gibt es eine dokumentierte API oder einen Export, über die Ergebnisse und Status ins Ticketsystem (Jira, ServiceNow) und in die eigenen Auswertungen fließen? Sind beide Wege offen, wird das Tool kein Silo, auch ohne Konnektor-Katalog.

2. Feldbasis: Auslieferungsstand plus Servicehistorie, kein Live-Inventar

An diesem Punkt scheitern die meisten Projekte; der Firmware-Abgleich aus Frage 3 ist technisch das leichtere Ende. Welche Firmware-Stände heute in den ausgelieferten Anlagen laufen, nach 15 Jahren Feldeinsatz, nach Retrofits und nach Vor-Ort-Updates des Betreibers, weiß der Anlagenbauer nicht. Nach der Auslieferung ist die Anlage in Betreiberhand, oft ohne Fernzugriff. Ein permanent aktuelles Feld-Inventar über 200 Anlagen und 15 Jahre ist eine Fiktion; ein Tool-Versprechen, das anderes suggeriert, sollte Sie skeptisch machen.

Belastbar ist der Auslieferungsstand: Ein Netzwerkscan bei der Abnahme (FAT) oder Inbetriebnahme hält fest, welche Komponenten mit welchem Firmware-Stand die Anlage tatsächlich verlassen haben. Danach ändert sich die Anlage aus Ihrer Sicht nur noch an den eigenen Berührungspunkten: Serviceeinsatz, Retrofit, Ersatzteillieferung. Drei Prüfpunkte im Auswahlgespräch:

• Wie kommt der Bestand initial ins Tool: aus ERP, PLM, Excel oder dem Hardware-Export des Engineering-Projekts (im TIA Portal der CAx-Export)? Welche Werkzeuge diese Erhebung abdecken, zeigt der Beitrag zu SBOM-Werkzeugen im Anlagenbau.
• Werden Serviceeinsatz, Retrofit und Komponententausch als Ereignisse nachgeführt, sodass der Datenstand mit jedem Kundenkontakt besser wird?
• Wird eine Baureihe als ein Modell gepflegt und bei vielen Kunden installiert, oder muss jede Anlage einzeln nachgezogen werden?

3. Firmware-Abgleich: welche Anlagen betroffen sind, nicht nur ob

Auf ein Advisory kann ein Tool auf zwei Ebenen antworten. Die erste lautet: „Für Produkt X gibt es eine Meldung." Schon das setzt voraus, dass es die Meldung überhaupt einem Ihrer Produkte zuordnet, und genau daran scheitern CPE-basierte Werkzeuge bei Lieferanten-Firmware (siehe oben). Die zweite Ebene spart die eigentliche Arbeit: welche Ihrer Anlagen die betroffene Version fahren.

Ein Beispiel. Ihr Lieferant meldet zu einem Sicherheits-Laserscanner: betroffen bis einschließlich Firmware 2.4.7, behoben ab 2.5.0. Das Gerät ist über acht Jahre in mehreren Baureihen verbaut und an rund 200 Betreiber ausgeliefert, teils mit 2.3.x, teils mit 2.4.x, ein Teil längst auf 2.6.x aktualisiert.

• Antwort auf der ersten Ebene: betroffen. Danach folgt die Handarbeit, aus 200 Anlagen die mit betroffener Firmware herauszusuchen.
• Antwort auf der zweiten Ebene: 140 Anlagen betroffen (Firmware 2.3.x–2.4.7), 60 nicht betroffen (bereits ≥ 2.5.0), aufgeschlüsselt nach Baureihe und Betreiber. Erst das ist eine Arbeitsliste für den Service.

Der Test in der Demo: Spielen Sie ein Advisory für eine real verbaute Komponente in einem bestimmten Versionsstand ein und sehen Sie sich an, was das Tool markiert: genau die betroffenen Anlagen und Baureihen oder nur den Produktnamen. Der Test dauert fünf Minuten und lässt sich bei jedem Anbieter wiederholen.

4. Betroffenheitsbewertung mit exportierbarer Begründung und VEX

KI-gestützte Triage beschleunigt die Arbeit, aber der CRA verlangt Dokumentation: Für jeden Treffer muss nachvollziehbar bleiben, auf welcher Grundlage (Komponente, Version, Quelle) entschieden wurde, und die Begründung muss sich fürs Audit exportieren lassen. Wichtiger als das „betroffen" ist für viele Anlagenbauer ohnehin das begründete „nicht betroffen" als maschinenlesbares VEX-Statement, das an Endkunden aus Automotive und Aerospace und deren eigene NIS2-Pflicht weitergereicht werden kann. Ein Mensch muss die KI-Einschätzung überstimmen können, revisionssicher mit Nutzer und Zeitstempel; die KI-Verarbeitung sollte in einer EU-Region laufen.

Meldepflichten und Betrieb

Seltener der Knackpunkt, aber Teil der Auswahl:

• Meldepflichten-Unterstützung. Fristen-Tracking über 24 h / 72 h / 14 Tage mit Eskalation und Vorbereitung für die ENISA-Meldeplattform, sauber getrennt zwischen Behördenmeldung und Kundeninformation.
• Betrieb und Wirtschaftlichkeit. EU-Datenresidenz, ein Betriebsmodell, das zur eigenen IT-Policy passt, und eine Preislogik, die zur Größe der eigenen Feldbasis passt.

Pilot mit zwei bis drei Anlagen statt Datenblatt-Vergleich

Am belastbarsten ist ein kurzer Pilot mit zwei bis drei echten Anlagen aus dem eigenen Bestand. An den eigenen Daten zeigt sich, ob die Integration trägt, ob die Feldbasis sauber abbildbar ist und ob der Firmware-Abgleich hält, was die Demo verspricht.

Der schnellste Einstieg: Bringen Sie die Stückliste einer einzigen Anlage mit, wir scannen sie auf offene Schwachstellen. Ein Excel-Export aus dem ERP reicht, es braucht keine SBOM und kein besonderes Format. Im Gespräch sehen Sie, welche Ihrer Komponenten offene Advisories haben und wo der Firmware-Stand über die Betroffenheit entscheidet, also den Abgleich aus Frage 3 an echten Daten. 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.