IEC 62443-4-1: Sichere Softwareentwicklung für den Cyber Resilience Act

Normen und Standards haben oft den Ruf, trocken, bürokratisch und praxisfern zu sein - ein notwendiges Übel, das man erfüllt, aber selten liebt. In dieser Episode des Podcasts Software Testing & Qualität zeigt Host Richard Seidl zusammen mit seinem Gast Holger Sandlmann, dass es auch anders geht. Holger, ein erfahrener Prozessmanager bei der M&M Software GmbH, nimmt dich mit auf eine Reise, die zeigt, wie die Sicherheitsnorm IEC 62443-4-1 nicht nur als Leitfaden für den rechtlich immer relevanter werdenden EU Cyber Resilience Act dient, sondern auch zu einem Katalysator für bessere Prozesse, klarere Kommunikation und ein geschärftes Bewusstsein für Qualität im gesamten Team werden kann. Die zentrale Frage dabei: Wie verwandelt man eine formale Anforderung in einen gelebten und geschätzten Teil der Unternehmenskultur?

Das Wichtigste auf einen Blick

• Die Norm als praktischer Werkzeugkasten: Die Prozessnorm IEC 62443-4-1 ist kein starres Regelwerk, sondern ein nützliches Hilfsmittel, um die Anforderungen des EU Cyber Resilience Act (CRA) systematisch zu erfüllen. Sie liefert die Struktur, um sichere Entwicklungsprozesse nachweisbar zu gestalten.
• Startpunkt Gap-Analyse: Eine erfolgreiche Einführung beginnt nicht bei null. Holger rät, den bestehenden Prozess zu analysieren und ihn mit den Anforderungen der Norm abzugleichen. So wird der tatsächliche Anpassungsbedarf klar und man baut auf dem auf, was bereits gut funktioniert.
• Wissen gezielt aufbauen: Statt auf abstrakte Zertifizierungen zu setzen, schuf Holgers Team eine interne Wissensdatenbank. Für jede einzelne Sicherheitsanforderung wurden konkrete Testideen, Bedingungen und Beispiele entwickelt - eine unschätzbare, praxisnahe Ressource für alle Teammitglieder.
• Unabhängigkeit organisieren: Die Norm fordert unabhängige Tester. Dies lässt sich auch in kleineren Unternehmen durch clevere Strukturen wie Kompetenzzentren lösen, die als neutrale Instanz bei Meinungsverschiedenheiten zwischen Entwicklung und Qualitätssicherung fungieren können.
• Kollaboration wiederbeleben: Die Einführung war der perfekte Anlass, um bewährte, aber in Vergessenheit geratene Praktiken wie das Test Collaboration Meeting zu reaktivieren. Dieser frühe Austausch zwischen Entwicklern und Testern zu jedem Product Backlog Item (PBI) verkörpert den Shift-Left-Gedanken und verhindert teure Missverständnisse.

Die Norm 62443-4-1 als Werkzeugkasten für den Cyber Resilience Act

Der Cyber Resilience Act (CRA) der EU ist seit Ende 2024 in Kraft und wird ab 2027 für Hersteller digitaler Produkte vollständig verpflichtend. Er fordert nachweisbare Cybersicherheit über den gesamten Lebenszyklus eines Produkts. Dazu gehören, wie Holger erklärt, sichere Standardkonfigurationen, ein transparentes Schwachstellen-Management, eine umfassende Dokumentation und die Erstellung einer Software-Stückliste (SBOM). Für viele Unternehmen stellt sich die Frage, wie sie diese rechtlichen Vorgaben konkret umsetzen können.

Hier kommt die Normenreihe IEC 62443 ins Spiel, die ursprünglich aus dem industriellen Automatisierungsumfeld stammt. Holger beschreibt sie als einen idealen Werkzeugkasten. Insbesondere der Teil 62443-4-1 definiert einen Prozess für die sichere Softwareentwicklung (Secure Development Lifecycle), während der Teil 62443-4-2 einen umfangreichen Katalog an technischen Sicherheitsanforderungen für Produkte enthält. Gemeinsam bieten sie einen praxiserprobten Pfad, um die Prozessanforderungen des CRA zu erfüllen. Ein zentrales Konzept der Norm sind die Security Level (SL), die von SL1 (Schutz gegen unbeabsichtigte Fehler) bis SL4 (Schutz gegen Angriffe von Geheimdiensten) reichen und dabei helfen, den Schutzbedarf eines Produkts realistisch einzuschätzen.

Der Startschuss: Gap-Analyse und schrittweise Prozessanpassung

Wie fängt man ein solches Projekt an? Holger berichtet, dass der erste Schritt bei M&M Software darin bestand, eine verantwortliche Person zu benennen und eine detaillierte Gap-Analyse durchzuführen. Anstatt einen komplett neuen Prozess aufzusetzen, wurde der bestehende, agile Scrum-Prozess als Grundlage genommen und gezielt erweitert. Die Sicherheit, die zuvor als implizites Qualitätsattribut behandelt wurde, erhielt nun eine explizite Rolle.

