Cyber Resilience Act: Pflichten in die Produktentwicklung bringen

Der Cyber Resilience Act (Cyberresilienz-Verordnung, CRA) verankert Cybersicherheitspflichten im Lebenszyklus erfasster Produkte mit digitalen Elementen. Für einen CTO besteht die praktische Aufgabe darin, das, was die Entwicklung baut, ausliefert und pflegt, mit den Nachweisen zu verbinden, die zur Erfüllung dieser Pflichten nötig sind.

Diese Verbindung muss auf Produkt- und Versionsebene funktionieren. Eine unternehmensweite Sicherheitsrichtlinie erklärt nicht, ob ein bestimmtes Release sichere Voreinstellungen hat, welche Abhängigkeiten es enthält oder wie Kunden ein Sicherheitsupdate erhalten. Ein als „behoben“ markiertes Schwachstellenticket belegt nicht, welche unterstützten Versionen weiterhin betroffen sind.

Der sinnvolle Ausgangspunkt ist daher ein Modell des Produktlebenszyklus: Anwendungsbereich, Sicherheitsanforderungen, Release-Nachweise, Schwachstellenbehandlung, Supportzusagen und verantwortete Entscheidungen. Bauen Sie dieses Modell in die Entwicklung ein, statt es vor einer Bewertung separat zusammenzustellen.

Die Produktgrenze festlegen, bevor Sie Maßnahmen zuordnen

Der CRA betrifft Produkte mit digitalen Elementen in seinem Anwendungsbereich, einschließlich erfasster Hardware und Software. Er ist keine allgemeingültige Regel für jeden SaaS-Dienst. Ein gehosteter Dienst und an Kunden verteilte Software können unterschiedliche Analysen erfordern, und eine für ein Produkt wesentliche Datenfernverarbeitung muss ebenfalls geprüft werden.

Nutzen Sie die CRA-Informationen der Europäischen Kommission als Ausgangsreferenz und klären Sie dann die produktspezifischen Rechtsfragen. Dokumentieren Sie die Schlussfolgerung, statt sich auf eine informelle Annahme des Teams zu verlassen.

Klären Sie für jedes in Frage kommende Produkt:

• Was Kunden erhalten: Hardware, installierte Software, herunterladbare Komponenten oder eine Kombination.
• Welche Funktionen der Datenfernverarbeitung notwendig sind, damit das Produkt seine Funktionen erfüllen kann.
• Wie das Produkt auf dem EU-Markt bereitgestellt wird und welche Gesellschaft es bereitstellt.
• Ihre Rolle als Wirtschaftsakteur: Hersteller, Einführer, Händler oder eine andere relevante Rolle.
• Anwendbare Ausnahmen, produktspezifische Rechtsvorschriften und Aspekte rund um Open Source.
• Die Produktkategorie und die daraus folgenden Anforderungen an die Konformitätsbewertung.

Open Source erfordert besondere Sorgfalt. Die Behandlung von Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, bedeutet nicht, dass ein kommerzieller Hersteller in sein Produkt eingebettete Open-Source-Komponenten ignorieren kann. Unterscheiden Sie die Position der vorgelagerten Beitragenden von Ihrer Verantwortung für das Produkt, das Sie bereitstellen.

Das technische Ergebnis sollte eine kurze Dokumentation des Anwendungsbereichs mit Architekturdiagramm, Produktkennungen, relevanten Gesellschaften, Annahmen und einer genehmigten Schlussfolgerung sein. Benennen Sie die Person, die diese Schlussfolgerung erneut aufgreift, wenn sich Funktionen oder Vertriebswege ändern.

So sollten etwa eine herunterladbare Verwaltungsanwendung und der zugehörige gehostete Analysedienst nicht automatisch eine einzige, undifferenzierte Entscheidung zum Anwendungsbereich erhalten. Ermitteln Sie, welche Funktionen lokal arbeiten, welche vom Dienst abhängen und ob diese Datenfernverarbeitung innerhalb der Produktgrenze liegt. Diese Unterscheidung beeinflusst Risikobewertung, Abhängigkeitsaufzeichnungen und die Verantwortung bei Vorfällen.

