Security by Design: Kaum ein Begriff fällt häufiger, wenn es um den Cyber Resilience Act geht. Und kaum ein Begriff wird so oft missverstanden. Denn Security by Design ist keine Haltung, kein Qualitätsversprechen und kein Punkt auf einer Folie. Es ist eine konkrete regulatorische Anforderung. Und sie lässt sich nur erfüllen, wenn Ihr Entwicklungsprozess darauf ausgelegt ist.
Der Cyber Resilience Act (CRA) verlangt von Herstellern, dass Sicherheit nicht nachträglich auf ein Produkt aufgesetzt, sondern von Beginn an in den Entwicklungsprozess integriert wird. Wer diesen Nachweis nicht bis zum Geltungsbeginn der CRA-Pflichten ab Dezember 2027 erbringen kann, verliert den Zugang zum europäischen Markt. Nicht wegen einer unsicheren Funktion, sondern wegen eines fehlenden Prozesses. Der strukturierte Rahmen dafür ist ein Secure Development Lifecycle (SDL).
Der CRA formuliert in Artikel 13 und Anhang I eine Reihe von Anforderungen, die unmittelbar die Art betreffen, wie Produkte mit digitalen Elementen entwickelt werden. Hersteller müssen unter anderem sicherstellen, dass ihre Produkte mit einem angemessenen Schutzniveau auf den Markt kommen, dass Risiken systematisch bewertet werden und dass Sicherheitsaspekte über den gesamten Produktlebenszyklus hinweg berücksichtigt sind.
Entscheidend ist dabei: Der CRA fragt nicht nur nach dem Ergebnis, sondern nach dem Weg dorthin. Die technische Dokumentation muss belegen, wie Sicherheitsanforderungen identifiziert, umgesetzt und verifiziert wurden. Das setzt einen strukturierten, wiederholbaren Entwicklungsprozess voraus, keinen projektbezogenen Ad-hoc-Ansatz.
Was ist ein Secure Development Lifecycle?
Ein Secure Development Lifecycle ist ein Prozessrahmen, der Sicherheitsaktivitäten systematisch in jede Phase der Produktentwicklung einbettet, von der Anforderungsanalyse bis zur Wartung. Er ist kein einzelnes Tool und kein einmaliges Projekt. Die Aktivitäten reichen über Architektur und Implementierung bis hin zu Test und Release und greifen in jeder Phase ineinander.
Ein SDL umfasst mehr als eine Phasenabfolge. Er gliedert sich in mehrere Themenfelder, von denen einige durchgängig über den gesamten Lebenszyklus laufen:
- Planung und Steuerung: Sicherheitsrichtlinien, Rollen, Zuständigkeiten und Kompetenzen festlegen.
- Risikomanagement: Bedrohungen und Risiken im jeweiligen Produktkontext systematisch bewerten.
- Anforderungen: Sicherheitsanforderungen aus der Risikobewertung ableiten.
- Architektur und Design: Sicherheit früh verankern und Secure-by-Default-Entscheidungen treffen.
- Implementierung: Sichere Codiervorgaben anwenden und ihre Einhaltung absichern.
- Verifikation und Validierung: Sicherheitsanforderungen testen und nachweisen, auch durch Pentests.
- Dokumentation: Handbücher und Sicherheitshinweise für Nutzer bereitstellen.
- Releases und Updates: Produkte sicher ausliefern und Updates kontrolliert bereitstellen.
- Lieferanten und Komponenten: zugekaufte und quelloffene Bestandteile absichern, mit Lieferanten-Sorgfalt und SBOM.
- Schwachstellenmanagement: Schwachstellen erfassen, bewerten und über den Unterstützungszeitraum beheben.
- Absicherung von Infrastruktur und Produktion: Entwicklungs- und Fertigungsumgebung schützen.
Planung und Steuerung sowie das Risikomanagement steuern den gesamten Prozess. Die Dokumentation entsteht als Teil der Entwicklung, Releases und Updates folgen nach deren Abschluss. Schwachstellenmanagement, die Einbindung von Lieferanten und Komponenten sowie die Absicherung von Infrastruktur und Produktion begleiten die Entwicklung als unterstützende Aktivitäten.
Ein SDL stellt sicher, dass Sicherheit nicht von der Verfügbarkeit einzelner Personen abhängt, sondern im Prozess verankert ist. Bedrohungsanalysen werden nicht optional durchgeführt, sondern als fester Bestandteil der Architekturphase. Sicherheitsanforderungen entstehen nicht aus Bauchgefühl, sondern aus einer dokumentierten Risikobewertung. Und die Verifikation erfolgt nicht erst kurz vor dem Release, sondern begleitend über den gesamten Entwicklungszyklus.
Für Hersteller, die bisher keine formalisierte Sicherheitsentwicklung betreiben, bedeutet das eine grundlegende Veränderung. Nicht unbedingt in dem, was entwickelt wird, sondern in dem, wie entwickelt wird.
Wo der SDL die CRA-Anforderungen adressiert
Die Verbindung zwischen SDL und CRA-Konformität ist kein indirekter Zusammenhang. Die wesentlichen Anforderungen des CRA lassen sich direkt auf SDL-Aktivitäten abbilden.
| CRA-Anforderung | Was der CRA verlangt | SDL-Aktivität, die das erfüllt |
|---|---|---|
| Risikobewertung (Artikel 13 Absatz 2) | systematische Bewertung der Cyber-Risiken | Bedrohungs- und Risikoanalyse in der Entwurfsphase |
| Sichere Standardkonfiguration (Anhang I) | Auslieferung mit sicherer Standardeinstellung | Secure-by-Default in Architekturentscheidungen |
| Dokumentationspflicht | Nachweis des Vorgehens, nicht nur des Ergebnisses | durchgängige Nachweisführung über alle Phasen |
| Updates und Änderungen | Sicherheit auch bei Wartung und Änderung | Defect- und Change-Management im SDL |
Gerade die letzte Zeile wird in der Praxis oft übersehen: Auch Updates und Änderungen sind eine Prozessanforderung, kein Produktmerkmal.
IEC 62443-4-1 als Orientierungsrahmen
Für Hersteller, die einen SDL aufbauen oder formalisieren wollen, bietet die IEC 62443-4-1 einen etablierten Orientierungsrahmen. Diese Norm beschreibt Anforderungen an einen sicheren Entwicklungsprozess und deckt Bereiche wie Security Management, Secure Design, Implementierung, Verifikation und Defect Management ab. Neben der IEC 62443-4-1 beschreibt auch der BSI TR-03185 zum sicheren Software-Lebenszyklus Anforderungen an einen sicheren Entwicklungsprozess.
Die IEC 62443-4-1 ist keine CRA-Norm im engeren Sinne: Sie wurde ursprünglich für industrielle Automatisierungssysteme entwickelt. Aber sie adressiert viele der Prozessanforderungen, die der CRA an Hersteller stellt, und wird von Konformitätsbewertungsstellen als relevanter Referenzrahmen herangezogen. Wer seinen SDL an der IEC 62443 als Grundlage für die CRA-Umsetzung ausrichtet, schafft damit eine belastbare Grundlage für die CRA-Konformitätsbewertung.
Wie zukunftssicher ist ein SDL nach IEC 62443-4-1?
Ein SDL, der sich heute an der IEC 62443-4-1 ausrichtet, zahlt auch auf die künftige CRA-Normenlandschaft ein. Die horizontale EN-40000-Reihe ist als Basis für alle Produkte mit digitalen Elementen angelegt. Für den Entwicklungsprozess besonders relevant sind die EN 40000-1-2 (Grundsätze für die Cyberresilienz) und die EN 40000-1-3 (Umgang mit Schwachstellen). Beide liegen bislang als Entwurf vor und sind noch nicht harmonisiert.
Für die Operational Technology werden ausgewählte Teile der IEC 62443 über eine Annex-Adaption (prAA) als unterstützende Normen in den entstehenden CRA-Normenrahmen überführt, darunter die IEC 62443-4-1 für den Entwicklungsprozess. Wer seinen Entwicklungsprozess an der IEC 62443-4-1 aufhängt, baut damit auf einer Grundlage auf, die in die künftige CRA-Normung hineinwächst, statt später ersetzt zu werden. Einen Überblick zum Stand gibt unsere Statusmeldung zu den horizontalen EN-40000-Normen.
Auch die Maschinenverordnung fordert sichere Entwicklung
Der CRA ist nicht die einzige EU-Regulierung, die einen sicheren Entwicklungsprozess voraussetzt. Auch die neue Maschinenverordnung (EU) 2023/1230, die ab Januar 2027 verbindlich gilt, enthält in Anhang III erstmals explizite Cybersecurity-Anforderungen für Maschinen mit digitalen Komponenten.
Für Maschinenhersteller bedeutet das: Der SDL adressiert nicht nur die CRA-Konformität, sondern schafft gleichzeitig eine Grundlage für die Erfüllung der Maschinenverordnung. Zwei regulatorische Anforderungen, ein Prozessrahmen. Diese Überschneidung macht den SDL-Aufbau besonders für Hersteller im Maschinenbau zu einer strategischen Investition, nicht zu einem Compliance-Overhead. Wie CRA und Maschinenverordnung ineinandergreifen, entscheidet darüber, wie viel doppelte Arbeit Sie vermeiden.
Reicht ein Pentest am Ende für die CRA-Konformität?
In der Praxis sehen viele Hersteller Sicherheit noch als etwas, das nach der funktionalen Entwicklung ergänzt wird: ein Pentest vor dem Release, eine Härtungsmaßnahme nach der Integration, ein Security Review kurz vor der Auslieferung.
Dieser Ansatz wird unter dem CRA nicht mehr tragfähig sein. Die Verordnung verlangt, dass Sicherheit in den Entwicklungsprozess integriert ist, nicht, dass sie ihm nachgelagert wird. Die technische Dokumentation muss den Prozess belegen, nicht nur das Ergebnis. Eine nachträgliche Absicherung kann Schwachstellen im Produkt beheben, aber sie kann keinen Entwicklungsprozess nachweisen, der nie existiert hat.
Das heißt nicht, dass ein Pentest überflüssig wird. Er bleibt ein wertvolles Werkzeug der Verifikation, etwa als wiederkehrende Maßnahme, wie sie Pentests im Maschinenbau zeigen. Entscheidend ist nur, dass er Teil eines durchgängigen Prozesses ist und nicht dessen Ersatz.
Das ist der entscheidende Punkt: Der CRA prüft nicht nur, ob ein Produkt sicher ist. Er prüft, ob es sicher entwickelt wurde. Und dieser Nachweis erfordert einen SDL, der vor dem ersten Commit steht, nicht nach dem letzten Test.
Was das für Hersteller bedeutet
Der Secure Development Lifecycle ist keine optionale Best Practice mehr. Er ist die operative Voraussetzung für CRA-Konformität. Hersteller, die heute keinen formalisierten SDL betreiben, stehen vor einer grundlegenden Prozessveränderung, die Zeit braucht und sich nicht in wenigen Wochen vor dem Stichtag umsetzen lässt.
Die Anforderungen sind dabei keine Überraschung. Der CRA ist seit 2024 in Kraft, die Maschinenverordnung seit 2023 veröffentlicht. Die Frage ist nicht mehr, ob Hersteller ihren Entwicklungsprozess umstellen müssen, sondern ob der verbleibende Zeitraum ausreicht, um es strukturiert zu tun.
Kommentar hinzufügen