Beispielfall CRA: die Stückliste einer Steuerung aus vier Dateien, geprüft und meldebereit

1. Das Produkt und seine Dateien

Die erfundene Steuerung SE-200 in Version 4.2.0, ein Gerät mit Software: eine Bedienoberfläche, ein Java-Dienst, ein Ubuntu-Rechner und Zukaufteile. Für die Stückliste genügen Dateien, die es in Entwicklung und Fertigung ohnehin gibt. Die Vorführung liest sie im Browser; Ihre Dateien werden nicht hochgeladen.

In der Komponentenliste stehen FortiOS 7.2.5, GoAhead 2.5.0 und die Steuerungssoftware SE-Kern 4.2.0. Daraus entsteht die Stückliste mit 18 Bausteinen im Standardformat CycloneDX, jeder Baustein mit Version und, wo es sie gibt, seiner Kennung (purl), etwa pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1.

2. Was die Software prüft

Die Stückliste wird gegen den öffentlichen Katalog der Sicherheitslücken mit bekannter aktiver Ausnutzung der US-Behörde CISA abgeglichen, mit den Versionsangaben der GitHub Advisory Database und der offiziellen CVE-Datensätze. Die 9 Bausteine mit Paketkennung aus npm und Java prüft sie zusätzlich gegen alle geprüften Einträge der GitHub Advisory Database. Der Abgleich am 19.10.2026 ergibt:

Beide Kataloge werden zweimal täglich aktualisiert; die Vorführung zeigt jeweils den neuesten Stand, und gespeicherte Produkte werden bei jedem Öffnen neu abgeglichen.

3. Was an die Verantwortlichen geht

Oben im Ergebnis steht der Handlungsbedarf: „3 Bausteine enthalten Sicherheitslücken, für die eine aktive Ausnutzung bekannt ist.“ Darunter die drei Schritte, die jetzt anstehen:

• Prüfen und bewerten: Steckt der betroffene Baustein in Produkten, die bereits bei Kunden sind, und ist er dort aktiv? Für jede Lücke wird festgehalten: wird geprüft, betroffen, nicht betroffen, behoben oder Fehlalarm, mit Begründung.
• Melden: Die Meldefristen beginnen mit der Kenntnis einer aktiv ausgenutzten Schwachstelle im Produkt oder eines schwerwiegenden Sicherheitsvorfalls. Die Software hält den Kenntniszeitpunkt fest; die anschließende Bewertung setzt die Frist nicht neu in Gang. Der Knopf „Meldung vorbereiten“ zeigt die Fristen und eine Textvorlage.
• Beheben: Auf eine reparierte Version des Bausteins aktualisieren und das Update an die Kunden ausliefern.

Für log4j-core und CVE-2021-44228, mit Kenntnis am 19.10.2026 um 09:00 Uhr, rechnet die Software die Fristen:

Frühwarnung nach Art. 14 Abs. 2 Buchst. a Verordnung (EU) 2024/2847

Hersteller: Beispiel Maschinenbau GmbH (fiktiv), [Anschrift, Ansprechpartner, Kontakt]
Produkt mit digitalen Elementen: Steuerung SE-200 (fiktives Beispiel), Version 4.2.0
Betroffene Komponente: org.apache.logging.log4j:log4j-core@2.14.1 (pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1)
Schwachstelle: CVE-2021-44228 (Apache Log4j2)
Hinweis auf aktive Ausnutzung: im CISA-Katalog aktiv ausgenutzter Schwachstellen seit 2021-12-10; laut Katalog bei Erpressungsangriffen (Ransomware-Kampagnen) genutzt
Kenntnis erlangt am: 19.10.2026, 09:00

Mitgliedstaaten, in denen das Produkt bereitgestellt wurde (soweit bekannt): [ ]
Erste Einschätzung und Sofortmaßnahmen: [ ]

Gemeldet wird über die einheitliche Meldeplattform der EU, gleichzeitig an das zuständige CSIRT und die ENISA; die Vorlage übernimmt Produkt, Version, Baustein, Kennung und den Hinweis auf aktive Ausnutzung.

4. Warum hier feste Regeln entscheiden

Ob eine Version betroffen ist, ist eine Frage von Kennung und Versionsbereich. Dafür entscheiden feste Regeln, jedes Mal gleich und mit Beleg; dieses Modul arbeitet ohne KI.

