Der Inhalt dieser Seite wurde automatisch von einem Drittanbieter übersetzt.

Die meisten Beiträge über den EU Cyber Resilience Act (CRA) behandeln ihn als ein technisches Cybersicherheitsproblem: Security-by-Design-Prinzipien, Fristen für die Meldung von Schwachstellen und eine Software-Stückliste (SBOM), die bei Bedarf im CycloneDX- oder SPDX-Format erstellt werden können.

Ich verstehe, warum dieser Ansatz naheliegt. Sicherheitsteams sind es gewohnt, Compliance-Vorgaben zu verantworten, und die Erstellung einer SBOM wirkt wie ein lösbares Toolproblem. Man lässt einen Scanner über die Build-Pipeline laufen, erhält eine maschinenlesbare Ausgabe und legt sie ab.

Aber eine SBOM ist eine Aussage über Ihre Stückliste. Sie ist kein Ersatz dafür.

Der schwierigere Teil beginnt, wenn etwas schiefgeht. Eine neu identifizierte Schwachstelle muss bis zu der betroffenen Komponente oder Software und anschließend zu den Konfigurationen und Produktvarianten zurückverfolgt werden, in denen sie verwendet wird. Entscheidungen und Änderungen von Lieferanten spielen dabei ebenfalls eine Rolle. Ebenso Produkte, die bereits auf dem Markt sind.

Plötzlich erscheint die Erstellung der SBOM als der einfache Teil.

Der CRA behandelt Produktsicherheit als dauerhafte Verpflichtung, nicht als einmalige Aufgabe zum Marktstart

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist eine EU-Verordnung für „Produkte mit digitalen Elementen“, darunter Hardware, Software und Produkte, die beides kombinieren und auf dem EU-Markt angeboten werden. Er trat am 10. Dezember 2024 in Kraft.

Grundsätzlich verpflichtet der CRA Hersteller dazu, Cybersicherheit bereits in der Entwicklungsphase zu berücksichtigen, Informationen über Produktkomponenten und Schwachstellen zu pflegen, Schwachstellen nach dem Inverkehrbringen eines Produkts zu behandeln und Meldepflichten einzuhalten, wenn bestimmte Sicherheitsprobleme auftreten.

Die Verpflichtungen treten nicht alle gleichzeitig in Kraft. Die Meldepflichten gelten ab dem 11. September 2026. Die vollständigen Anforderungen an die Compliance, einschließlich der CE-Kennzeichnung, gelten ab dem 11. Dezember 2027.

Bei Nichteinhaltung können erhebliche Sanktionen drohen.

Die operative Herausforderung beginnt jedoch viel früher. Hersteller müssen wissen, was in einem Produkt enthalten ist, und diese Informationen so aktuell halten, dass sie auf ein Sicherheitsproblem reagieren können, sobald es auftritt.

Aus dieser Perspektive ist der CRA auch eine Herausforderung für Produktdaten und Rückverfolgbarkeit.

Die Uhr läuft ab diesem Monat, nicht erst ab 2027

Die Frist für die vollständige Einhaltung des CRA, einschließlich CE-Kennzeichnung und Konformitätsbewertung, ist der 11. Dezember 2027. Dieses Datum bleibt den meisten im Gedächtnis, weshalb die Verordnung noch immer in komfortabler Ferne zu liegen scheint.

Doch die Meldepflichten beginnen bereits am 11. September 2026.

Bei bestimmten aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen sehen die Fristen eine Frühwarnung innerhalb von 24 Stunden und eine ausführlichere Meldung innerhalb von 72 Stunden vor.

Überlegen Sie, was innerhalb dieser 72 Stunden geschehen muss. Woher stammt die betroffene Komponente? In welchen Konfigurationen wird sie verwendet? Hat ein Lieferant sie geändert? Welche bereits freigegebenen Produkte sind betroffen?

Es bleibt nicht viel Zeit, um nach diesen Antworten zu suchen.

Genau diese Unterscheidung geht meiner Ansicht nach verloren, wenn der CRA hauptsächlich als SBOM-Problem dargestellt wird. Eine SBOM zeigt, was Ihren Systemen zufolge im Produkt enthalten ist. Sobald eine Schwachstelle entdeckt wird, ist die umgebende Produktdefinition genauso wichtig.

Können Sie die betroffene Komponente oder Softwareabhängigkeit mit dem richtigen Release verknüpfen? Mit der richtigen Konfiguration? Mit der zugrunde liegenden Lieferantenentscheidung? Und können Sie feststellen, welche Produkte tatsächlich auf den Markt gelangt sind?

An diesem Punkt wird Rückverfolgbarkeit praktisch statt theoretisch.

Eine SBOM ist nur so genau wie die zugrunde liegende Produktdefinition

Eine Software Bill of Materials muss aus etwas erzeugt werden.

Das wird schnell kompliziert, wenn die Stückliste in einem System gepflegt wird, während sich die Fertigungsstückliste in einem anderen weiterentwickelt hat. Lieferanteninformationen befinden sich möglicherweise in einer E-Mail. Manche Änderungen wurden vielleicht nie sauber in den kontrollierten Produktdatensatz zurückgeführt.

