Seit dieser Woche ist der Cyber Resilience Act keine Ankündigung mehr. Ab dem
- September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden an die ENISA und das zuständige CSIRT melden, und zwar auch für Produkte, die längst im Markt sind. Ab dem
- Dezember 2027 gilt die Verordnung dann vollständig, inklusive Konformitätsbewertung und CE-Kennzeichnung. Betroffen ist fast alles, was direkt oder indirekt vernetzbar ist: IoT-Geräte, Maschinensteuerungen, Embedded-Linux-Systeme, auch reine Software. Die harmonisierten Normen, die die Anforderungen eigentlich konkretisieren sollen, hängen derweil in der Abstimmung fest. Man muss also anfangen, bevor die offizielle Messlatte im Amtsblatt steht.
Ich habe die Anforderungen in den letzten Wochen einmal gegen meine eigene Projekthistorie gehalten und dabei gemerkt: Vieles davon habe ich in den letzten Jahren bereits gebaut. Es hieß nur nicht CRA, sondern schlicht solides Engineering. Die meisten Texte zum CRA sind aus juristischer Sicht geschrieben, welche Artikel, welche Fristen, welche Bußgelder. Meiner hier ist aus der Engineering-Sicht geschrieben, denn am Ende entscheidet sich CRA-Konformität nicht im Rechtsgutachten, sondern in der Build-Infrastruktur, der Architektur und im Entwicklungsprozess. Sechs Punkte, jeweils mit dem, was ich dazu in Projekten erlebt habe.
1. Wissen, was betroffen ist und wie stark
Bevor irgendein Werkzeug angeschafft wird, gehört das Produktportfolio einmal ehrlich sortiert: Welche Produkte fallen unter den CRA? Welche sind der Standardfall mit Selbstbewertung, welche gelten als „wichtig” oder „kritisch” und brauchen ein strengeres Bewertungsverfahren? Und welche sind zwar schon im Markt, fallen aber trotzdem unter die neuen Meldepflichten?
Die Einstufung entscheidet über den gesamten weiteren Aufwand. Gerade die Grenzfälle (Fernzugriff? Sicherheitsfunktion?) sollte man früh und schriftlich entscheiden, sonst diskutiert man sie später unter Zeitdruck mit der Benannten Stelle.
2. Die SBOM muss aus dem Build kommen, nicht aus Excel
Der CRA verlangt eine Software Bill of Materials in einem maschinenlesbaren Format, mindestens über die direkten Abhängigkeiten, aktuell zu halten über die gesamte Supportdauer. Das Problem daran ist selten das Format. In fast jedem gewachsenen C++-Projekt, das ich übernommen habe, lagen die Abhängigkeiten als einkopierte Quelltexte, eingecheckte Binärdateien oder Archive auf dem Netzlaufwerk herum. Eine SBOM wäre dort eine Momentaufnahme von Hand gewesen, beim nächsten Release gleich wieder falsch.
Bei zwei Kunden, einem großen Automobilzulieferer und einem Medizintechnik-Hersteller, habe ich das über Conan gelöst, den Paket- und Dependency-Manager für C und C++. Conan löst bei jedem Build ohnehin den vollständigen Abhängigkeitsgraphen auf, und aus genau diesem Graphen fällt die SBOM (bspw. im CycloneDX-Format) automatisch heraus. Niemand pflegt ein Dokument, die SBOM ist ein Build-Artefakt wie die Binaries auch.
Der eigentliche Gewinn liegt ohnehin im Weg dorthin: Wer seine Abhängigkeiten so weit im Griff hat, dass eine SBOM automatisch entstehen kann, kann auch die Frage beantworten, die als nächstes kommt, nämlich was überhaupt im eigenen Produkt steckt.
3. Schwachstellen in Fremdkomponenten: Monitoring statt Zufallsfund
Die SBOM ist nur die Inventur. Der CRA verlangt zusätzlich, dass Produkte ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden und dass bekannte Schwachstellen über die Supportdauer behandelt werden. Praktisch heißt das: die eigenen Komponenten laufend gegen die CVE-Datenbanken abgleichen und die Treffer dokumentiert bewerten („betrifft uns / betrifft uns nicht, weil …”).
Bei einem Hersteller von Laborautomatisierung habe ich das für ein
Yocto-basiertes Embedded-Linux-System eingerichtet. So ein Image zieht
schnell einige hundert Pakete nach sich, von Hand ist da nichts zu
überwachen. Yocto bringt dafür aber schon alles mit: INHERIT += "cve-check"
in der Konfiguration, bitbake -c cve_check <recipe> im Build, und der
Abgleich gegen bekannte Schwachstellen läuft als ganz normales Build-Target.
Heraus kommt eine Liste offener CVEs pro Rezept. Damit kann ein Team arbeiten
und priorisieren, mit einer diffusen Sorge kann es das nicht.
Das Werkzeug ist austauschbar, das Muster nicht: Die Schwachstellenprüfung gehört in den Build oder die CI, nicht in einen Quartalstermin.
4. Updates im Feld: ohne Vertrauenskette kein Update-Pfad
Der CRA verlangt außerdem Sicherheitsupdates über die Supportdauer von mindestens fünf Jahren, bei längerer Produktlebensdauer entsprechend mehr. Für Geräte im Feld braucht es also einen Update-Mechanismus, der existiert und der nicht selbst zum Einfallstor wird. Ein Update-Kanal, der beliebige Images akzeptiert, ist schlimmer als keiner.
Für einen Hersteller von elektronischen Wegfahrsperren haben wir das seinerzeit über eine klassische PKI-Vertrauenskette gelöst: Die Firmware-Images werden beim Build kryptografisch signiert, der Bootloader trägt das zugehörige Schlüsselmaterial und startet ausschließlich korrekt signierte Images. Bootloader und Firmware sind damit fest aneinander gebunden, ein Update ohne gültige Signatur läuft schlicht nicht an. Nichts davon ist exotisch. Aber es muss von Anfang an in der Architektur stecken, nachträglich bekommt man Secure Boot nur mit erheblichem Aufwand in eine Geräteflotte.
Die unbequeme Frage für Bestandsprodukte lautet deshalb: Gibt es für jedes Gerät, das in fünf Jahren noch im Feld sein wird, überhaupt einen Weg, ein Update sicher auszurollen? Wenn nein, ist das die teuerste Lücke auf dieser Liste.
5. Security-Testing gehört in den Entwicklungsprozess, nicht ans Ende
„Secure by Design” aus Anhang I klingt abstrakt. Konkret wird es mit einer einfachen Frage: Was findet Schwachstellen im eigenen Produkt zuerst, der eigene Prozess oder ein Fremder?
Bei einem großen Sensorhersteller habe ich dafür über mehrere Projekte hinweg
drei Ebenen kombiniert. nmap gegen die eigenen Geräte, um die tatsächliche
Angriffsfläche zu sehen, bspw. offene Ports und Dienste, von denen im Zweifel
nicht einmal das Entwicklungsteam alle kennt. Fuzzing gegen die
Schnittstellen, um die Eingabeverarbeitung automatisiert mit Fehleingaben zu
konfrontieren. Und Address-, Memory- und Thread-Sanitizer im regulären Build-
und Testablauf, damit ganze Fehlerklassen wie Speicherfehler oder Data Races
auffallen, bevor daraus eine ausnutzbare Schwachstelle wird.
Nichts davon ist rocket science, und genau das ist der Punkt: Die Werkzeuge existieren, sind größtenteils frei verfügbar und laufen in jeder CI. Der Unterschied zwischen „Secure by Design” und Papierwerk ist, ob sie bei jedem Merge laufen oder in einem Konzeptdokument stehen.
6. Die 24-Stunden-Frage: Wer meldet eigentlich?
Der am schlechtesten vorbereitete Punkt, und ab dem 11. September der akuteste. Die Meldepflicht verlangt eine Frühwarnung binnen 24 Stunden, nachdem der Hersteller von einer aktiv ausgenutzten Schwachstelle Kenntnis erlangt. Dafür muss es im Unternehmen jemanden geben, bei dem diese Kenntnis zusammenläuft, der bewerten darf und der melden kann.
In keinem meiner Projekte gab es diese Person. Es gibt den Support, es gibt die Entwicklung, es gibt vielleicht einen Informationssicherheitsbeauftragten für die IT. Aber auf die Frage „bei wem landet es, wenn ein Kunde eine ausgenutzte Schwachstelle im Produkt meldet, und wer meldet binnen 24 Stunden weiter?” habe ich nie eine spontane Antwort bekommen.
Immerhin: Das ist die am schnellsten schließbare Lücke der Liste. Eine benannte Person plus Stellvertretung, ein dokumentierter Eskalationsweg vom Support bis zur Meldung, einmal durchgespielt. Das ist ein Nachmittag Arbeit. Die Alternative ist, den Prozess zum ersten Mal im Ernstfall unter Zeitdruck zu improvisieren.
Womit anfangen?
Wenn alles gleichzeitig wichtig aussieht, sortiere ich nach Risiko und Vorlaufzeit:
- Meldeprozess und Verantwortlichkeit. Die Pflicht gilt bereits, der Aufwand ist klein.
- Bestandsaufnahme und Einstufung des Portfolios. Sie bestimmt den Umfang von allem Weiteren.
- Dependency-Management und SBOM. Darauf bauen Schwachstellenmanagement und technische Dokumentation auf.
- Update-Pfad für Feldgeräte. Die größte Architekturfrage, deshalb früh anfangen.
- Security-Testing in der CI und Threat Modelling. Danach kontinuierlich, nicht einmalig.
Der Dezember 2027 klingt weit weg. Wer aber heute ein Produkt entwickelt, das dann auf den Markt kommt, trifft die relevanten Architekturentscheidungen jetzt. Genau diese Bestandsaufnahme mache ich inzwischen als eigenes Format: das CRA-Readiness-Assessment.