CRA Readiness: Secure-by-Design + Vulnerability Handling

Edouard Jacques

Managing Director, Cyber Culture

Der Cyber Resilience Act lässt sich auf zwei Kernprinzipien herunterbrechen: Erstens muss Sicherheit von Anfang an im Produkt stecken, statt nachträglich aufgesetzt zu werden. Zweitens müssen Schwachstellen, ob von Ihnen, von Entwicklern oder von Kunden entdeckt, systematisch und fristgerecht gehandhabt werden. Beide Anforderungen klingen einfach. In der Umsetzung zeigen sich regelmäßig die gleichen strukturellen Lücken.

Secure-by-Design: Was das in der Praxis bedeutet

Secure-by-Design ist kein Security Testing am Ende des Sprints. Es ist die systematische Integration von Sicherheit in jeden Entwicklungsschritt. In der Anforderungsphase: Sicherheitsanforderungen als explizite funktionale Anforderungen, nicht als nachgelagerte Ergänzung. In der Designphase: Threat Modeling für neue Features und Architekturentscheidungen. Im Code: Secure Coding Guidelines, automatisierte SAST-Scans, keine Known-Vulnerable-Dependencies. Im Testing: DAST-Scans, manuelle Security Reviews für kritische Features. Im Deployment: dokumentierte Sicherheitskonfiguration, Patch-Management-Plan, keine Default-Passwörter.

Das klingt aufwendig. In der Praxis ist es vor allem eine Frage der richtigen Werkzeuge und der richtigen Prozessverankerung. Viele Teams haben bereits einzelne dieser Elemente, aber kein kohärentes Gesamtbild.

Vulnerability Handling: Was der CRA konkret fordert

Ab dem 11. Dezember 2027 müssen Hersteller eine Strategie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure) umsetzen und eine Kontaktadresse für Schwachstellenmeldungen angeben, die Nutzer finden können. Sie müssen die Komponenten ihrer Produkte mit einer Software-Stückliste (SBOM) dokumentieren und Schwachstellen auch in genutzten Open-Source-Komponenten aktiv verfolgen, statt nur auf CVEs zu warten. Sicherheitsupdates sind für den gesamten Unterstützungszeitraum bereitzustellen, der in der Regel mindestens fünf Jahre beträgt.

Schon seit dem 11. September 2026 gilt die Meldepflicht nach Art. 14 CRA, auch für Produkte, die bereits auf dem Markt sind. Zu melden sind aktiv ausgenutzte Schwachstellen, nicht jede kritische Schwachstelle. Die Meldung geht über die einheitliche Meldeplattform der ENISA gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden und Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur verfügbar ist. Für schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts betreffen, gilt dasselbe mit einem Monat für den Abschlussbericht.

Was wir liefern

Wir helfen Ihnen, Secure-by-Design pragmatisch in Ihren Entwicklungsprozess zu integrieren, ohne Ihren Entwicklungsrhythmus zu unterbrechen. Und wir bauen mit Ihnen einen strukturierten Vulnerability-Handling-Prozess auf: Disclosure Policy, Tracking-Prozess, SBOM-Tooling, Meldeweg über die ENISA-Plattform. Alles CRA-konform und in Ihrer Realität umsetzbar.

Was der Unterschied zwischen Theorie und Praxis ist: Viele Entwicklungsteams haben einzelne Elemente von Secure-by-Design bereits. Aber kein kohärentes Gesamtbild. Wir helfen Ihnen, aus den vorhandenen Teilen ein vollständiges, CRA-konformes Bild zu machen und die wirklich fehlenden Teile strukturiert nachzubauen.