Die SBOM übernimmt diese Lücken. Maschinenlesbar bedeutet nicht zwangsläufig vollständig.

In der Elektronikfertigung wird dieses Problem besonders deutlich. PCBA-Daten werden nachgelagert häufig noch immer als Teilenummer zusammen mit einem Paket von Fertigungsdateien weitergegeben, während Konstruktionsabsicht, freigegebene Bezugsquellen, Substitutionen und Fertigungsentscheidungen an anderer Stelle verwaltet werden.

Dann greift die Realität ein.

Eine Komponente ist nicht mehr verfügbar. Eine Alternative wird qualifiziert. Ein Lieferant trifft eine andere Entscheidung, um die Produktion am Laufen zu halten.

Später stellt sich die Frage, ob überhaupt jemand nachvollziehen kann, was passiert ist. Wurde die Substitution in den Produktdatensatz zurückgeführt? Können Engineering, Fertigung, Compliance und Sicherheit die Entscheidung sehen und verstehen, wo sie gilt?

Bei Software besteht dasselbe Problem in anderer Form. Firmware-Versionen ändern sich. Open-Source-Abhängigkeiten entwickeln sich weiter. Konfigurationen driften auseinander. Von Lieferanten bereitgestellte Software kann sich unabhängig von der mechanischen oder elektrischen Definition weiterentwickeln.

Im Laufe der Zeit kann sich das Produkt auf dem Markt erheblich von der Produktdefinition unterscheiden, von der das Unternehmen glaubt, dass sie gültig ist.

Hier ist ein hilfreicher Test: Identifizieren Sie eine Schwachstelle in einer Komponente oder Softwareabhängigkeit und versuchen Sie, innerhalb von 72 Stunden jedes betroffene Produkt, jede Konfiguration und jede Variante zu ermitteln. Belegen Sie anschließend das Ergebnis.

Bei vielen Herstellern wird diese Übung Probleme aufdecken, die wenig mit dem Scannen nach Schwachstellen zu tun haben.

Compliance, die erst bei der Freigabe zusammengestellt wird, hält dem Zeitdruck eines Vorfalls nicht stand

In regulierten Fertigungsbranchen ist ein bekanntes Muster, den Compliance-Status kurz vor einer Produktfreigabe zu rekonstruieren. Jemand trägt Informationen aus Engineering-Systemen, Lieferantenerklärungen, Tabellen, E-Mails und dem ERP-System zusammen. Die Nachweise werden zusammengestellt und geprüft, und das Produkt kann freigegeben werden.

Das ist umständlich. Es kann aber funktionieren, solange das Unternehmen die Frist selbst kontrolliert.

Bei einem Vorfall ist das anders.

Eine Schwachstelle kann morgen früh veröffentlicht werden. Ein Lieferant kann Monate nach der Auslieferung von Produkten ein Problem feststellen.

Dann läuft die Uhr bereits.

Die Beziehungen zwischen Produkt, Komponente, Software, Konfiguration, Änderung und Lieferantennachweisen müssen verfügbar sein. Sie unter Zeitdruck zu rekonstruieren, ist keine besonders tragfähige Strategie.

Hier legt der CRA ein Problem offen, mit dem Hersteller seit Jahren leben. Fragmentierte Produktdaten verursachen Nacharbeit, verlangsamen Entscheidungen, erschweren das Änderungsmanagement und machen Compliance aufwendiger.

Nun entsteht daraus ein weiteres Risiko. Die Frist kann von außerhalb des Unternehmens vorgegeben werden.

Rückverfolgbarkeit über den gesamten Lebenszyklus ermöglicht eine schnelle Reaktion. Die SBOM zeigt, was vorhanden sein sollte. Rückverfolgbarkeit hilft dabei zu beantworten, was damit geschehen ist: wo etwas verwendet wurde, was sich geändert hat, welche Konfiguration freigegeben wurde und welche Lieferantennachweise die Entscheidung gestützt haben.

Diese Verbindungen sind entscheidend, sobald die Meldefrist zu laufen beginnt.

Hier wird der digitale Faden praktisch

Der digitale Faden wird seit Jahren im Zusammenhang mit effizienterem Engineering, besserer Zusammenarbeit und fundierteren Entscheidungen diskutiert. Der CRA gibt ihm eine wesentlich unmittelbarere Aufgabe.

Es muss möglich sein, eine schwierige Frage zu einem Produkt zu stellen und die Antwort über den gesamten Lebenszyklus hinweg nachzuverfolgen, ohne die Historie von Grund auf neu rekonstruieren zu müssen.

Das bedeutet nicht, dass alles in einem einzigen riesigen System gespeichert werden muss. Für die meisten Unternehmen ist das weder realistisch noch notwendig.

Es bedeutet jedoch, die Verbindungen aufrechtzuerhalten. Eine Hardwareänderung kann sich auf eine Konfiguration auswirken. Eine Lieferantenentscheidung kann eine freigegebene Bezugsquelle verändern. Software kann sich unabhängig weiterentwickeln und dennoch zu einem bestimmten freigegebenen Produkt gehören. Auch die Nachweise hinter diesen Entscheidungen müssen miteinander verbunden bleiben.