Von den aktuellen Umsetzungsterminen ausgehen

Die Kommission nennt den 11. September 2026 für die Meldepflichten und den 11. Dezember 2027 für die wesentlichen CRA-Anforderungen. Mit Stand 7. Oktober 2026 ist der Termin für die Meldepflichten bereits verstrichen. Behandeln Sie die Meldebereitschaft als aktuelle betriebliche Anforderung, nicht als Aufgabe, die bis zur Vorbereitung der Konformität aufgeschoben wird.

Halten Sie zwei Arbeitsstränge sichtbar:

Produkte, die vor dem Hauptgeltungstermin bereitgestellt werden, erfordern Aufmerksamkeit für Übergangsbestimmungen und wesentliche Änderungen. Nehmen Sie nicht an, dass ein älteres Produkt für die Meldepflichten irrelevant ist, nur weil sein ursprüngliches Release vor Dezember 2027 lag.

Führen Sie ein datiertes Register der rechtlichen Anforderungen. Prüfen Sie für Ereignisschwellen, gestufte Meldefristen, Empfänger und Übermittlungsverfahren den aktuellen Rechtstext und die offiziellen Umsetzungsleitlinien. Ersetzen Sie den CRA-spezifischen Prozess nicht durch eine generische Vorlage für die Reaktion auf Sicherheitsvorfälle.

Sicherheitsanforderungen in Design- und Release-Kriterien übersetzen

Die grundlegenden Anforderungen des CRA umfassen Eigenschaften der Produktsicherheit und die Behandlung von Schwachstellen. Ihre Umsetzung sollte der Cybersicherheitsrisikobewertung des Produkts folgen, nicht einer allgemeinen Checkliste, die ohne architektonischen Kontext angewendet wird.

Beginnen Sie damit, wie das Produkt Schaden verursachen kann. Beschreiben Sie Benutzer, Einsatzumgebungen, exponierte Schnittstellen, privilegierte Operationen, sensible Daten und vorhersehbare Fehlanwendung. Beziehen Sie die Betriebsannahmen der Kunden ein: Eine Appliance in einem Industrienetz hat eine andere Exposition und andere Wiederherstellungsbeschränkungen als ein Desktop-Werkzeug.

Eine praktische Bedrohungsmodellierung kann diese Arbeit unterstützen; der Leitfaden von OWASP zur Bedrohungsmodellierung bietet einen etablierten Ansatz. Das Ergebnis sollte Bedrohungen mit konkreten Anforderungen, Umsetzungsentscheidungen und Tests verbinden.

Betrachten Sie, wie vertraute Anforderungen prüfbar werden:

Das sind praktische Umsetzungsbeispiele, kein Ersatz für die anwendbaren Anforderungen. Bestimmen Sie Relevanz und Angemessenheit über die Risikobewertung.

Ergänzen Sie Feature-Arbeit um Sicherheitsabnahmekriterien. Eine neue administrative API sollte mit Entscheidungen zu Authentifizierung, Autorisierung, Eingabeverarbeitung und Protokollierung kommen, nicht mit dem Versprechen, dass die Sicherheit sie später prüft. Überprüfen Sie das Bedrohungsmodell erneut, wenn eine Fernschnittstelle, eine privilegierte Komponente oder eine neue Vertrauensgrenze hinzukommt.

Die Release-Freigabe sollte offene Schwachstellen, ihre Ausnutzbarkeit, betroffene Konfigurationen und die Behandlung benennen. Wenden Sie die CRA-Anforderung an, Produkte ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitzustellen, unter Berücksichtigung der Risikobewertung und der anwendbaren grundlegenden Anforderungen; das Dokumentieren oder Akzeptieren eines Risikos erfüllt diese Anforderung für sich genommen nicht. Ein Scanner-Ergebnis allein kann diese Entscheidung nicht treffen: Erreichbarkeit, Voraussetzungen und Produktverhalten spielen eine Rolle. Umgekehrt ist ein niedriger numerischer Schweregrad kein ausreichender Grund, eine Schwachstelle zu ignorieren, die in Ihrem Einsatzmodell folgenreich ist.

