Security by Design unter dem CRA: Was es über den Produktlebenszyklus hinweg tatsächlich bedeutet

„Security by Design“ ist eine Formulierung, die im CRA und seinen begleitenden Leitlinien immer wieder auftaucht. Es ist auch eine Formulierung, die in der Praxis fast alles bedeuten kann. Für Hersteller, die sich auf die Konformitätsfrist im Dezember 2027 vorbereiten, lautet die Frage nicht, ob sie an Security by Design im Grundsatz glauben. Sie lautet, ob ihr Entwicklungsprozess die Nachweise hervorbringt, die die Verordnung verlangt.

Dieser Beitrag legt dar, was der CRA in jeder Phase des Lebenszyklus der Produktentwicklung und -technik (PDE) tatsächlich erwartet und was das für Teams bedeutet, die Produkte mit digitalen Elementen für den EU-Markt bauen.

Was der CRA unter Security by Design versteht

Anhang I des CRA legt die grundlegenden Anforderungen fest, die Produkte mit digitalen Elementen erfüllen müssen. Mehrere dieser Anforderungen spiegeln direkt Security-by-Design-Prinzipien wider:

• Produkte müssen mit einer sicheren Standardkonfiguration ausgeliefert werden.
• Produkte müssen so gestaltet sein, dass sie Angriffsflächen begrenzen, einschließlich externer Schnittstellen.
• Produkte müssen so gestaltet sein, dass sie vor unbefugtem Zugriff schützen.
• Produkte müssen die Vertraulichkeit und Integrität der von ihnen verarbeiteten Daten schützen.
• Produkte müssen ihre eigenen Auswirkungen minimieren, wenn sie kompromittiert werden.

Das sind keine Dokumentationsanforderungen. Es sind Designanforderungen. Ein Produkt, das sie nicht erfüllt, kann keine CE-Kennzeichnung erhalten, egal wie sorgfältig seine Dokumentation erstellt ist. Die Verordnung geht davon aus, dass ein konformes Produkt sicher gebaut wurde, nicht dass es gebaut und dann als sicher dokumentiert wurde.

Risikoanalyse als anfängliche Pflicht

Artikel 13 verlangt von Herstellern, eine Cybersicherheits-Risikobewertung durchzuführen, bevor ein Produkt in Verkehr gebracht wird. Diese Bewertung muss das Produktdesign prägen und als Teil der nach Anhang VII erforderlichen technischen Dokumentation dokumentiert werden.

Die Risikoanalyse muss Folgendes abdecken:

• Die bestimmungsgemäße Verwendung und die vorhersehbare Fehlanwendung des Produkts.
• Die im Produkt vorhandenen oder von ihm verarbeiteten Werte.
• Bedrohungen für diese Werte und die einem Angreifer zur Verfügung stehenden Angriffspfade.
• Den Schweregrad und die Wahrscheinlichkeit jedes identifizierten Risikos.
• Die zur Behandlung dieser Risiken ausgewählten Sicherheitskontrollen.

Das ist keine einmalige Übung. Die Verordnung verlangt, dass die Risikoanalyse überprüft und aktualisiert wird, wenn sich das Produkt ändert, wenn neue Bedrohungen entstehen und in regelmäßigen Abständen während des Produktunterstützungszeitraums. Die anfängliche Risikobewertung, die eine Konformitätserklärung stützt, muss über die Lebensdauer des Produkts hinweg aktuell gehalten werden.

Bedrohungsmodellierung als Entwicklungspraxis

Der wirksamste Weg, die vom CRA geforderte Risikoanalyse durchzuführen, ist die Bedrohungsmodellierung in der Designphase. Bedrohungsmodellierung ist die Praxis, systematisch zu identifizieren, wie ein Angreifer ein System angreifen könnte, mit strukturierten Methoden wie STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) oder PASTA (Process for Attack Simulation and Threat Analysis).

Für PDE-Entwicklungsteams besteht der praktische Wert der Bedrohungsmodellierung darin, dass sie Sicherheitslücken aufdeckt, bevor sie im Code verankert sind. Eine während der Bedrohungsmodellierung identifizierte Schwachstelle kostet ein paar Stunden Designüberarbeitung. Dieselbe Schwachstelle, nach der Veröffentlichung identifiziert, erfordert einen Patch, eine koordinierte Offenlegung, eine mögliche Meldung nach Artikel 14 und Kundenkommunikation. Die Kostendifferenz ist nicht marginal.

Der CRA schreibt keine bestimmte Methode der Bedrohungsmodellierung vor. Was er verlangt, ist der Nachweis, dass Bedrohungen systematisch berücksichtigt wurden und dass das Design die Schlussfolgerungen widerspiegelt. Ein Bedrohungsmodelldokument oder strukturierte Notizen aus einer Bedrohungsmodellierungssitzung bilden einen Teil der technischen Dokumentation, die die Konformitätserklärung stützt.

Die Rolle automatisierter Tests

Anhang I verlangt, dass Produkte vor dem Inverkehrbringen gegen ihre Sicherheitsanforderungen getestet werden. Für Softwarekomponenten von Produkten mit digitalen Elementen umfasst das typischerweise eine Kombination aus statischer Analyse, dynamischer Analyse und Abhängigkeits-Scanning.

Statische Analyse

