CRA Secure by Design: Cybersicherheit von der Produktidee bis zum Release

Secure by Design bedeutet unter dem Cyber Resilience Act, dass Cybersicherheit nicht erst vor dem Release geprüft, sondern von der ersten Produktentscheidung an mitentwickelt wird. Hersteller müssen Produkte mit digitalen Elementen risikobasiert konzipieren, entwickeln und herstellen. Sicherheitsanforderungen gehören deshalb in Produktziele, Architektur, Entwicklungsprozess, Tests, Lieferkette und spätere Wartung.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Technische Produktsicherheit. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Architekturentscheidungen sollten Kryptografie einschließlich Schlüssellebenszyklus früh berücksichtigen. Der Abgleich mit einschlägigen CRA-Normen hilft, Anforderungen und Nachweislücken nachvollziehbar festzuhalten.

Was verlangt der CRA bei Secure by Design?

Der CRA verlangt, dass Produkte mit digitalen Elementen auf Grundlage der Cybersicherheitsrisiken ein angemessenes Sicherheitsniveau erreichen. Artikel 13 und Anhang I verbinden diese Pflicht mit konkreten Produkteigenschaften: keine bekannten ausnutzbaren Schwachstellen beim Inverkehrbringen, sichere Grundeinstellungen, Zugriffsschutz, Vertraulichkeit, Integrität, Verfügbarkeit, Datenminimierung, begrenzte Angriffsflächen, Exploit-Mitigation sowie Security Logging.

Damit reicht es nicht, kurz vor der Markteinführung einen Scanner laufen zu lassen. Die CRA-Risikobewertung muss bereits die Entwicklungsentscheidungen beeinflussen. Erkennt das Unternehmen zum Beispiel, dass ein Gerät aus dem Internet erreichbar ist, müssen Architektur, Authentisierung, Updatefähigkeit und Monitoring dieses Risiko von Anfang an berücksichtigen.

Wann beginnt Secure by Design?

Secure by Design beginnt bei Zweckbestimmung, Produktanforderungen und Betriebsumgebung. Noch bevor Technologie gewählt wird, sollte geklärt sein, welche Funktionen sicherheitskritisch sind, welche Daten verarbeitet werden, wer auf das Produkt zugreifen darf und welche Missbrauchsszenarien vernünftigerweise vorhersehbar sind.

Diese frühen Entscheidungen sind wichtig, weil spätere Sicherheitskorrekturen teuer oder technisch unvollständig sein können. Wer beispielsweise eine Architektur ohne sichere Updatefunktion entwickelt, kann diese Fähigkeit kurz vor dem Release nur schwer zuverlässig nachrüsten. Der CRA betrachtet deshalb den gesamten Lebenszyklus und nicht nur den Endzustand.

Wie werden aus Risiken konkrete Sicherheitsanforderungen?

Jedes relevante Risiko sollte zu einer nachvollziehbaren Produktanforderung führen. Ein Risiko unberechtigter Fernzugriffe kann zum Beispiel Anforderungen an starke Authentisierung, Rollenmodelle, Rate Limiting und Protokollierung erzeugen. Risiken für vertrauliche Daten können Verschlüsselung, Schlüsselmanagement und Zugriffstrennung notwendig machen.

Welche Rolle spielt die Architektur?

Architektur entscheidet, welche Angriffsflächen überhaupt entstehen. Secure by Design bedeutet deshalb, unnötige Schnittstellen, Dienste, Berechtigungen und Vertrauensbeziehungen zu vermeiden. Funktionen, die nicht benötigt werden, sollten nicht vorsorglich offen bleiben.

Hilfreich ist eine dokumentierte Trust-Boundary- und Datenflussanalyse. Sie zeigt, wo Daten Zonen wechseln, welche Komponenten einander vertrauen und an welchen Stellen ein Angreifer Eingaben kontrollieren kann. Daraus lassen sich Sicherheitskontrollen deutlich zielgerichteter ableiten als aus einer generischen Checkliste.

Was bedeutet Angriffsfläche begrenzen?

Anhang I verlangt ausdrücklich, dass Produkte so konzipiert, entwickelt und hergestellt werden, dass Angriffsflächen einschließlich externer Schnittstellen begrenzt werden. In der Praxis bedeutet das: nicht benötigte Ports schließen, Debug-Schnittstellen absichern, Verwaltungsfunktionen trennen, APIs auf notwendige Operationen beschränken und Standarddienste deaktivieren.