Zu den wichtigsten Anpassungen gehörte die Einführung einer lückenlosen Rückverfolgbarkeit (Traceability): Security-Anforderungen werden nun explizit gekennzeichnet und mit den Features, Code-Änderungen und Testfällen verknüpft, die sie umsetzen. Dadurch ist jederzeit nachvollziehbar, wie und wo eine Sicherheitsvorgabe realisiert und geprüft wurde. Auch Review-Prozesse, etwa bei Pull Requests, wurden formalisiert und in der Definition of Done verankert. Diese schrittweise Anpassung sorgte dafür, dass das Team nicht überfordert wurde und die neuen Praktiken organisch in die gewohnten Abläufe integriert werden konnten.

Mehr als nur Schulung: Gezieltes Training und Wissensmanagement

Ein entscheidender Erfolgsfaktor war der durchdachte Trainingsansatz. Zunächst wurden rollenspezifische Prozess-Schulungen für Product Owner, Entwickler und Qualitätsingenieure durchgeführt. Holger betont, dass dies eine willkommene Gelegenheit war, das Wissen über den gesamten, über Jahre gewachsenen Prozess aufzufrischen und das Bewusstsein für die Zusammenhänge zu schärfen. Plötzlich war allen wieder klar, warum bestimmte Schritte existieren.

Für die fachlichen Security-Trainings wählte das Team einen besonders cleveren Weg. Anstatt alle Mitarbeiter durch teure und sehr abstrakte Zertifizierungsprogramme zu schicken, schufen sie eine eigene, praxisorientierte Wissensbasis. Für jede einzelne Sicherheitsanforderung aus der Norm bauten sie im Wiki einen Fundus an konkreten Hilfestellungen auf: Was ist die Kernaussage der Anforderung? Wie könnte ein Feature aussehen, das sie umsetzt? Was sind typische Testziele und Testbedingungen? Welche Beispiel-Testfälle gibt es? Diese Sammlung dient nun als ständig verfügbare Referenz, die neuen und erfahrenen Teammitgliedern hilft, Security-Anforderungen schnell zu verstehen und systematisch zu testen.

Zusammenarbeit im Fokus: Unabhängigkeit und Test-Kollaboration

Eine zentrale, aber organisatorisch anspruchsvolle Forderung der Norm ist die Independence of Testers. Ein Tester sollte nicht derselben Person berichten wie der Entwickler, dessen Arbeit er prüft, um Interessenkonflikte zu vermeiden. Holgers Firma löste dies durch eine Matrix-Struktur mit drei Säulen: Mitarbeiter, Projekte und Kompetenzzentren. Das Kompetenzzentrum Quality Engineering dient dabei als fachliche Heimat für alle Qualitätsingenieure und kann als unabhängiges Schiedsgericht fungieren, falls es zu fachlichen Meinungsverschiedenheiten kommt.

Noch wichtiger für die tägliche Arbeit war laut Holger die Wiederbelebung des Test Collaboration Meetings. In diesem Format setzen sich die zuständigen Entwickler und ein Qualitätsingenieur zusammen, bevor die Implementierung eines Product Backlog Items (PBI) beginnt. Gemeinsam besprechen sie das PBI, klären offene Fragen und legen eine Teststrategie fest. Ein Kollege, so Holger, beschrieb dies treffend als kleines Wasserfallmodell für jedes PBI. Auf diese Weise wird sichergestellt, dass alle das gleiche Verständnis haben, Tests auf der effizientesten Ebene geplant werden (z. B. viele Permutationen in Unit-Tests statt in langsamen UI-Tests) und es am Ende im Pull-Request keine bösen Überraschungen mehr gibt. Es ist gelebter Shift Left.

Praktische Schritte zur Einführung eines Security-Prozesses

Wenn du vor einer ähnlichen Aufgabe stehst, können dir die Erfahrungen von Holger Sandlmann als wertvolle Blaupause dienen. Hier sind die wichtigsten Schritte zusammengefasst:

1. Verantwortung klären: Benenne eine Person oder ein kleines Team, das den Prozess treibt und als zentraler Ansprechpartner fungiert.
2. Gap-Analyse durchführen: Analysiere deinen bestehenden Entwicklungsprozess und vergleiche ihn systematisch mit den Anforderungen der Norm (z.B. IEC 62443-4-1). So identifizierst du die wirklichen Lücken.
3. Prozess anpassen, nicht neu erfinden: Integriere die neuen Anforderungen - wie die explizite Kennzeichnung von Security-Artefakten oder formale Reviews - in deine bestehenden agilen Abläufe.
4. Gezielte Trainings entwickeln: Führe allgemeine Prozess-Schulungen durch, um alle auf den gleichen Stand zu bringen. Ergänze diese durch praxisnahe Security-Trainings, die sich direkt auf die umzusetzenden Anforderungen beziehen, beispielsweise durch ein internes Wiki mit Test-Mustern.
5. Kollaboration institutionalisieren: Etabliere Formate wie das Test Collaboration Meeting, um die Zusammenarbeit zwischen Entwicklung und Qualitätssicherung frühzeitig zu fördern und ein gemeinsames Verständnis für jedes Feature zu schaffen.
6. Unabhängigkeit sicherstellen: Schaffe organisatorische Strukturen, zum Beispiel durch Kompetenzzentren, um die geforderte Unabhängigkeit von Testern zu gewährleisten.
7. Kontinuierlich verbessern: Nutze interne Audits nicht als Kontrollinstrument, sondern als Feedback-Schleife. So bleibt der Prozess lebendig und passt sich an die realen Herausforderungen der Teams an.