Die Release-Dokumentation sollte die freigegebene Quellcode-Revision, das Build-Artefakt, das Abhängigkeitsinventar, die Testergebnisse und die Sicherheitsentscheidung verbinden. So wird die Bewertung reproduzierbar, wenn ein Kunde oder eine Behörde später nach einer bestimmten Version fragt.

Die Sorgfaltsprüfung von Komponenten zum Teil des Build-Prozesses machen

Komponenten Dritter begründen Pflichten, die sich nicht durch das Weiterleiten eines vorgelagerten Sicherheitshinweises erfüllen lassen. Sie müssen verstehen, was Sie ausgeliefert haben, ob es betroffen ist und wie Sie Abhilfe schaffen können.

Der CRA enthält in seinen Anforderungen an die Schwachstellenbehandlung die Pflicht zu einer Software-Stückliste (SBOM): in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten der obersten Ebene abdeckt. Erfassen Sie als praktische Empfehlung tiefere Abhängigkeitsinformationen, wo immer Ihre Build-Werkzeuge verlässliche Ergebnisse liefern können. Transitive Abhängigkeiten bestimmen oft die Exposition.

Eine SBOM ist nur nützlich, wenn sie zu einem realen Produktartefakt passt. Verknüpfen Sie sie mit der Release-Kennung und dem Build und unterscheiden Sie ausgelieferte Komponenten von reinen Entwicklungswerkzeugen. Beziehen Sie, wo relevant, Firmware, Betriebssystempakete, gebündelte Bibliotheken und kommerzielle Komponenten ein; ein Export aus dem Paketmanager kann mehrere davon übersehen.

Gestalten Sie die Komponentenprüfung entlang von Fragen, die technische Entscheidungen verändern:

• Wird die Komponente gepflegt, und ist ihre unterstützte Lebensdauer mit unserer vereinbar?
• Können wir Schwachstelleninformationen und Sicherheitsupdates zeitnah erhalten?
• Haben wir Zugang zum Quellcode, einen Patch-Weg über den Lieferanten oder eine Ersatzstrategie?
• Führt die Komponente eine privilegierte Ausführung oder eine neue externe Verbindung ein?
• Kann das Produkt weiter gepflegt werden, wenn der Lieferant die Unterstützung einstellt?

Bei kommerziellen Komponenten sollte der Einkauf Sicherheitskontakte, Benachrichtigungsregelungen und den Zugang zu Fehlerbehebungen festlegen. Die Reaktionszeiten der Lieferanten müssen Raum für Ihre eigene Bewertung und Ihre Meldepflichten lassen. Der Produkthersteller braucht dennoch einen internen Eskalationsweg, wenn eine Lieferantenantwort unvollständig ist.

Bewahren Sie bei Open-Source-Abhängigkeiten die Herkunft und einen realistischen Wartungsplan auf. Ein öffentlich zugängliches Repository ist kein Beleg dafür, dass jemand während Ihres Unterstützungszeitraums einen kompatiblen Patch liefern wird.

Unterstützungszeitraum und Update-Mechanismus gemeinsam gestalten

Support ist eine technische Zusage mit kaufmännischen Folgen. Der CRA verlangt grundsätzlich einen Unterstützungszeitraum von mindestens fünf Jahren, sofern die erwartete Nutzungsdauer des Produkts nicht kürzer ist. Bestimmen Sie den anwendbaren Zeitraum anhand der Kriterien der Verordnung, statt ein beliebiges Datum zu wählen, das zur Roadmap passt.

Dokumentieren Sie die Begründung, teilen Sie Kunden die vorgeschriebenen Supportinformationen mit und verknüpfen Sie diese mit gepflegten Produktversionen. Die Supportzusage muss die Fähigkeit berücksichtigen, Sicherheitsupdates zu liefern, und nicht nur eine Helpdesk-Adresse aufrechterhalten.

Fragen Sie vor der Genehmigung eines Supportplans für ein Produkt, ob Sie:

