Ihr IEC-62443-4-1-SDLC ist erst Compliance, wenn Ihre Entwickler ihn leben

Die Frage hinter der Frage

Ich verstehe, woher die Frage kommt. KI ist Teil der Arbeit von Produktteams geworden, und sie ist wirklich gut darin, schnell strukturierten Text zu erzeugen. Bitten Sie sie um einen sicheren Entwicklungszyklus, und Sie bekommen etwas, das richtig aussieht: acht Praktiken, Rollen, Verfahren, Vorlagen. Für ein Team, das vor dem Cyber Resilience Act steht, sieht das aus wie die Ziellinie.

Aber ein SDLC ist keine Compliance. Er beschreibt Arbeit, die Release für Release geschehen muss, in den Händen von Menschen, die nicht im Raum waren, als er geschrieben wurde. Die IEC 62443-4-1 verlangt einen definierten Prozess und den Nachweis, dass er für jedes Produkt befolgt wurde. Die erste Hälfte passt in ein Dokument. Die zweite existiert nur, wenn die Entwicklungsteams den Prozess tatsächlich leben. Das erzeugt kein Generator für Sie.

Die erste Überraschung: Die Norm dürfen Sie der KI nicht geben

Der zweite Teil des Gesprächs überraschte noch mehr. Der Plan war, die IEC 62443-4-1 in ein KI-Werkzeug hochzuladen und den Lebenszyklus aus dem Originaltext bauen zu lassen. Die Lizenzbedingungen des IEC Webstore erlauben das nicht: IEC-Publikationen dürfen ohne ausdrückliche Genehmigung der IEC nicht in KI-Werkzeuge eingebracht werden, weder in öffentliche noch in privat lizenzierte. Die Norm hochzuladen ist keine clevere Abkürzung. Es verstößt gegen die Lizenz, unter der Sie sie gekauft haben.

Damit arbeitet die KI mit allgemeinem Wissen über die Norm statt mit dem Text selbst, und das Ergebnis liest sich überzeugend, während genau das Detail fehlt, das ein Assessor prüft. Jemand, der die Anforderungen kennt, muss die Norm trotzdem lesen, entscheiden, was jede Praxis für diese Organisation und diese Produkte bedeutet, und diese Auslegung festhalten. KI kann helfen, diese Auslegung zu entwerfen und zu strukturieren. Die Person, die dafür verantwortlich ist, ersetzt sie nicht.

Den Lebenszyklus zu schreiben war immer der kleine Teil

Selbst sorgfältig gemacht ist der Aufbau des SDLC mühsame Arbeit. Aber in jedem Zertifizierungsprojekt, an dem ich beteiligt war, war er der kleinere Teil des Aufwands. Der größere begann an dem Tag, an dem das Dokument freigegeben war und zur Art werden musste, wie Menschen tatsächlich arbeiten.

Stellen Sie sich den Entwickler am anderen Ende vor. Sein Backlog ist voll, sein Release-Termin steht fest, und Sicherheit war bisher etwas, worum sich die Plattform oder ein anderes Team gekümmert hat. Jetzt erhält er hundert Seiten über Bedrohungsmodelle, Sicherheitsanforderungen, Coding-Regeln, Verifikationsaktivitäten und Freigabe-Gates. Er wird sie nicht lesen. Nicht aus Nachlässigkeit, sondern weil in seiner Woche kein Platz dafür ist. Ein Lebenszyklus, der als Dokument übergeben wird, bleibt ein Dokument.

Was eine echte Übergabe umfasst

Die Teams, die ich erfolgreich gesehen habe, behandelten die Übergabe als eigenes Projekt, mit eigenen Schritten und einem eigenen Verantwortlichen:

• Managementteil und Entwicklungsteil trennen. Governance, Verantwortlichkeiten, Anforderungen an Zulieferer und Prozessreviews gehören zum Management. Entwickler brauchen eine kurze, praktische Fassung: was bei einem Feature, einem Pull Request und einem Release zu tun ist. Allen das vollständige Dokument zu geben, hilft keiner der beiden Gruppen.
• Die richtigen Menschen finden. Jede Aktivität braucht einen benannten Verantwortlichen mit echtem Interesse an Sicherheit, nicht eine Zeile im Organigramm. Warum das alles entscheidet, habe ich in Sichere Entwicklung gelingt, wenn Interesse auf Expertise trifft beschrieben.
• Die Expertise aufbauen, bevor die Arbeit beginnt. Bewerten Sie, was die Verantwortlichen wissen, gemessen an dem, was ihre Rolle verlangt, und schulen Sie dort, wo es eine Lücke gibt. Die IEC 62443-4-1 verlangt genau das (SM-2 und SM-4), und es ist der Schritt, der aus einer zugewiesenen Aufgabe eine gelebte macht.
• Den Prozess dorthin bringen, wo die Arbeit schon stattfindet. Definition of Done, Pull-Request-Vorlagen, CI-Prüfungen und Freigabe-Gates tragen den Lebenszyklus weit besser in die tägliche Arbeit als ein Dokumentenportal.
• Klein anfangen und es beweisen. Lassen Sie den vollständigen Lebenszyklus zuerst an einem Produkt und einem Release laufen, korrigieren Sie, was nicht passt, und rollen Sie ihn dann aus. Beim ersten Release zeigt sich, ob die Übergabe wirklich funktioniert hat.