PLM, MBSE, MBE, Software-Lifecycle-Management, ERP, Lieferantensysteme und Sicherheitstools spielen dabei jeweils eine Rolle. Die größere Frage ist, was zwischen diesen Systemen passiert.

Bleiben diese Beziehungen intakt, während sich das Produkt verändert?

Der CRA bietet eine ziemlich unerbittliche Möglichkeit, das herauszufinden.

Die Arbeit, die der CRA tatsächlich verlangt

Nichts davon ist als Rechts- oder Compliance-Beratung zu verstehen. Entscheidungen zur Klassifizierung, Verfahren zur Konformitätsbewertung und konkrete Meldepflichten sollten mit qualifizierten Rechts- und Compliance-Fachleuten geklärt werden und nicht anhand eines Blogbeitrags eines Anbieters.

Für Engineering-Organisationen wirft der CRA jedoch eine praktische Frage auf: Können die Produktdaten innerhalb einer strikten Frist eine schnelle Antwort ermöglichen?

Die meisten Inhalte zum CRA konzentrieren sich darauf, was die Verordnung verlangt. Es gibt noch eine andere Frage, die sich jetzt zu stellen lohnt, bevor die Frist eintritt.

Wie müssen Engineering-Daten aussehen, damit eine solche Reaktion möglich ist?

Der Unterschied könnte darüber entscheiden, ob eine 72-Stunden-Meldung auf Basis kontrollierter Informationen erstellt werden kann oder zu einer hektischen Suche in E-Mails und Tabellen sowie zu Telefonaten und dem Rückgriff auf das Gedächtnis einzelner Personen führt.

Die Sicherheitstools sorgen für Schlagzeilen. Die kontrollierte Produktdefinition und die Rückverfolgbarkeit rund um diese Daten sorgen dafür, dass diese Tools tatsächlich nützlich sind.

Empfohlene Maßnahmen

Für keine dieser Maßnahmen ist ein vollständig ausgearbeitetes CRA-Compliance-Programm erforderlich. Es sind Fragen, die vor der nächsten Frist beantwortet werden sollten, nicht danach.

  • Erfassen Sie, was tatsächlich in den Anwendungsbereich fällt. Identifizieren Sie die Produktlinien, die gemäß CRA als „Produkte mit digitalen Elementen“ gelten und für die eine sorgfältig gepflegte SBOM erforderlich wäre. Diese Klassifizierung gehört in die Verantwortung von Compliance und Rechtsberatung und nicht allein ins Engineering.
  • Finden Sie heraus, wo Ihre Stückliste tatsächlich verwaltet wird. Gibt es eine einzige kontrollierte BOM, die mit Compliance- und Lieferantendaten verbunden ist, oder mehrere Versionen, die sich in ECAD, ERP und Tabellen auseinanderentwickelt haben und seit einiger Zeit niemand mehr abgeglichen hat?
  • Suchen Sie nach Substitutionen, die nicht dokumentiert wurden. Fragen Sie Lieferanten und Fertigungspartner direkt, ob Komponentensubstitutionen den Änderungsprozess durchlaufen haben oder einfach ausgeliefert wurden. Eine ehrliche Antwort ist hilfreicher als eine beruhigende.
  • Führen Sie den 72-Stunden-Test jetzt durch, ohne den Druck eines tatsächlichen Vorfalls. Wählen Sie ein Produkt aus und prüfen Sie, wie lange es dauert, eine bestimmte Komponente oder Softwareabhängigkeit zu jedem betroffenen Produkt, jeder Konfiguration und jeder Variante zurückzuverfolgen. Prüfen Sie anschließend, welche Nachweise die Antwort stützen. Wenn die Rückverfolgung vom Posteingang, einer Tabelle oder dem Gedächtnis einer Person abhängt, ist genau das Teil des Problems, das dieser Test aufdecken soll.
  • Behandeln Sie Compliance- und Lieferantendaten als Teil des Produktdatensatzes. Unabhängig davon, auf welchen Plattformen die Engineering-Daten gespeichert sind, sollten die Beziehungen zwischen Produktdefinition, freigegebenen Bezugsquellen, Compliance-Status, Lieferantennachweisen, Änderungen und freigegebenen Konfigurationen erhalten bleiben. So wird die Dokumentation zu einem Nebenprodukt der täglichen Arbeit und nicht zu einem Projekt, das vor jeder Freigabe oder Reaktion auf einen Vorfall neu rekonstruiert werden muss.

Einen tieferen Einblick darin, wie Lieferkettenvolatilität, domänenübergreifende Änderungen und steigende Anforderungen an Nachweise für High-Tech- und Elektronikhersteller zusammenwirken, einschließlich des Digitalen Produktpasses (DPP) und speziell des CRA, bietet der ergänzende Beitrag Von fragmentierten Daten zu High-Tech-Resilienz.

Category:
Aras Insights Digital Engineering Digital Thread