• Ältere unterstützte Branches mit gepflegten Toolchains neu bauen können.
• Sicherheitsupdates sicher erstellen, authentifizieren und verteilen können.
• Fehlerbehebungen über unterstützte Hardware- und Einsatzkonfigurationen hinweg testen können.
• Signaturschlüssel pflegen und sich sicher von einer Schlüsselkompromittierung erholen können.
• Kundenbezogene Update- und Sicherheitsinformationen verfügbar halten können.
• Mit Abhängigkeiten umgehen können, deren vorgelagerter Support vor Ihrem endet.

Sicherheitsupdates sind während des Unterstützungszeitraums grundsätzlich kostenlos bereitzustellen, vorbehaltlich der Bestimmungen der Verordnung. Jedes während dieses Zeitraums bereitgestellte Sicherheitsupdate muss nach seiner Bereitstellung mindestens zehn Jahre lang oder für den Rest des Unterstützungszeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist. Planen Sie Sicherheitskorrekturen getrennt von der Feature-Entwicklung, damit Kunden nicht unnötig zu unabhängigen funktionalen Änderungen gezwungen werden.

Testen Sie mehr als den Normalfall. Eine unterbrochene Installation, unzureichender Speicherplatz, abgelaufene Zugangsdaten und eine fehlgeschlagene Verifizierung können aus einem gültigen Patch ein Verfügbarkeitsproblem machen. Entscheiden Sie, welche Wiederherstellungsmechanismen für das Risikoprofil des Produkts nötig sind.

Am Ende des Supports sollten Kundenkommunikation und interne Aufzeichnungen übereinstimmen. Lassen Sie keine Download-Seite bestehen, die eine fortlaufende Sicherheitspflege suggeriert, wenn das Produktregister besagt, dass die Zusage geendet hat.

Ein Melde-Runbook aufbauen, das Unsicherheit standhält

Eine gewöhnliche Schwachstellenfeststellung, eine aktiv ausgenutzte Schwachstelle und ein schwerwiegender Sicherheitsvorfall sind nicht austauschbar. Der CRA-Meldeprozess braucht eine dokumentierte Bewertung des maßgeblichen Auslösers, keine automatische Meldung jedes Scanner-Alarms und keine automatische Zurückweisung von allem, wofür keine abgeschlossene forensische Untersuchung vorliegt.

Das Runbook sollte mit der Annahme von Meldungen beginnen. Forschende, Kundensupport, Lieferanten und Entwicklungsteams brauchen einen bekannten Weg zur Produktsicherheitsfunktion. Bewahren Sie die ursprüngliche Meldung auf und dokumentieren Sie, wann relevante Informationen bekannt wurden; setzen Sie Zeitstempel der Kenntnisnahme nicht zurück, wenn ein Ticket das Team wechselt.

Erfassen Sie bei möglicherweise meldepflichtigen Ereignissen:

• Produktkennungen und betroffene unterstützte Versionen.
• Belege für eine Ausnutzung oder die Auswirkungen des Vorfalls, mit Vertrauensgrad und Unsicherheiten.
• Bekannte Angriffsbedingungen, betroffene Funktionen und Einsatzannahmen.
• Verfügbare Abhilfemaßnahmen und den Stand der Korrekturmaßnahmen.
• Die Bewertung des Auslösers, die für die Meldung verantwortliche Person und die Berechnung der anwendbaren Fristen.
• Übermittelte Meldungen, Eingangsbestätigungen, spätere Aktualisierungen und Kundenkommunikation.

Prüfen Sie die gestuften Meldefristen, Anforderungen an den Abschlussbericht, Empfänger und das aktuelle Meldeverfahren anhand offizieller Quellen. Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten unterschiedliche Meldeangaben; ein einziges kopiertes Fristenfeld reicht nicht aus.

Benennen Sie eine primär für die Meldung verantwortliche Person und eine Stellvertretung mit der Befugnis, Entwicklung, Recht und Kundenkommunikation zu koordinieren. Regeln Sie den Zugang zum anwendbaren Meldemechanismus im Voraus. Die rechtliche Prüfung sollte innerhalb des Meldezeitraums verfügbar sein, statt zu einer unbegrenzten Freigabeschleife zu werden.