Die Angriffsfläche sollte bei jeder größeren Produktänderung erneut betrachtet werden. Ein neues Cloud-Feature kann beispielsweise eine bisher lokale Anwendung ins Internet öffnen. Dann verändert sich das Risikoprofil auch dann, wenn der bestehende Code unverändert bleibt.

Wie passt Secure by Default zu Secure by Design?

Secure by Default ist ein Teil von Secure by Design. Eine technisch sichere Funktion hilft wenig, wenn sie ab Werk deaktiviert ist oder eine unsichere Konfiguration der einfachste Weg bleibt. Deshalb müssen sichere Grundeinstellungen bereits im Produktkonzept berücksichtigt werden.

Dazu gehören unter anderem keine universellen Standardpasswörter, minimal notwendige Rechte, sichere Netzwerkoptionen und – soweit anwendbar – aktivierte automatische Sicherheitsupdates. Der separate Beitrag CRA Secure by Default vertieft die Konfigurationsanforderungen.

Wie verändert Secure by Design den Entwicklungsprozess?

Security wird zu einem normalen Qualitätskriterium jeder Änderung. Anforderungen erhalten Sicherheitsakzeptanzkriterien, Code Reviews berücksichtigen risikorelevante Muster und Releases werden nicht nur funktional, sondern auch sicherheitsbezogen freigegeben.

Das muss kein schwerfälliger Prozess sein. Kleine Teams können mit wenigen verpflichtenden Prüfpunkten starten: Security-Auswirkung bei neuen Features, Review sicherheitskritischer Änderungen, automatisierte Abhängigkeits- und Codeprüfungen sowie ein Release-Gate für offene kritische Schwachstellen.

Welche Rolle spielen sichere Entwicklungsrichtlinien?

Entwicklungsrichtlinien übersetzen abstrakte CRA-Anforderungen in konkrete Arbeitsregeln. Sie können Vorgaben für Authentisierung, Geheimnisse, Kryptografie, Fehlerbehandlung, Eingabevalidierung, Logging und Abhängigkeiten enthalten.

Wichtig ist, dass diese Regeln zur eingesetzten Technologie passen. Eine allgemeine Policy mit hundert Punkten, die kein Entwickler nutzt, ist weniger wirksam als zehn klare Regeln mit Beispielen, automatisierten Prüfungen und Review-Kriterien. Änderungen sollten aus realen Schwachstellen und Lessons Learned zurück in die Richtlinie fließen.

Wie werden Drittkomponenten Secure by Design berücksichtigt?

Secure by Design endet nicht an der Grenze des eigenen Codes. Artikel 13 verlangt Due Diligence bei Komponenten Dritter, einschließlich Open Source. Schon bei der Auswahl sollte geprüft werden, ob eine Kernkomponente aktiv gepflegt wird, Sicherheitsmeldungen veröffentlicht, Updates verfügbar sind und der geplante Supportzeitraum zum eigenen Produkt passt.

Eine günstige Bibliothek ohne Maintainer kann später zum strukturellen Risiko werden. Der CRA Lieferanten- & Drittkomponentencheck bietet hierfür eine praktische Prüfbasis.

Welche Security Tests gehören zum Ansatz?

Die Tests richten sich nach Risiko und Produkt. Typische Bausteine sind Codeanalyse, Abhängigkeitsprüfung, Fuzzing, Schnittstellentests, Authentisierungs- und Berechtigungstests, Penetrationstests sowie Tests der Update- und Recovery-Funktion.

Entscheidend ist die Kombination. Ein externer Pentest kann wertvoll sein, ersetzt aber keine kontinuierlichen Prüfungen während der Entwicklung. Anhang I Teil II verlangt wirksame und regelmäßige Tests und Reviews der Produktsicherheit. Deshalb sollte der Testplan bereits aus der Risikobewertung entstehen.

Was muss vor einem Release geprüft werden?

Vor dem Inverkehrbringen sollte ein Security Release Gate sicherstellen, dass bekannte ausnutzbare Schwachstellen behandelt, sicherheitsrelevante Anforderungen umgesetzt und erforderliche Nachweise vorhanden sind. Offene Risiken brauchen eine dokumentierte Entscheidung.

• Risikobewertung für den Release aktuell?
• Bekannte kritische oder ausnutzbare Schwachstellen offen?
• SBOM und Komponentenstände aktuell?
• Security Tests bestanden?
• Update- und Recovery-Weg geprüft?
• Sichere Standardkonfiguration bestätigt?
• Nutzerinformationen und Supportzeitraum aktuell?

