Praxisorientierte Einordnung zu Secure by Design unter dem CRA: Vom Entwicklungsprozess bis zum Schwachstellenmanagement: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für Cyber Resilience Act aufbauen.
Secure by Design bedeutet unter dem Cyber Resilience Act mehr als sichere Programmierung. Hersteller müssen Sicherheit als Produkteigenschaft planen, Risiken in Architekturentscheidungen übersetzen, ein Produkt in sicherer Standardkonfiguration ausliefern und Schwachstellen während des Unterstützungszeitraums beherrschen. Der Nachweis entsteht entlang des gesamten Entwicklungs- und Wartungsprozesses – nicht durch einen Penetrationstest kurz vor dem Release.
Dieser Beitrag verfolgt den Lebenszyklus einer fiktiven vernetzten Steuerung „ControlHub“ vom Produktkonzept bis zum Supportende. Das Beispiel zeigt, welche Entscheidungen ein Product-Security-Modell tragen muss und welche Artefakte daraus entstehen. Die Methode lässt sich auf Hardware, eingebettete Software, Desktopprodukte, Apps und verbundene Backend-Dienste übertragen.
Phase 1: Sicherheit beginnt in der Produktdefinition
ControlHub soll Maschinenzustände erfassen, Parameter ändern und Diagnosedaten an einen Cloud-Dienst übertragen. Schon diese Kurzbeschreibung enthält sicherheitsrelevante Annahmen: Wer darf Parameter verändern? Welche Folgen hat eine Manipulation? Muss das Produkt ohne Cloud sicher weiterarbeiten? Welche Daten verlassen den Standort? Wie wird ein gebrauchtes Gerät zurückgesetzt?
Vor dem ersten Architekturentwurf dokumentiert das Produktteam bestimmungsgemäße und vernünftigerweise vorhersehbare Verwendung. Dazu gehören reale Einsatzumgebungen, Benutzerrollen, erwartete Netzanbindung und typische Fehlkonfigurationen. Ein Hersteller kann sich nicht darauf beschränken, dass nur ideal geschulte Administratoren das Produkt in perfekt segmentierten Netzen verwenden, wenn ein breiterer Einsatz vorhersehbar ist.
Aus dieser Beschreibung entstehen messbare Security-Ziele. Beispielsweise dürfen Parameteränderungen nur authentisierten Rollen möglich sein; der Verlust der Cloud-Verbindung darf keinen unsicheren Anlagenzustand erzeugen; Updates müssen vor Installation authentifiziert werden; und eine lokale Werksschnittstelle darf im Normalbetrieb keinen privilegierten Zugang bieten. Diese Ziele werden Teil der Produktanforderungen und erhalten Eigentümer.
Phase 2: Threat Modeling steuert die Architektur
Das Threat Model zerlegt ControlHub in Komponenten, Datenflüsse und Vertrauensgrenzen. Erfasst werden Bedienoberfläche, lokale Dienste, Geräteschnittstellen, Updatefunktion, Schlüsselmaterial, Cloud-API und Administrationskanäle. Für jede Grenze prüft das Team mögliche Identitätsfälschung, Manipulation, Informationsabfluss, Verfügbarkeitsverlust und Rechteausweitung.
Wichtig ist die Wirkung auf den Produktzweck. Bei einer Steuerung ist ein kurzer Kommunikationsausfall möglicherweise tolerierbar, eine unautorisierte Parameteränderung hingegen sicherheitskritisch. Das Team bewertet nicht nur Eintrittswahrscheinlichkeit, sondern auch technische und physische Auswirkungen. Sicherheitsfunktionen des übergeordneten Prozesses dürfen dabei nicht mit Cybersecurity-Kontrollen verwechselt werden; ihre Abhängigkeit muss jedoch verstanden werden.
Architekturentscheidungen werden als Reaktion auf konkrete Risiken festgehalten. ControlHub trennt beispielsweise Diagnose und Steuerung in unterschiedliche Berechtigungsdomänen, speichert private Schlüssel in geschützter Hardware, signiert Updatepakete und begrenzt Cloud-Befehle auf einen eng definierten Funktionsumfang. Jede Entscheidung enthält Annahmen und verbleibende Grenzen. So bleibt später nachvollziehbar, warum die Architektur gewählt wurde.
Phase 3: Sichere Standards statt sicherer Installationsanleitung
Ein Produkt ist nicht Secure by Default, wenn die Dokumentation empfiehlt, unsichere Funktionen nach der Installation abzuschalten. ControlHub wird deshalb mit deaktivierten nicht benötigten Diensten ausgeliefert. Das erste Administratorkonto verlangt eine individuelle Aktivierung; gemeinsame Standardpasswörter existieren nicht. Externe Schnittstellen sind zunächst geschlossen und werden nur für den gewählten Einsatzfall aktiviert.
Defaults müssen zugleich betriebsfähig sein. Ein Updatezwang ohne kontrollierbares Wartungsfenster kann in Industrieumgebungen die Verfügbarkeit gefährden. Deshalb unterscheidet das Produkt zwischen sicherheitskritischer Benachrichtigung, planbarer Installation und klar dokumentierter Notfallbehebung. Betreiber sehen Supportstatus und verfügbare Updates, können die Installation aber in ihren Betriebsprozess integrieren.
Auch Protokollierung braucht ein ausgewogenes Design. ControlHub zeichnet Authentisierung, Rollenänderung, Konfigurationsänderung, Update und sicherheitsrelevante Fehler mit geschützter Zeitreferenz auf. Geheimnisse und unnötige personenbezogene Daten werden nicht protokolliert. Ereignisse können an eine zentrale Überwachung übergeben werden, bleiben aber lokal verfügbar, wenn die Verbindung ausfällt.
Phase 4: Entwicklung reproduzierbar und überprüfbar machen
Security-Anforderungen werden in denselben Backlogs und Freigaben geführt wie funktionale Anforderungen. Kritische Codebereiche benötigen Review durch eine zweite qualifizierte Person. Entwicklungsumgebungen, Build-Pipelines und Artefakt-Repositories sind gegen unbefugte Änderungen geschützt. Signaturschlüssel liegen nicht als normale Pipeline-Variable vor, sondern werden über einen kontrollierten Signierprozess genutzt.
Automatisierte Prüfungen decken unterschiedliche Fehlerklassen ab: statische Codeanalyse, Abhängigkeits- und Lizenzprüfung, Secret Detection, Container- oder Firmwareanalyse sowie Tests der Infrastrukturkonfiguration. Findings werden nicht pauschal nach Werkzeugbewertung übernommen. Das Team prüft Erreichbarkeit und Produktkontext und dokumentiert, ob ein Fund behoben, kompensiert oder begründet akzeptiert wird.
Reproduzierbarkeit ist für spätere Schwachstellenbehandlung entscheidend. Zu jedem Release müssen Quellstand, Buildumgebung, Werkzeuge, Konfigurationen, Komponenten und erzeugte Artefakte nachvollziehbar sein. Andernfalls kann ein Hersteller zwar eine Schwachstelle kennen, aber nicht zuverlässig feststellen, welche ausgelieferten Versionen betroffen sind.
Phase 5: Die Software-Lieferkette als Teil des Produkts behandeln
ControlHub verwendet Betriebssystemkomponenten, Kryptobibliotheken, Webframework, Cloud-SDK und Drittanbieter-Firmware. Das Produktteam führt diese Bestandteile mit Version, Herkunft, Einsatzort und Supportstatus. Eine SBOM wird automatisch pro Release erzeugt und unveränderbar mit der Produktversion abgelegt.
Die Auswahl einer Komponente berücksichtigt mehr als aktuelle Schwachstellen. Relevant sind Wartungsaktivität, sichere Veröffentlichungswege, Reaktionsfähigkeit des Projekts, Lizenz, Abhängigkeitstiefe und Austauschbarkeit. Eine kleine Bibliothek in einer kritischen Updatefunktion kann ein größeres Langzeitrisiko darstellen als ein umfangreiches, gut gepflegtes Framework.
Bei kommerziellen Lieferanten werden Sicherheitsmeldungen, Patchbereitstellung, Supportende und Informationen über Unterkomponenten vertraglich geregelt. Wenn ein Lieferant ausfällt, bleibt der Hersteller gegenüber dem Markt verantwortlich. Deshalb benötigt jedes kritische Fremdteil eine Strategie: aktualisieren, isolieren, ersetzen oder – bei vertretbarem Risiko – kontrolliert weiterbetreiben.
Phase 6: Security Verification als Risikonachweis
Die Testplanung leitet sich aus Threat Model und Anforderungen ab. Für ControlHub werden unter anderem Rechtewechsel, Session Handling, manipulierte Updatepakete, Rollback, API-Missbrauch, Ausfall der Cloud, Ressourcenausschöpfung und Wiederherstellung geprüft. Negative Tests untersuchen nicht nur erwartete Funktionen, sondern bewusst falsche Sequenzen und Eingaben.
Fuzzing kann Parser und Protokollschnittstellen belasten, während Penetrationstests Angriffswege über mehrere Komponenten prüfen. Kryptografische Funktionen werden nicht durch „verschlüsselt vorhanden“ abgehakt; Schlüsselerzeugung, Speicherung, Rotation, Zertifikatsprüfung und Fehlerverhalten gehören zum Prüfbereich. Für Hardware werden Debug- und Fertigungsschnittstellen einbezogen.
Ein externer Penetrationstest ist wertvoll, ersetzt aber weder kontinuierliche Tests noch interne Produktkenntnis. Sein Scope muss reale Angriffsflächen und verwendbare Rollen enthalten. Findings werden bis zur Behebung oder formalen Risikoentscheidung verfolgt. Der Abschlussbericht ist ein Teil der Evidenz, nicht die gesamte Konformitätsbegründung.
Phase 7: Releaseentscheidung mit Security-Kriterien
Vor Freigabe prüft ein Product Security Gate, ob Risikobewertung, Tests, Komponentenliste, Benutzerinformationen und offene Abweichungen zur vorgesehenen Version passen. Kritische Findings blockieren den Release. Für andere Abweichungen gibt es eine dokumentierte Entscheidung mit Kompensation, Verantwortlichem und Frist.
Das Team validiert außerdem den Auslieferungskanal. Kunden müssen authentische Artefakte erkennen können; Downloadportale und Updateinfrastruktur benötigen Schutz, Monitoring und Wiederherstellung. Ein sicher entwickeltes Produkt kann durch einen kompromittierten Distributionsweg vollständig unterlaufen werden.
Die Dokumentation erklärt sichere Installation, notwendige Systemvoraussetzungen, Änderung von Zugangsdaten, relevante Protokolle, Updateverfahren und Supportdauer. Hinweise werden für die Zielgruppe geschrieben. Eine industrielle Instandhaltung benötigt andere Details als ein Endverbraucher.
Phase 8: Vulnerability Handling nach Markteinführung
Nach dem Release beginnt die längste Phase. ControlHub überwacht eingesetzte Komponenten, nimmt externe Meldungen über einen veröffentlichten Security-Kontakt entgegen und bewertet neue Informationen. Die Triage klärt Reproduzierbarkeit, betroffene Versionen, Ausnutzung, Auswirkungen und mögliche Abhilfe. Eine zentrale Fallnummer verbindet technische Analyse, Rechtsbewertung und Kundenkommunikation.
Für Fixes gilt derselbe sichere Entwicklungs- und Testprozess wie für neue Funktionen, jedoch mit beschleunigten, vorher definierten Pfaden. Ein Notfallupdate darf keine unbekannten Seiteneffekte in kritischen Umgebungen erzeugen. Deshalb werden Rollback, Kompatibilität und gestufte Verteilung vorbereitet. Security Advisories nennen klare betroffene Versionen und konkrete Gegenmaßnahmen.
Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach CRA über die Single Reporting Platform gemeldet werden. Diese Entscheidung darf nicht erst getroffen werden, wenn alle technischen Details bekannt sind. Ein geübter Eskalationsweg stellt sicher, dass frühe Meldung, Folgebericht und Abschlussbericht fristgerecht entstehen.
Phase 9: Wesentliche Änderungen und Supportende
Neue Funktionen, Plattformwechsel oder Änderungen an Cloud-Komponenten können das Risikoprofil wesentlich verändern. Das Änderungsverfahren prüft deshalb nicht nur funktionale Kompatibilität, sondern auch neue Schnittstellen, Vertrauensgrenzen, Datenflüsse und Konformitätsfolgen. Dass eine Version denselben Produktnamen trägt, bedeutet nicht, dass die alte Bewertung unverändert gilt.
Der Unterstützungszeitraum wird bereits in der Produktstrategie festgelegt und Kunden transparent mitgeteilt. Vor seinem Ende erhalten Nutzer rechtzeitig Informationen und einen sicheren Migrationsweg. Ein Gerät, das nach Supportende weiterarbeitet, darf nicht stillschweigend den Eindruck laufender Sicherheitsversorgung erzeugen.
Bei Außerbetriebnahme müssen Schlüssel, Konten und Kundendaten sicher gelöscht oder übertragen werden können. Backend-Dienste und Zertifikate werden kontrolliert beendet. Die Lebenszyklusakte hält fest, welche Versionen nicht mehr unterstützt werden und welche Pflichten für bereits gemeldete Fälle fortbestehen.
Die wichtigsten Prozessartefakte im Überblick
- Produkt-Scope, Rollen- und Klassifizierungsentscheidung.
- Versioniertes Architekturmodell mit Datenflüssen und Vertrauensgrenzen.
- Threat Model, Risikoregister und genehmigte Restrisiken.
- Rückverfolgbare Security-Anforderungen und Architekturentscheidungen.
- Releasebezogene SBOM und Bewertung kritischer Komponenten.
- Teststrategie, Ergebnisse und Behandlung von Findings.
- Security Gate mit nachvollziehbarer Releasefreigabe.
- Sichere Installations-, Update- und Außerbetriebnahmeanleitung.
- CVD-Policy, Triageverfahren, Advisories und CRA-Melde-Playbook.
- Technische Dokumentation und EU-Konformitätsunterlagen.
Diese Artefakte sollten keine voneinander getrennten Pflichtdokumente sein. Anforderungen verweisen auf Risiken, Tests auf Anforderungen, Komponenten auf Releases und Schwachstellenfälle auf betroffene Versionen. Diese Verknüpfung macht den Secure-by-Design-Prozess zugleich effizient und prüfbar.
Fazit: Sicherheit wird entworfen, nachgewiesen und weiterbetrieben
Secure by Design unter dem CRA ist ein durchgängiges Produktmodell. Es beginnt mit realistischem Nutzungskontext, prägt Architektur und Standardkonfiguration, schützt Entwicklung und Lieferkette und endet nicht vor dem Supportende. Hersteller, die Risiken und Nachweise bereits im normalen Produktprozess verbinden, vermeiden eine teure Nachdokumentation und können bei neuen Schwachstellen deutlich schneller handeln.
BlackMount unterstützt Produktorganisationen dabei, Secure Development, CRA-Nachweise und Vulnerability Handling praxisnah zu verbinden. Weitere Informationen finden Sie unter Cyber Resilience Act Beratung.