Üben Sie den Prozess mit unvollständigen Informationen. Eine sinnvolle Übung beginnt mit einer glaubwürdigen Meldung über eine Ausnutzung, einer unsicheren Liste betroffener Versionen und einem nicht erreichbaren Komponentenlieferanten. Das Team sollte eine zeitgerechte, dokumentierte Meldeentscheidung treffen können, während die Untersuchung weiterläuft.

Die CRA-Meldung ersetzt keine anderen anwendbaren Pflichten. Ein Produktereignis kann auch eine Bewertung nach Datenschutzrecht oder einem Kundenvertrag erfordern. Stimmen Sie diese Bewertungen ab, halten Sie aber ihre jeweiligen Auslöser, Empfänger und Entscheidungsdokumentationen getrennt.

Die Einstufung bestätigen, bevor Sie den Bewertungsplan wählen

Die Produkteinstufung beeinflusst, welches Konformitätsbewertungsverfahren zur Verfügung steht. Nehmen Sie nicht an, dass jedes vernetzte Produkt dieselbe externe Bewertung benötigt oder dass sich jeder Hersteller auf eine interne Bewertung stützen kann.

Bestimmen Sie die anwendbare Kategorie anhand der Funktionen des Produkts sowie der Begriffsbestimmungen und Anhänge der Verordnung. Bestätigen Sie dann das zulässige Verfahren, einschließlich etwaiger Bedingungen zu harmonisierten Normen, anerkannten Spezifikationen, Zertifizierungsschemata oder einer Bewertung durch Dritte.

Die Planung von Normen braucht ein ausdrückliches Abhängigkeitsregister: welche Referenzen anwendbar sind, wie ihr aktueller Status ist und was sich ändert, wenn ein erwartetes Verfahren nicht verfügbar ist. Lassen Sie den Release-Plan nicht von einer unbestätigten Annahme über Normen oder Bewertungskapazitäten abhängen.

Überprüfen Sie die Einstufung erneut, wenn sich Funktionen ändern. Das Hinzufügen von Funktionen zum Sicherheitsmanagement oder zur Netzwerksteuerung kann die Analyse beeinflussen, doch ein Feature-Name allein begründet keine Kategorie. Bewerten Sie die tatsächliche Funktion und dokumentieren Sie die Schlussfolgerung.

Halten Sie Einstufung, gewähltes Verfahren und Konformitätsergebnisse mit der technischen Dokumentation verbunden. CE-Kennzeichnung und EU-Konformitätserklärung müssen dem anwendbaren Verfahren folgen; sie ersetzen nicht die Umsetzung der zugrunde liegenden Anforderungen.

Ein Nachweispaket pflegen, das ein Release erklären kann

Die technische Dokumentation sollte sowohl das Produkt als auch die Begründung seiner Sicherheitsentscheidungen beschreiben. Bewahren Sie Risikobewertungen und Dokumentation auf, während sich das Produkt verändert, und wenden Sie die gesetzlichen Aufbewahrungsanforderungen auf die betreffenden Aufzeichnungen an.

Ein brauchbares Nachweispaket für ein Produkt umfasst die Entscheidung zum Anwendungsbereich, die Architektur, die Risikobewertung, Sicherheitsanforderungen, Komponenteninformationen, Verifizierungsergebnisse, Verfahren zur Schwachstellenbehandlung, die Begründung des Supportzeitraums und Konformitätsaufzeichnungen. Jedes Element braucht eine verantwortliche Person und eine identifizierbare Version.

Verwenden Sie stabile Kennungen, um diese Aufzeichnungen zu verbinden. Ein Schwachstellendatensatz sollte betroffene Versionen, Exposition, Behandlung, Release und erforderliche Kommunikation erklären. „Behoben“ ohne Versionskontext lässt die Produktnachweise unvollständig.

Bestehende ISMS-Prozesse können nützliche Nachweise zu Governance, Lieferanten und sicherer Entwicklung liefern. ISO 27001 betrifft jedoch ein abgegrenztes Informationssicherheitsmanagementsystem; eine Zertifizierung belegt nicht die CRA-Konformität eines einzelnen Produkts. Verwenden Sie relevante Nachweise wieder, ohne Zuordnungen zwischen Rahmenwerken als rechtliche Gleichwertigkeit zu behandeln.