Statisches Application Security Testing (SAST) analysiert Quellcode auf Schwachstellenmuster, ohne den Code auszuführen. Gängige Werkzeuge sind Semgrep, CodeQL und SonarQube. SAST ist wirksam beim Auffinden von Problemen der Speichersicherheit, Injektionsschwachstellen, fest codierten Zugangsdaten und unsicherer API-Nutzung. Für Teams, die kompilierte Sprachen wie C oder C++ verwenden, hat SAST in Kombination mit Fuzzing historisch die Mehrzahl der kritischen Schwachstellen vor der Veröffentlichung gefunden.

Dynamische Analyse

Dynamisches Application Security Testing (DAST) und Fuzzing testen die laufende Anwendung. DAST-Werkzeuge senden präparierte Eingaben an laufende Schnittstellen und beobachten die Antworten. Fuzzing erzeugt große Mengen halb-zufälliger Eingaben, um unerwartetes Verhalten auszulösen. Für Produkte mit Netzwerkschnittstellen, Web-APIs oder Parsing-Komponenten findet dynamisches Testen regelmäßig Schwachstellen, die die statische Analyse übersieht, insbesondere in Randfällen rund um Protokollverarbeitung und Eingabevalidierung.

Abhängigkeits-Scanning

Produkte mit digitalen Elementen enthalten häufig Open-Source-Komponenten mit eigener Schwachstellenhistorie. Der CRA verlangt von Herstellern, die Komponenten in ihren Produkten zu verfolgen und zu reagieren, wenn neue Schwachstellen in diesen Komponenten offengelegt werden. Automatisierte Werkzeuge zur Software Composition Analysis (SCA) gleichen das SBOM mit bekannten Schwachstellendatenbanken ab und erzeugen Warnungen, wenn eine Abhängigkeit verwundbar wird. Das ist kein optionales Werkzeug für die CRA-Konformität. Es ist der operative Mechanismus, über den ein Hersteller entdeckt, dass eines seiner Produkte einen Patch oder eine Artikel-14-Meldung erfordern könnte.

Technische Ergebnisse in Compliance-Nachweise verwandeln

Die oben beschriebenen Ergebnisse der Sicherheitstests sind für die CRA-Konformität nur wertvoll, wenn sie erfasst, interpretiert und als Nachweise aufbewahrt werden. Ein SAST-Scan, der keine kritischen Funde ergab, ist ein Nachweis. Ein DAST-Test, der drei Schwachstellen identifiziert und dann behoben hat, ist ein Nachweis. Ein Bedrohungsmodelldokument, das zeigt, dass ein bestimmter Angriffspfad in der Designphase berücksichtigt und entschärft wurde, ist ein Nachweis.

Die Herausforderung für Entwicklungsteams besteht darin, dass die Werkzeuge und die Compliance-Dokumentation typischerweise unterschiedlichen Funktionen gehören. Ingenieure führen Scans in CI/CD-Pipelines aus; Compliance-Manager pflegen die technische Dokumentation nach Anhang VII. Ohne eine strukturierte Brücke dazwischen sammeln sich Testergebnisse in Build-Logs, die niemand liest, und die technische Dokumentation spiegelt wider, was Ingenieure zu tun beabsichtigten, statt was sie nachweislich getan haben.

Diese Brücke früh zu bauen, als Teil des Entwicklungsworkflows statt als Compliance-Nachrüstung, ist das, was Organisationen, die eine vollständige Konformitätserklärung erstellen können, von jenen unterscheidet, die Ende 2027 unter Zeitdruck Nachweise rekonstruieren.

Die Lebenszykluspflicht

Security by Design ist kein Projekt, das endet, wenn ein Produkt ausgeliefert wird. Der CRA verlangt von Herstellern, die Sicherheit über den gesamten Unterstützungszeitraum aufrechtzuerhalten, der ein Mindestzeitraum sein muss, der zur erwarteten Produktlebensdauer im Verhältnis steht. Für die meisten vernetzten Produkte bedeutet das Jahre fortgesetzter Schwachstellenüberwachung, Patch-Entwicklung und Meldepflichten.

Die oben beschriebenen Entwicklungs- und Compliance-Prozesse müssen daher nachhaltig sein, nicht heldenhaft. Ein Bedrohungsmodell, das nie aktualisiert wird, ein SAST-Scan, der einmal bei der Veröffentlichung läuft, oder ein Abhängigkeits-Scan, auf den niemand reagiert, sind Compliance-Artefakte ohne Compliance-Wert. Der Test ist, ob die Prozesse kontinuierlich, mit derselben Sorgfalt, über die Lebensdauer jedes unterstützten Produkts im Portfolio funktionieren.

Der praktische Ausgangspunkt

Für Teams, die diese Praktiken noch nicht etabliert haben, lautet die Prioritätsreihenfolge: zuerst die Risikoanalyse (sie prägt alles andere), als Nächstes die Bedrohungsmodellierung (sie ist in der Designphase am günstigsten), drittens das Abhängigkeits-Scanning (es ist die wahrscheinlichste Quelle eines Artikel-14-Auslösers) und dann SAST und DAST, während die Entwicklungspipeline reift.

Keines davon erfordert neue Werkzeuge, die nicht bereits existieren. Die Hürde ist fast immer organisatorisch: die Erfassung von Sicherheitsnachweisen zum Teil des Entwicklungsworkflows zu machen, nicht zu einem nachträglichen Gedanken, der einmal vor einem Compliance-Audit geschieht.