Wie geht Secure by Design nach dem Release weiter?

Der Ansatz endet nicht mit CE-Kennzeichnung oder Verkauf. Neue Schwachstellen, geänderte Angriffsverfahren und aktualisierte Komponenten können die Sicherheitslage verändern. Hersteller müssen deshalb während des Supportzeitraums Schwachstellen behandeln und die Risikobewertung gegebenenfalls aktualisieren.

Genau hier verbindet sich Secure by Design mit dem Schwachstellenmanagement: Erkenntnisse aus dem Feld müssen zurück in Architektur, Entwicklungsrichtlinien und Tests fließen.

Wie dokumentiert man Secure by Design?

Für die technische Dokumentation sollte nachvollziehbar sein, welche Risiken betrachtet, welche Sicherheitsanforderungen daraus abgeleitet und wie diese umgesetzt und geprüft wurden. Sinnvoll sind Architekturdiagramme, Datenflüsse, Security-Anforderungen, Testnachweise, Review-Entscheidungen und Verweise auf relevante Entwicklungsrichtlinien.

Es geht nicht darum, jedes Entwicklergespräch zu archivieren. Die Dokumentation muss aber zeigen, dass Sicherheitsentscheidungen systematisch und produktbezogen getroffen wurden. Der geplante Artikel zur CRA-technischen Dokumentation behandelt die Produktakte im Detail.

Welche Fehler widersprechen Secure by Design?

Typisch sind Sicherheitsprüfungen erst kurz vor Release, ungeprüfte Drittkomponenten, feste Zugangsdaten im Produkt, unnötig offene Schnittstellen, fehlende Updatefähigkeit und eine Architektur ohne klare Vertrauensgrenzen. Ebenfalls problematisch ist ein Sicherheitskonzept, das nur bekannte Angriffe abbildet, aber Änderungen am Produkt nicht neu bewertet.

Ein weiteres Warnsignal ist die Trennung zwischen „Security-Team“ und Entwicklung. Wenn nur eine Spezialabteilung Sicherheitsanforderungen kennt, werden sie zu spät entdeckt. Produktmanagement, Engineering, QA und Support brauchen jeweils einen klaren Anteil am Sicherheitsprozess.

Wie können KMU Secure by Design pragmatisch umsetzen?

KMU müssen keinen komplexen Konzernprozess kopieren. Ein brauchbarer Einstieg besteht aus fünf Artefakten: produktbezogene Risikobewertung, kurze Security-Anforderungsliste, Architektur-/Datenflussübersicht, Security-Testplan und Release-Checkliste.

Hinzu kommen ein Komponentenregister sowie ein klarer Prozess für Schwachstellen und Sicherheitsupdates. Diese wenigen Bausteine erzeugen bereits einen geschlossenen Kreislauf, wenn sie tatsächlich für jede relevante Änderung verwendet werden.

Wie lässt sich Secure by Design in bestehende agile Teams integrieren?

Security muss kein eigener Sprint sein. Sicherheitsrelevante Akzeptanzkriterien können direkt in User Stories aufgenommen werden. Ein kurzes Threat-Review bei größeren Features, automatisierte Prüfungen in CI/CD und ein Security-Feld im Pull Request reichen häufig, um kontinuierliche Aufmerksamkeit zu erzeugen.

Für besonders kritische Änderungen sollte ein tieferes Review vorgesehen werden. Beispiele sind neue Authentisierungswege, kryptografische Änderungen, Cloud-Anbindung, Remote Administration oder Verarbeitung besonders sensibler Daten. Dadurch wird Aufwand risikobasiert statt pauschal verteilt.

Welche Rolle spielen Fehler- und Missbrauchsszenarien?

Ein Produkt sollte nicht nur bei korrekter Nutzung sicher sein. Der CRA bezieht auch vernünftigerweise vorhersehbare Verwendung und Bedingungen ein. Deshalb sollten Teams Missbrauchsfälle betrachten: manipulierte Eingaben, gestohlene Zugangsdaten, unzuverlässige Netzwerke, übermäßige Requests oder ein kompromittiertes angebundenes System.

Solche Szenarien helfen, Schutzmechanismen realistisch zu testen. Ein Zugriffsschutz ist beispielsweise erst dann belastbar, wenn geprüft wurde, ob Rollen umgangen, Tokens wiederverwendet oder Verwaltungsfunktionen direkt angesprochen werden können.