Praxisbeispiel: eine Schwachstelle in einer Abhängigkeit einer unterstützten Appliance

Betrachten Sie einen fiktiven Hersteller, der eine vernetzte Appliance in der EU bereitstellt. Angenommen, Anwendungsbereich und Einstufung wurden geprüft, zwei Release-Branches werden weiterhin unterstützt, und eine gebündelte Bibliothek wird andernorts als aktiv ausgenutzt gemeldet.

Die erste Aufgabe besteht nicht darin, den vorgelagerten Sicherheitshinweis zu schließen. Die Entwicklung ermittelt, welche Appliance-Builds die verwundbare Bibliothek enthalten und ob die betroffene Funktion erreichbar ist. Die SBOM legt nahe, dass beide Branches sie enthalten, doch die Konfigurationsanalyse zeigt eine unterschiedliche Exposition. Dieser Unterschied wird mit den stützenden Nachweisen dokumentiert.

Die für Produktsicherheit verantwortliche Person bewertet dann, ob die verfügbaren Fakten den anwendbaren CRA-Meldeauslöser erfüllen. Die Unsicherheit über eine Einsatzkonfiguration wird dokumentiert; sie rechtfertigt nicht, die für die Entscheidung verantwortliche Person unbenannt zu lassen. Das Melde-Runbook liefert die aktuellen Meldestufen und das Verfahren.

Die Entwicklung erarbeitet eine vorläufige Abhilfemaßnahme und einen gepatchten Build für jeden betroffenen Branch. Die Tests decken den verwundbaren Pfad, den Normalbetrieb und die authentifizierte Update-Installation ab. Kann ein Branch den vorgelagerten Patch nicht nutzen, dokumentiert das Team dessen alternative Behandlung und das Restrisiko, statt das gesamte Produkt als behoben zu markieren.

Die Kundenkommunikation benennt betroffene Versionen, sofortige Schutzmaßnahmen und den Bezug des Updates. Der Zeitpunkt der Offenlegung wird mit den anwendbaren Anforderungen an die Schwachstellenbehandlung und etwaigen begründeten Sicherheitserwägungen abgestimmt.

Die vollständige Dokumentation verbindet den Sicherheitshinweis, die Analyse der betroffenen Builds, die Meldeentscheidung, gegebenenfalls erforderliche Übermittlungen, Patch-Commits, Testergebnisse, Release-Artefakte und die Kommunikation. Eine prüfende Person kann nun sowohl die technische Reaktion als auch die Compliance-Entscheidung nachvollziehen.

Mit einem Produkt und einer vollständigen Nachweiskette beginnen

Wählen Sie ein repräsentatives unterstütztes Produkt und verfolgen Sie ein aktuelles Release und eine Schwachstelle durch den Lebenszyklus. Fehlende Versionsverknüpfungen, unklare Supportzusagen und unzugängliche Meldeverfahren werden schnell sichtbar. Machen Sie jede Lücke zu einer Aufgabe mit klarer Verantwortung und übertragen Sie das Modell dann auf das gesamte Portfolio.

Secani kann diesen Nachweisablauf unterstützen, indem es Anforderungen, Nachweise, Verantwortliche, Aufgaben und Prüfentscheidungen miteinander verbindet. Entwicklungswerkzeuge bleiben die operativen Quellen für Builds, Releases und Schwachstellen; der Compliance-Arbeitsbereich setzt diese Aufzeichnungen in Beziehung zur anwendbaren Pflicht. Halten Sie die menschliche Freigabe von Zuordnungen und Schlussfolgerungen ausdrücklich fest und bewahren Sie die Nachvollziehbarkeit der Quellen, wenn Sie KI-gestützte Entwürfe nutzen.

Der unmittelbar nächste Schritt ist, das Melde-Runbook zu testen. Verlangen Sie parallel dazu, dass das nächste Produkt-Release eine verknüpfte Entscheidung zum Anwendungsbereich, eine aktuelle Risikobewertung, ein Komponenteninventar und eine Sicherheitsfreigabe mitbringt. So entsteht eine wiederholbare technische Praxis, während die Vorbereitung der Konformität voranschreitet.