Warum die meisten CRA-Tools am Long-Tail scheitern: worauf Anlagenbauer bei der Tool-Auswahl achten sollten

Die meisten Werkzeuge fürs Schwachstellenmanagement sind für Software-Hersteller gebaut, die ihren Code selbst schreiben. Ein Anlagenbauer arbeitet unter anderen Vorzeichen: Sein Risiko steckt fast vollständig in zugekaufter Firmware, verteilt über einen langen Schwanz von Lieferanten. Ein Tool, das für den ersten Fall gebaut ist, löst diesen zweiten nicht automatisch mit.

Werkspilot ist für genau diesen zweiten Fall gebaut. Die vier Auswahlfragen unten sind trotzdem neutral gehalten – sie taugen, um jeden Anbieter zu prüfen, uns eingeschlossen.

Warum „CRA-Schwachstellenmanagement" zwei Aufgaben meint

Die Fristen und Pflichten selbst behandelt ein eigener Beitrag ausführlich – ab dem 11. September 2026 greift die Meldepflicht nach Artikel 14 des Cyber Resilience Act. In der Tool-Diskussion geht dagegen meist unter, dass „CRA-Schwachstellenmanagement" je nach Fragesteller zwei recht unterschiedliche Aufgaben bezeichnet.

Ein Software-Hersteller baut sein Produkt selbst. Seine Schwachstellen stecken in Open-Source-Bibliotheken, die er in seinem Build zieht. Dafür gibt es einen reifen Werkzeugkasten: SCA, SBOM-Erzeugung aus dem Build, Abgleich gegen CVE-Datenbanken, VEX zur Statusaussage. Viele Anlagenbauer haben genau diesen Teil, ihre eigene Softwareentwicklung, bereits gut im Griff, etwa mit Dependency-Track.

Ein Anlagenbauer baut sein Produkt zum größten Teil aus Zukaufteilen. Eine Verpackungsmaschine, eine Fördertechnik-Anlage, eine Sondermaschine besteht aus SPS, HMI, Antrieben, 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. Das Risiko sitzt überwiegend in fremder Firmware, die über eine Feld-Lebensdauer von 15 bis 20 Jahren beobachtet sein will.

Für den Anlagenbauer lautet die Kernfrage damit anders: Wie erfahren Sie von einer Schwachstelle in einer zugekauften Komponente, und woher wissen Sie, welche Ihrer ausgelieferten Anlagen konkret betroffen sind? Viele Anlagenbauer haben beide Baustellen, die eigene Entwicklung und den Zukauf. Ein Werkzeug, das nur die erste bedient, hilft bei der zweiten wenig.

Das Long-Tail-Problem und eine Zahl dazu

Ein Beispiel aus der eigenen Feed-Auswertung, das die Größenordnung greifbar macht: Eine Auswertung des öffentlichen CSAF-/ROLIE-Feeds eines einzigen großen Sensorherstellers ergab rund 258 distinct CVEs über 71 Advisories, und das ist ein Lieferant, der es vorbildlich macht: maschinenlesbar, automatisiert einlesbar, sauber gepflegt. Jetzt multiplizieren Sie diesen einen gut geführten Feed mit dem gesamten übrigen Lieferantenstamm einer Anlage, und ziehen Sie ab, was gar keinen Feed bereitstellt.

Denn genau da liegt die operative Arbeit. Die großen OT-Hersteller stellen zunehmend maschinenlesbare Advisory-Feeds im CSAF-2.0-Format bereit. Das ist die Spitze des Portfolios, nicht die Masse. Der Long-Tail, also die vielen kleineren Komponentenlieferanten, verschickt Advisories weiterhin per PDF, per E-Mail an einen Verteiler oder veröffentlicht sie verstreut auf der eigenen Website. Aggregatoren wie CERT@VDE füllen einen Teil der Lücke, aber eben nicht die ganze. Hier ist der Deckungsgrad eines Tools am schwersten zu beurteilen und zugleich am wichtigsten.

Binäranalyse oder advisory-zentriert?

Für unterschiedliche Ansätze gibt es gute Gründe. Eine Binäranalyseist 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, also Herstellermeldungen plus Aggregatoren plus aktive Long-Tail-Erfassung, ist stark, wenn das Risiko über viele Zukauf-Lieferanten verteilt ist und es auf lückenlose Abdeckung ankommt. Für den typischen Anlagenbauer mit wenig eigenem Code und breitem Lieferantenstamm ist genau diese Abdeckung meist das dringendere Problem. Diese Abwägung sollten Sie an Ihrem eigenen Portfolio treffen, nicht ein Anbieter für Sie.

Vier Fragen, an denen sich die Tools unterscheiden

Die folgende Reihenfolge entspricht der Priorität aus Sicht des Serien- und Sondermaschinenbaus. Im Einzelfall kann sie anders aussehen, aber diese vier Fragen sollten in jeder Evaluierung vorkommen. Keine davon lässt sich am Datenblatt beantworten.

1. Integration, oder wird es ein weiteres Datensilo?