• Betroffen heißt: Die Version liegt eindeutig im betroffenen Bereich, nach Versionsnummer oder nach den Versionsangaben des Herstellers.
• Bitte prüfen heißt: Zum Baustein gibt es eine aktiv ausgenutzte Lücke, und die Version wird mit der Beschreibung der Lücke oder dem Sicherheitshinweis der Distribution abgeglichen, weil Distributionen Korrekturen oft ohne neue Versionsnummer einspielen oder nur der Name eindeutig ist.
• Nicht betroffen heißt: Die Lücke passt zum Namen, betrifft aber nicht die verbaute Version, meist weil sie dort bereits repariert ist; solche Treffer stehen gesammelt unter dem Ergebnis.
• Jeder Treffer nennt seine Nummer, etwa CVE-2021-44228; ein Klick öffnet die offizielle Beschreibung.
• Der Katalog ist die tägliche feste Grundlage; die Meldepflicht umfasst jede aktiv ausgenutzte Schwachstelle, von der der Hersteller erfährt, auch aus eigenen Erkenntnissen oder Hinweisen von außen. Schwerwiegende Sicherheitsvorfälle erfasst Ihr Betrieb über „Vorfall erfassen“, mit eigenen Fristen und Vorlagen.

Ob und was gemeldet wird, entscheidet der Hersteller. Für die rechtliche Einordnung sind Ihre Fachanwälte der richtige Ansprechpartner; die Software liefert ihnen die technische Übersicht mit Belegen.

5. Das Ergebnis

• Die Stückliste der Steuerung SE-200 mit 18 Bausteinen als CycloneDX 1.6, zum Herunterladen.
• Die Stückliste mit Bewertungen (CycloneDX, VEX): je Lücke die Bewertung mit Begründung, Datum und Benutzer.
• Das gespeicherte Produkt in der Liste „Ihre Produkte“, mit Stand des Abgleichs, „Neu seit dem letzten Öffnen“ und Zahl der bewerteten Lücken.
• Alarm per E-Mail: Im Kundenbetrieb gleicht der Server nach jeder Aktualisierung des Katalogs alle gespeicherten Produkte ab und schreibt an bis zu fünf Empfänger, je Produkt höchstens eine E-Mail mit Produkt, Kennung, Schweregrad und Baustein.
• Schwerwiegende Sicherheitsvorfälle über „Vorfall erfassen“: Frühwarnung 24 Stunden, Vorfallmeldung 72 Stunden, Abschlussbericht binnen eines Monats nach der Vorfallmeldung, mit Vorlagen für jede Stufe und für die Information der Nutzer.

6. Woran der Pilot gemessen wird

Im Pilot läuft derselbe Ablauf mit den Dateien Ihrer Produkte, eingerichtet in fünf Werktagen. Ausgewertet werden:

• Vollständigkeit der Stückliste: wie viele Bausteine mit Version und Kennung aus Ihren Dateien kommen und was in die Komponentenliste gehört, etwa Firmware von Zulieferern;
• Treffer je Produkt: betroffen, bitte prüfen und weitere bekannte Lücken, jeweils mit Ihrer Bewertung;
• der Weg zur Meldung: von der Kenntnis bis zur ausgefüllten Vorlage der Frühwarnung, mit Zuständigkeiten in Ihrem Haus;
• der laufende Betrieb: Alarm per E-Mail, Empfänger und Stufe, passend zu Ihren Produkten.

Danach entscheiden Sie über die Vollversion.

Mit Ihren Unterlagen

• Im Pilot entstehen die Stücklisten Ihrer Produkte aus Abhängigkeitsdateien der Software, Paketlisten der Geräte und Ihrer Komponentenliste; fest einkopierte Bibliotheken und Zukaufteile ergänzt die Komponentenliste.
• Im Kundenbetrieb speichert die Software Produkte, Stücklisten und Bewertungen je Kunde getrennt auf dem Server, mit Protokoll.
• Weitere Quellen wie die europäische Schwachstellendatenbank (EUVD), die Anbindung an Build und Jira und englische Meldetexte für die ENISA-Meldeplattform kommen nach Wunsch dazu, zum Festpreis.

Vorführung anfragen