Dann beginnt die eigentliche Arbeit, und das geht verloren

Erst wenn Menschen, Expertise und Werkzeuge bereitstehen, kann der Lebenszyklus tatsächlich laufen. Und dort beginnt eine lange Liste von Pflichten, von denen jede leicht verloren geht, wenn ein ausgelastetes Team mit dem Dokument allein gelassen wird:

• Secure by Design — Bedrohungsmodellierung, die stattfindet, bevor das Design feststeht, nicht nachträglich für die Akte rekonstruiert.
• Sicherheitsanforderungen — Anforderungen, die abgeleitet, geprüft und bis zu den Tests nachverfolgbar sind, nicht aus einer Vorlage kopiert.
• Sichere Implementierung — Coding-Regeln, Reviews und statische Analyse, die tatsächlich durchgesetzt werden.
• Sicherheitsverifikation und -validierung — Anforderungstests, Tests der Bedrohungsminderung, Schwachstellen- und Penetrationstests, mit der Unabhängigkeit, die die Norm verlangt.
• Umgang mit Schwachstellen und Offenlegung — Eingang, Triage und koordinierte Offenlegung, und nach dem CRA seit dem 11. September 2026 die Meldung aktiv ausgenutzter Schwachstellen.
• SBOMs und Sicherheitsupdates — ein aktuell gehaltenes Komponentenverzeichnis und Updates, die über den gesamten Unterstützungszeitraum sicher ausgeliefert werden.
• Sicherheitshinweise für Nutzer — Anleitungen zu Härtung, sicherem Betrieb und Außerbetriebnahme, die zum ausgelieferten Produkt passen.

Jeder dieser Punkte hat eigene Nachweise, einen eigenen Verantwortlichen und eigene Arten, still zu scheitern. Keiner wird durch ein gut geschriebenes Lebenszyklus-Dokument gelöst. Alle werden durch Menschen gelöst, die verstehen, warum sie wichtig sind, und die Zeit und Unterstützung haben, sie umzusetzen.

Wo KI wirklich hilft

Nichts davon ist ein Argument gegen KI. Ich nutze sie und empfehle sie den Teams, mit denen ich arbeite. Sie ist hervorragend darin, Vorlagen und Arbeitsanweisungen aus Ihrer eigenen Auslegung zu entwerfen, einem Entwickler eine Anforderung in einfacher Sprache zu erklären, einen Pull Request gegen Ihre Policy zu prüfen und die Dokumentation am Code zu halten. Den letzten Teil habe ich ausführlich in KI schreibt Ihre IEC-62443-4-1-SDLC-Dokumentation beschrieben.

Dieser Ansatz beginnt mit einer Policy, die Ihre eigenen Leute geschrieben haben, und jede Änderung, die die KI vorschlägt, braucht weiterhin einen Engineer, der sie beurteilen kann, bevor sie gemergt wird. Genau für diesen Engineer ist die Übergabe da. KI macht einen gut übergebenen Lebenszyklus günstiger im Betrieb; die Übergabe ersetzt sie nicht. Was KI nicht tut: entscheiden, wie Ihr Prozess aussehen soll, ihn verantworten oder ein Entwicklungsteam dafür gewinnen. Das bleiben menschliche Aufgaben, und genau auf sie schaut ein Auditor am genauesten.

Was ich daraus mitnehme

Die Frage des Kunden war gut, und ich rechne damit, sie öfter zu hören. Meine Antwort hat sich nicht geändert: KI macht das Schreiben des Lebenszyklus schneller, und das ist willkommen. Aber Compliance mit IEC 62443-4-1 und dem CRA ist kein Dokument, das man erzeugt. Sie ist eine Arbeitsweise, die in Teams Wurzeln schlagen muss, die ohnehin zu viel zu tun haben. Sie dorthin zu bringen, mit den richtigen Menschen, der richtigen Expertise und den Praktiken in der täglichen Arbeit, ist der Teil, der entscheidet, ob der Lebenszyklus sein erstes Release überlebt.