Wie bewertet man Änderungen an einer bestehenden Architektur?

Jede relevante Änderung sollte einen Security-Impact-Check auslösen. Dabei reicht eine kurze Fragefolge: neue Schnittstelle? neue Daten? neue Abhängigkeit? neue Berechtigung? geänderte Vertrauensgrenze? veränderte Betriebsumgebung? Wenn eine Antwort ja lautet, sollte die Risikobewertung gezielt überprüft werden.

Bei tiefgreifenden Änderungen kann zusätzlich die Frage entstehen, ob eine wesentliche Änderung nach CRA vorliegt. Das betrifft insbesondere Veränderungen, die Zweckbestimmung oder Risikoprofil wesentlich beeinflussen.

Wie unterstützt Secure by Design die Konformitätsbewertung?

Eine Konformitätsbewertung lässt sich wesentlich leichter vorbereiten, wenn Sicherheitsnachweise während der Entwicklung entstehen. Werden Anforderungen, Tests, Komponentenstände und Entscheidungen erst am Ende rekonstruiert, entstehen Lücken und unnötiger Aufwand.

Secure by Design schafft deshalb nicht nur bessere Sicherheit, sondern eine belastbare Evidenzkette. Diese kann später mit der CRA-Konformitätsbewertung, technischen Dokumentation und EU-Konformitätserklärung verbunden werden.

Wie sieht eine Security Definition of Done aus?

Eine Security Definition of Done übersetzt Secure by Design in konkrete Freigabekriterien. Für sicherheitsrelevante Änderungen kann sie verlangen, dass die Risikobewertung aktualisiert, neue Schnittstellen dokumentiert, Berechtigungen geprüft, Abhängigkeiten bewertet und passende Security-Tests durchgeführt wurden. Dadurch wird Sicherheit nicht vom Gedächtnis einzelner Entwickler abhängig.

Die Kriterien sollten nach Risiko gestuft sein. Eine reine Textänderung braucht kein Threat Modeling; eine neue Remote-Administrationsfunktion dagegen schon. So bleibt der Prozess praktikabel und konzentriert zusätzliche Arbeit dort, wo neue Angriffsflächen entstehen.

Welche Rolle können Security Champions übernehmen?

In größeren oder verteilten Entwicklungsteams können Security Champions als lokale Ansprechpartner dienen. Sie ersetzen kein zentrales Product-Security-Team, helfen aber dabei, Sicherheitsfragen früh zu erkennen, Richtlinien in den Entwicklungsalltag zu übersetzen und Findings aus Tests oder Vorfällen zurück ins Team zu tragen.

Für KMU kann diese Rolle Teil einer bestehenden Entwickler- oder Architekturverantwortung sein. Wichtig ist, dass Zeit, Wissen und Eskalationsweg tatsächlich vorhanden sind und die Rolle nicht nur auf dem Organigramm steht.

Wie entsteht eine belastbare Evidenzkette?

Secure by Design wird prüfbar, wenn Anforderungen, Umsetzung und Nachweis miteinander verknüpft sind. Ein Risiko verweist auf eine Security-Anforderung, diese auf Architektur oder Implementierung und anschließend auf einen Test oder Review. Bei Änderungen lässt sich damit erkennen, welche Nachweise erneut geprüft werden müssen.

Eine solche Kette reduziert später den Aufwand für technische Dokumentation und Konformitätsbewertung, weil Entscheidungen nicht rückwirkend aus Tickets, Chats und Entwicklerwissen rekonstruiert werden müssen.

Wie wird Secure by Design in der Release-Freigabe sichtbar?

Vor einem Release sollte das Team nicht nur offene Funktionsfehler prüfen, sondern auch sicherheitsrelevante Annahmen aus Architektur, Risikobewertung und Tests. Ein kurzes Security-Gate mit dokumentierter Entscheidung verhindert, dass bekannte Restpunkte ohne Owner oder Begründung in die Veröffentlichung rutschen. Dabei sollte feststehen, welche Risiken akzeptiert, welche Maßnahmen verschoben und welche Nachweise in der technischen Dokumentation aktualisiert werden müssen.

Wo steht Secure by Design im CRA?

Die verbindliche Grundlage ergibt sich vor allem aus Artikel 13 und Anhang I Teil I der Verordnung (EU) 2024/2847. Dort werden risikobasiertes Design und konkrete grundlegende Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festgelegt.