CRA-Compliance ist kein singuläres Ereignis, sondern das Zusammenspiel aus drei Bereichen. Unsere Timeline zeigt, wie diese Hebel ineinandergreifen, um am Ende die CE-Kennzeichnung zu ermöglichen.

Um das Ziel „CRA Compliance“ zu erreichen, müssen diese drei Stränge parallel bearbeitet werden:

• Prävention (Hebel 1): Das Fundament bildet das Risikomanagement.
• Produktentwicklung (Hebel 2): Dies ist der Kern dieses Beitrags. Hier verzahnen sich Requirements Management, Testmethoden und Vulnerability Management in einem iterativen Prozess.
• Absicherung der Lieferkette (Hebel 3): Da Sie für Komponenten Dritter haften, ist das Lieferantenmanagement essenziell.

Um Hebel 2 (Produktentwicklung) technisch zu meistern, nutzen wir die VDI 2206. Sie liefert das V-Modell, das wir für Security-Zwecke adaptiert haben. Es strukturiert die Komplexität und stellt sicher, dass keine Sicherheitslücke durchrutscht.

Lassen Sie uns dieses Modell im Detail betrachten, denn hier entscheidet sich die Compliance:

Die linke Seite: Requirements & Specification Process

Hier wird „Security by Design“ geboren. Wir arbeiten uns vom Groben ins Detail (Top-Down):

1. Customer Requirements and Targets: Ganz oben stehen die Anforderungen aus Sicht des Kunden und des Marktes. Hier nutzen wir die ISO/IEC 25010, um qualitative Sicherheitsziele zu definieren (z. B. „Vertraulichkeit von Nutzerdaten“).
2. Complete Product (Functional & Technical Specifications): Die Anforderungen werden in technische Funktionen übersetzt. Hier kommt oft die IEC 62443 (Cybersicherheit in industriellen Automatisierungs- und Steuerungssystemen) ins Spiel, um konkrete Security-Levels für das Gesamtsystem festzulegen.
3. System & Component Specification: Das System wird zerlegt. Für jedes Subsystem und jede Komponente werden spezifische Sicherheitsvorgaben definiert (z. B. „Verschlüsselung des Bus-Systems“, „Secure Boot für Controller X“).
4. Hardware & Software Specification: Auf der untersten Ebene landen wir bei den konkreten Vorgaben für die Entwickler (Coding Guidelines, Hardware-Sicherheitsmodule).

Die Talsohle: Implementation

Hier findet die eigentliche Wertschöpfung statt – das Coding und die Hardware-Fertigung. Wichtig: Moderne agile Methoden (Scrum/Kanban) finden hier ihren Platz und stehen nicht im Widerspruch zum V-Modell.

Die rechte Seite: Integration & Test Process

Hier beweisen wir, dass das System sicher ist (Bottom-Up). Jede Ebene der linken Seite hat ein passendes Gegenstück auf der rechten Seite (Verifikation & Validierung):

1. Hardware & Software Test: Unit-Tests prüfen einzelne Code-Bausteine auf Schwachstellen (z. B. Buffer Overflows).
2. Component & System Integration Test: Wir fügen die Teile zusammen. Funktionieren die Schnittstellen sicher? Greifen die Verschlüsselungen zwischen den Modulen?
3. Validation (Complete Product): Ganz oben wird geprüft: Haben wir das gebaut, was der Kunde und der Gesetzgeber (CRA) wollten? Ist das Produkt im Nutzungskontext sicher?

Werfen Sie einen Blick auf die Grafik: Über dem V-Modell schwebt der Begriff „Vulnerability Management“.

Der CRA fordert, dass aktiv ausgenutzte Schwachstellen binnen 24 Stunden gemeldet werden. Das V-Modell ist daher kein einmaliger „Wasserfall“, sondern ein Kreislauf. Ein Sicherheitsupdate ist im Grunde ein Mikro-Durchlauf des V-Modells:

1. Schwachstelle identifizieren (Requirements/Analyse).
2. Lösung coden (Implementation).
3. Testen und Validieren (Integration & Test).
4. Release.

Dies muss im Ernstfall rasend schnell gehen. Ohne automatisierte CI/CD-Pipelines und Testautomatisierung auf der rechten Seite des V-Modells ist die 24-Stunden-Frist technisch nicht haltbar.

Ein sauberes V-Modell (VDI 2206), inhaltlich gefüllt mit den Qualitätskriterien der ISO 25010 und den technischen Standards der IEC 62443, ist der sicherste Weg zur Compliance. Wer seine Entwicklungsprozesse so strukturiert, macht Sicherheit vom Zufallsprodukt zum reproduzierbaren Ergebnis.