Ein Händler schreibt eine E-Mail und bittet um Ihre Konformitätserklärung. Sie geht an den Vertrieb, der sie an den Produktmanager weiterleitet, der sie an die Entwicklungsabteilung weiterleitet, wo sie stecken bleibt. Das Gerät wird seit vier Jahren ausgeliefert. Die Firmware wird auf dem Rechner eines einzelnen Entwicklers gebaut. Niemand hat eine Bestandsaufnahme dessen, was darin enthalten ist, der Update-Mechanismus wurde aus v1 herausgenommen, um einen Markteinführungstermin einzuhalten, und die Person, die den Bootloader geschrieben hat, ist 2023 gegangen.
Nichts davon war fahrlässig. Es war normal, und es war völlig in Ordnung – bis zu dem Moment, in dem jemand in der Wertschöpfungskette eine Antwort in schriftlicher Form brauchte.
Der EU Cyber Resilience Act ist das, was sich geändert hat. Es handelt sich um eine Marktzugangsverordnung, nicht um einen Leitfaden für bewährte Sicherheitspraktiken: Produkte mit digitalen Elementen, die in die EU verkauft werden, müssen dessen Anforderungen erfüllen, und die Pflichten liegen beim Hersteller über die gesamte Lebensdauer des Produkts hinweg und nicht bei einem einmalig ausgestellten Zertifikat.
In diesem Artikel geht es um die technischen Konsequenzen – was sich durch die CRA-Konformität tatsächlich daran ändert, wie Firmware entwickelt, aktualisiert und dokumentiert wird, und wie man beurteilt, ob das eigene Team dies zusätzlich zur Roadmap bewältigen kann. Wenn Sie noch am Anfang stehen und erst herausfinden, wie die Software selbst erstellt wird, beginnen Sie mit dem Leitfaden zur Entwicklung eingebetteter Software.
- First important point
- Second important point
- Third important point
Was CRA-Konformität für einen Gerätehersteller tatsächlich bedeutet
Die Europäische Kommission beschreibt eine Verordnung, die verbindungsfähige Hardware und Software abdeckt — ihre eigenen Beispiele reichen von Babyfonen und Smartwatches bis hin zu Apps und Computerprogrammen — und sie verpflichtet die Hersteller, die Cybersicherheit durch die Planung, das Design, die Entwicklung und die Wartung des Produkts zu berücksichtigen sowie Schwachstellen über dessen gesamten Lebenszyklus hinweg zu behandeln. Produkte tragen die CE-Kennzeichnung, um die Konformität nachzuweisen, und Kategorien mit höherem Risiko erfordern vor dem Verkauf eine Bewertung durch Dritte in Form einer benannten Stelle.
Lies das als Ingenieur und nicht als Anwalt, dann ergeben sich drei Dinge.
Es knüpft am Prozess an, nicht an der Veröffentlichung. „Planung, Entwurf, Entwicklung und Wartung“ umfasst den gesamten Lebenszyklus. Eine Konformitätsübung, die im letzten Sprint vor dem Start durchgeführt wird, kann einen Prozess beschreiben; sie kann ihn nicht rückwirkend schaffen.
Es geht nach dem Versand weiter. Der Umgang mit Schwachstellen über den gesamten Lebenszyklus bedeutet, dass die Verpflichtung bei einem vor drei Jahren verkauften Produkt weiterhin besteht. Das ist die Anforderung, die am ehesten unterschätzt wird, weil sie einmalige Projektkosten in laufende Betriebskosten verwandelt.
Es gilt für das, was Sie verkaufen, einschließlich dessen, was Sie nicht geschrieben haben. Ein Gerät besteht größtenteils aus dem Code anderer Leute — einem RTOS, einem TCP/IP-Stack, einer Krypto-Bibliothek, einem Hersteller-BSP, einem Dutzend Open-Source-Komponenten, die durch den Build eingebunden werden. Die Verpflichtung, Schwachstellen zu behandeln, unterscheidet nicht zwischen dem Code, den Sie selbst verfasst haben, und dem Code, den Sie ausgeliefert haben.
Die drei Termine, die Ihren Zeitplan festlegen
Das mittlere Datum ist dasjenige, das Teams unvorbereitet trifft. Die Berichtspflicht tritt mehr als ein Jahr vor den Hauptverpflichtungen in Kraft, und die Berichterstattung ist keine Dokumentationsaufgabe — man kann eine aktiv ausgenutzte Schwachstelle in seinem Produkt nicht melden, wenn nicht etwas darauf achtet, jemand die Entscheidung verantwortet und es einen Weg gibt, den Fix auszuliefern. In der Praxis erfordert das September-Datum die Maschinerie, die das Datum im Dezember 2027 formell verlangt.
Ausgehend von einem Produkt mit einem zweijährigen Hardware-Zyklus werden die Architekturentscheidungen, die dies erschwinglich machen, jetzt getroffen – im Design dessen, was auch immer Sie dieses Jahr begonnen haben.
Die Anforderungen des Cyber Resilience Act, die Ihre Firmware verändern
Vier Dinge bewegen sich von „wir sollten“ zu „wir müssen“, und jedes einzelne ist eine Architekturentscheidung und kein Feature.
Ein signierter Update-Pfad, der sicher fehlschlagen kann
Eine Verpflichtung, Schwachstellen über die gesamte Lebensdauer eines Produkts hinweg zu behandeln, ist eine Verpflichtung, einen Fix ausliefern zu können, was bedeutet, dass der Mechanismus für Firmware-Updates über die Luftschnittstelle nicht länger optional ist. Der technische Inhalt ist konkret: Secure Boot, damit das Gerät nur von Ihnen signierte Firmware ausführt, Integritätsprüfung des Images und Rollback-Schutz, sodass ein halb angewendetes Update auf einem Gerät im Keller eines Kunden ein funktionierendes Produkt hinterlässt und keinen Briefbeschwerer. Bereits im Feld befindliche Produkte ohne diese Eigenschaften sind der schwierige Fall, denn der Update-Mechanismus selbst muss über einen Kanal ankommen, der noch nicht existiert.
Eine Bestandsaufnahme dessen, was Sie tatsächlich versenden
Der Umgang mit Schwachstellen in Komponenten, die Sie nicht selbst geschrieben haben, setzt voraus, dass Sie wissen, welche Komponenten Sie ausgeliefert haben, in welcher Version, in welchem Firmware-Image, auf welchen Geräten. Die meisten Teams können dies mit einem Arbeitsaufwand von einer Woche rekonstruieren, aber nicht auf Abruf neu generieren – und genau das ist der entscheidende Unterschied, denn die Offenlegung einer Schwachstelle in einer weit verbreiteten Bibliothek ist eine Frage, die Sie innerhalb von Stunden beantworten, immer wieder, über Jahre hinweg. Der praktische Test besteht darin, ob Ihr Build dieses Inventar automatisch erzeugt oder ob eine Person es zusammenstellt.
Schwachstellenbehandlung als laufender Prozess
Irgendjemand muss die Offenlegungs-Feeds gegen Ihre Komponentenliste überwachen, priorisieren, was auf Ihr Produkt zutrifft, und entscheiden, was ausgeliefert wird und wann. Dies ist die Verpflichtung, die die Struktur eines Entwicklungsteams am stärksten verändert, denn sie ist kontinuierlich und konkurriert direkt mit der Roadmap-Arbeit. Es ist auch diejenige, bei der die ehrliche Antwort für viele Produktunternehmen lautet, dass ein solcher Prozess heute nicht existiert.
Dokumentation, die die Menschen überdauert, die sie geschrieben haben
Die Konformität beruht darauf, nachweisen zu können, wie das Produkt entworfen wurde, was bewertet wurde und was entschieden wurde. Das ist ein anderes Artefakt als ein einmal gezeichnetes Architekturdiagramm — es handelt sich um eine Dokumentation, die parallel zum Code aktuell gehalten wird, was eher eine Disziplin als ein Liefergegenstand ist. Eingebettete Software Sicherheitsarbeit hat die Angewohnheit, in den Köpfen von zwei Personen zu leben; diese Anforderung ist es, die sie aus ihnen herauszwingt.
Welche Produkte fallen in den Anwendungsbereich, und wer trägt die Verpflichtung
Der Anwendungsbereich ist breiter, als die meisten Hardware-Teams beim ersten Lesen annehmen. Er beschränkt sich nicht auf Produkte, die als Sicherheitsgeräte vermarktet werden, und er beschränkt sich nicht auf Konsumgüter – der Prüfmaßstab ist, ob das Produkt digitale Elemente aufweist und sich verbinden kann, was den Großteil dessen abdeckt, was Hersteller von Industrie-, Medizin- oder Konsumgeräten derzeit ausliefern.
Die Verpflichtung liegt beim Hersteller. Das ist für zwei Situationen wichtig, die ständig auftreten:
- Sie haben die Firmware von jemand anderem erstellen lassen. Die Verpflichtung liegt trotzdem bei Ihnen. Ein Entwicklungsvertrag, der mit der Lieferung endet, lässt Sie mit einer Lebenszykluspflicht zurück, der keine technische Kapazität zugeordnet ist – eine Frage des Leistungsumfangs, die vor dem Vertrag zu klären ist, nicht danach.
- Sie verkaufen über einen Vertriebspartner in die EU. Die Anforderungen müssen entlang der gesamten Wertschöpfungskette erfüllt werden, sodass die Anfrage letztendlich bei Ihrem Engineering-Team ankommt, unabhängig davon, wer das Gerät verkauft hat.
Für Produktkategorien mit höherem Risiko ist vor dem Verkauf eine Bewertung durch eine benannte Stelle als Drittpartei erforderlich, was einem Zeitplan, der bereits Hardware enthält, eine externe Abhängigkeit mit eigener Vorlaufzeit hinzufügt.
Kann Ihr Team dies intern bewältigen?
Das ist die eigentliche Frage, und sie ist keine Frage der Kompetenz. Die meisten Embedded-Teams können Secure Boot und einen Update-Pfad umsetzen; viele haben beides bereits umgesetzt. Die Frage ist die der Kapazität und Kontinuität, und sie lässt sich in vier ehrliche Prüfungen auflösen.
Können Sie Ihr Komponenteninventar heute auf Abruf neu generieren? Wenn die Antwort eine Person und eine Tabellenkalkulation umfasst, liegt die Lücke im Tooling, und Tooling ist die günstigste der vier Lücken, die es zu schließen gilt.
Verfügt ein im Feld eingesetztes Produkt über einen funktionierenden Update-Pfad? Falls nicht, ist die Arbeit keine Compliance-Arbeit — es handelt sich um ein Firmware-Projekt mit einer Bootloader-Änderung, einer Signierungsinfrastruktur und einem Rollout-Plan, und es muss als solches geplant werden.
Wer trägt die Verantwortung, wenn eine Offenlegung an einem Freitag eintrifft? Eine benannte Person mit der Befugnis zur Auslieferung – oder niemand. Dies ist eine Frage des Betriebsmodells, die die technische Leitung nicht allein beantworten kann.
Was fällt aus der Roadmap heraus? Die Arbeit ist real und sie ist wiederkehrend. Ein Plan, der davon ausgeht, dass sie aufgenommen wird, ohne etwas anderes zu verdrängen, ist ein Plan, der stillschweigend nicht umgesetzt wird.
Wenn sich Teams entscheiden, Hilfe hinzuzuziehen, geschieht dies meist für die zweite und dritte dieser Aufgaben: ein abgegrenztes Projekt, um den Aktualisierungs- und Signierungspfad in ein bestehendes Produkt zu integrieren, und ein Prozess, den jemand anderes betreibt, bis er zur Routine wird. Wenn die Antwort darin besteht, Personal einzustellen oder eine breitere Partnerschaft einzugehen, vergleicht der Top-Unternehmen für die Entwicklung eingebetteter Software Überblick elf Firmen anhand der Fähigkeiten, die jede tatsächlich veröffentlicht, einschließlich der Frage, welche von ihnen Secure Boot, OTA und langfristige Wartung als ihre eigene Arbeit statt als Problem des Kunden benennen.
Was das kostet und wo die Kosten tatsächlich anfallen
Es gibt keine einzelne Zahl, und die im Anbietermarketing kursierenden Spannen sind nicht ausreichend belegt, um sie zu wiederholen. Was vorhersehbar ist, ist wo wo sich die Kosten konzentrieren, was nützlicher ist, wenn Sie einen Business Case erstellen.
Nachrüstung ist mit großem Abstand die teure Kategorie. Das Hinzufügen eines signierten Aktualisierungspfads zu einem Produkt, das ohne einen solchen konzipiert wurde, betrifft den Bootloader, das Speicherlayout, den Fertigungsprozess und den Feldrollout. Es jetzt in ein Produkt einzubauen, kostet nur einen Bruchteil davon.
Die wiederkehrenden Kosten werden am häufigsten übersehen. Überwachung, Triage und Patch-Releases werden fortgesetzt, solange das Produkt verkauft und unterstützt wird. Ein Business Case, der nur das erste Projekt bepreist, unterschätzt die Verpflichtung, und es ist die wiederkehrende Position, die bestimmt, ob dies aufgefangen oder mit Ressourcen ausgestattet wird.
Flottenfragmentierung vervielfacht alles. Vier Hardware-Revisionen und drei Firmware-Zweige bedeuten, dass jeder Fix vier oder mehr Releases erfordert. Die Konsolidierung von Varianten ist oft das Nützlichste, was ein Team tun kann, bevor die Verpflichtungen greifen, und es ist eine reine Ingenieursaufgabe ganz ohne regulatorischen Inhalt.
Dokumentation ist billig, wenn sie kontinuierlich erfolgt, und teuer, wenn sie archäologisch ist. Wird sie zusammen mit dem Code gepflegt, ist sie eine kleine Steuer pro Änderung. Nachträglich rekonstruiert, an einer Codebasis, deren Autoren gegangen sind, ist sie ein Projekt.
Wo Crunch-IS passt
Unsere Firmware-Entwicklungsdienstleistungen entwickeln Bootloader und Feld-Update-Mechanismen mit sicherer Boot-Verifizierung, Rollback-Schutz und Integritätsvalidierung als Standard und legen die Härtung — verschlüsselte Kommunikation, sichere Speicherung, Zugriffskontrolle, Reduzierung der Angriffsfläche — bereits in der Architekturphase fest und nicht erst, nachdem das Produkt funktioniert. Das ist genau die Reihe von Entscheidungen, die diese Verordnung nun nicht mehr optional macht, weshalb die Arbeit häufiger ein Firmware-Projekt als ein Compliance-Projekt ist.
Die andere Hälfte davon ist die Release-Disziplin, denn eine Verpflichtung, Fehlerbehebungen zuverlässig auszuliefern, ist eine Verpflichtung, einen Release-Prozess zu haben, der nicht selbst Dinge kaputt macht. Bei einem Netzwerkmanagementsystem für Telekommunikation, der Umbau um sauberere Grenzen und ein disziplinierter Release-Prozess reduzierten bereitstellungsbezogene Probleme um 60% und verbesserten die Systemverfügbarkeit und Zuverlässigkeit um 50% — dieselbe Fähigkeit, gemessen an einem anderen Problem.
Fazit
Der Cyber Resilience Act verlangt von Geräteherstellern nichts, wofür die besseren Embedded-Teams nicht ohnehin schon plädiert haben. Was sich ändert, ist, dass Update-Fähigkeit, Transparenz über Abhängigkeiten und ein laufender Prozess zum Umgang mit Schwachstellen nun Voraussetzungen für den Verkauf sind und nicht länger Dinge, die man im nächsten Jahr finanziert – und dass die bereits im Feld befindlichen Produkte neben dem nächsten ebenfalls in den Anwendungsbereich fallen.
Die beiden Entscheidungen, die jetzt getroffen werden sollten, sind architektonischer Natur: Gestalten Sie den Aktualisierungspfad in alles hinein, was Sie dieses Jahr beginnen, und machen Sie Ihr Komponenteninventar zu etwas, das der Build erzeugt, statt zu etwas, das eine Person zusammenstellt. Beides ist jetzt günstiger als zu jedem späteren Zeitpunkt, und keines davon erfordert, dass die Regulierung vollständig geklärt ist, bevor Sie handeln.
