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 – nicht nachträglich aufgesetzt. Zweitens müssen Schwachstellen, wenn sie entdeckt werden – von Ihnen, von Entwicklern, von Kunden –, 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

Hersteller müssen eine öffentliche Vulnerability-Disclosure-Policy haben – einen dokumentierten Prozess, wie Schwachstellen gemeldet werden können und wie mit diesen umgegangen wird. Sie müssen Schwachstellen in genutzten Open-Source-Komponenten aktiv verfolgen – nicht nur auf CVEs warten. Kritische und hochkritische Schwachstellen müssen innerhalb von 24 Stunden an ENISA gemeldet werden. Und: Patches müssen für die gesamte definierte Produktlebensdauer bereitgestellt werden.

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, Meldepfad zu ENISA. 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.