Der teuerste Fehlkauf ist ein Tool, das neben der zentralen Datenplattform steht und von Hand gepflegt werden muss. Fragen Sie deshalb konkret nach: Zieht das Tool Anlagen- und Stücklistendaten über einen Standard-Konnektor aus PLM/ERP, oder pflegen Sie die installierte Basis manuell? Gibt es eine dokumentierte API, die Ergebnisse und Status in die zentrale Plattform und ins Ticketsystem (Jira, ServiceNow) zurückschreibt? Und lässt sich eine Referenzintegration zeigen, statt nur ein Individualprojekt in Aussicht zu stellen?

2. Die Feldbasis: kommt sie sauber ins Tool, und bleibt sie aktuell?

Das ist der oft unterschätzte, eigentlich harte Teil, und der, an dem die meisten Projekte scheitern. Der Firmware-Abgleich (Frage 3) ist technisch das leichtere Ende. Die schwierige Frage kommt davor: Wissen Sie überhaupt, welche Firmware-Stände heute in Ihren ausgelieferten Anlagen laufen, nach 15 Jahren Feldeinsatz, nach Retrofits, nach Vor-Ort-Updates, die der Betreiber selbst gemacht hat?

• Wie kommt die Bestands-Feldbasis initial ins Tool, aus ERP, PLM, Excel? Mit welchem realistischen Aufwand?
• Wie wird ein Firmware-Update oder Komponententausch an einer Feld-Anlage nachgeführt, damit der Datenbestand nicht nach zwei Jahren zur Fiktion wird?
• Bildet das Tool die Serien-Logik ab, also eine Baureihe als ein Modell gepflegt und bei vielen Kunden installiert, oder muss jede Anlage einzeln nachgezogen werden?

Ein Tool ist nur so gut wie die Datenqualität, die es füttert. Wer das im Auswahlgespräch überspringt, kauft eine Betroffenheitsanalyse auf Basis veralteter Stände.

3. Firmware-Abgleich: der Test, den Sie selbst durchführen können

Fast jedes Tool kann sagen: „Für Produkt X existiert ein CVE." Das ist wenig wert, wenn Sie eine große installierte Basis haben und nicht wissen, welche Anlagen Produkt X in genau der betroffenen Version verbaut haben.

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

• Ein Tool, das nur „CVE existiert für Produkt X" kann, meldet Ihnen: betroffen. Davor steht dann die eigentliche Arbeit, nämlich herauszufinden, welche der 200 Anlagen die Firmware in einer betroffenen Version fahren, von Hand.
• Ein Tool, das den Firmware-Abgleich beherrscht, meldet stattdessen: 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 zweite Ergebnis ist eine Arbeitsliste, mit der der Service etwas anfangen kann. Der Test in der Demo: Spielen Sie ein Advisory für eine real verbaute Komponente in einem bestimmten Versionsstand ein und beobachten Sie, was das Tool tut. Markiert es genau die betroffenen Anlagen und Baureihen, oder meldet es nur, dass irgendwo ein CVE für Produkt X existiert? Führen Sie diesen Test bei jedem Anbieter durch. Er kostet fünf Minuten und trennt die Werkzeuge, die Ihr Problem lösen, von denen, die nur CVEs auflisten.

4. Nachvollziehbare Betroffenheitsbewertung inklusive VEX

KI-gestützte Triage beschleunigt die Arbeit, aber der CRA verlangt Dokumentation. Eine Bewertung, die Sie im Audit nicht begründen können, hält der Prüfung nicht stand. Und für viele Anlagenbauer ist die wichtigere Ausgabe ohnehin nicht „betroffen", sondern das begründete „nicht betroffen", als VEX-Statement, das Sie Ihren Endkunden (oft aus Automotive und Aerospace) und deren eigener NIS2-Pflicht weiterreichen können.

• Ist für jeden Treffer nachvollziehbar, auf welcher Grundlage (Komponente, Version, Quelle) entschieden wurde, und ist die Begründung fürs Audit exportierbar?
• Erzeugt das Tool maschinenlesbare VEX-Statements, die Sie kontrolliert mit Endkunden teilen können?
• Kann ein Mensch die KI-Einschätzung überstimmen, revisionssicher mit Nutzer und Zeitstempel? Läuft die KI-Verarbeitung in einer EU-Region?

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.

Der praktische Rat: testen, nicht am Datenblatt evaluieren

Die vier Fragen lassen sich nicht am Datenblatt beantworten. Der belastbarste Weg ist ein kurzer Pilot mit zwei bis drei echten Anlagen aus dem eigenen Bestand. Dann zeigt sich an den eigenen Daten, ob die Integration trägt, ob die Feldbasis sauber abbildbar ist und ob der Firmware-Abgleich hält, was die Demo verspricht.

Am schnellsten wird das konkret, wenn Sie den Firmware-Test aus Frage 3 direkt an den eigenen Daten durchspielen: Bringen Sie ein reales Advisory einer verbauten Komponente mit, wir spielen es an Ihrer Feldbasis durch und zeigen, welche Anlagen und Baureihen in welchem Versionsstand betroffen sind. Bringen Sie ein Advisory 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.