KI schreibt Ihre IEC-62443-4-1-SDLC-Dokumentation — und hält sie am Code

Was ich immer wieder sah: Dokumentation driftet, der Code zieht weiter

Was mir Team um Team auffiel: Die IEC 62443-4-1 verlangt zwei Dinge, die in entgegengesetzte Richtungen ziehen: einen definierten Prozess und den Nachweis, dass der Prozess für jedes Produkt tatsächlich befolgt wurde. Den Prozess schreibt man einmal. Den Nachweis muss man fortlaufend erbringen, Release für Release, während sich der Code darunter verschiebt. Ich sah viele Teams das Erste meistern und das Zweite still verlieren.

Das Muster war fast immer dasselbe. Jemand schrieb die Dokumentation nahe einem Release, und danach verrottete sie. Ein halbes Jahr später hatte sich die Architektur verschoben, Abhängigkeiten hatten sich geändert, und das Sicherheitsdesign-Dokument beschrieb ein Produkt, das es nicht mehr gab. Ich brauchte nie einen feindseligen Auditor, um diese Lücke zu finden — sie war das Erste, was jede sorgfältige Prüfung zutage förderte. Und die übliche Reaktion, vor jedem Audit manuellen Aufwand in die Neudokumentation zu stecken, lieferte stets nur eine Momentaufnahme, die beim nächsten Sprint schon wieder veraltet war. Das war teuer, es zermürbte die Leute, und es behob das Problem nie wirklich.

Wo es begann: die eigene Policy in maschinenlesbarer Form schreiben

Die Teams, die das richtig machten, begannen alle an derselben Stelle. Statt die IEC 62443-4-1 als PDF in Meetings auszulegen, schrieben sie eine eigene, strukturierte SDLC-Policy in einem Format, das Menschen und Modelle nativ lesen — Markdown. Jede der acht Praktiken der Norm wurde zu einer expliziten Menge von Erwartungen: wie eine Sicherheitsanforderung hier aussieht, was der Schritt zur Bedrohungsmodellierung abdecken muss, was ein Freigabe-Gate prüfen muss, wie mit Sicherheitsproblemen und Updates umgegangen wird. Es war ihre Auslegung der Norm, festgehalten als schlichter, versionierter Text. Die Policy beschreibt die eigenen Entwicklungsprozesse der Organisation in eigenen Worten. Inhalte aus IEC-Publikationen dürfen KI-Werkzeugen nur mit der nach den geltenden IEC-Lizenzbedingungen erforderlichen Genehmigung bereitgestellt werden.

Ich hielt das Format früher für ein Detail. Ist es nicht. Klartext ist diff-fähig, sodass jede Änderung an der Policy genauso prüfbar ist wie eine Codeänderung. Sie liegt im Repository statt in einem Dokumentenmanagementsystem, das niemand öffnet. Und Modelle lesen sie ohne jeden Konvertierungsschritt, was sich für alles Weitere als entscheidend erweist. Das ist „Policy as Code“ im wörtlichen Sinn: Die Compliance-Absicht liegt in derselben Versionsverwaltung wie die Software, die sie regelt.

Was es zum Laufen brachte: die Policy nahe an Code und Artefakten

Die Teams, bei denen das hielt, legten die SDLC-Policy — und die daraus erzeugte Dokumentation — in dieselbe Versionsverwaltung wie das Produkt selbst. Was sich auszahlte, war die Nähe: Wenn Policy, Quellcode, Build-Artefakte und SBOM an einem Ort liegen, können sowohl die KI als auch ein menschlicher Prüfer sie zusammen sehen und als ein System begreifen, statt Nachweise über fünf Werkzeuge hinweg zusammenzusuchen.

• Die Policy — Ihre Auslegung der IEC 62443-4-1 als Markdown, versioniert wie jede andere Quelldatei.
• Der Produktquellcode — der Code, den die Dokumentation beschreiben soll.
• Die Build- und CI-Konfiguration — die Pipeline-Definitionen selbst, die bereits ein Nachweis des Prozesses sind.
• Die Artefakte — SBOM, Ergebnisse von Abhängigkeits- und Code-Scans, Testergebnisse.
• Die erzeugte SDLC-Dokumentation — das Ergebnis, direkt neben den Eingaben, aus denen es abgeleitet wurde.

Der Schritt, den Teams übersprangen: den menschlichen Kontext zuerst

Diesen Schritt sah ich Menschen überspringen, und er entschied, ob ich dem Ergebnis traute. Bevor irgendetwas erzeugt wurde, bereiteten die guten Teams den Kontext vor, den der Code allein nicht liefern kann: den Produktumfang und seine Grenzen, die Annahmen des Bedrohungsmodells, die Architekturentscheidungen und ihre Gründe, die bewusst akzeptierten Risiken. Der Code zeigt, was gebaut wurde; nur Menschen können festhalten, warum — und meiner Erfahrung nach ist einem Auditor beides wichtig, oft das Warum mehr.

Sie legten außerdem vorab fest, wie „gute“ Dokumentation für jede Praktik aussah — welche Fragen sie beantworten und welche Nachweise sie anführen musste. Gegen diese Vorgabe erzeugte die KI, und an ihr prüfte ein Mensch das Ergebnis hinterher. Die Erzeugung war automatisiert; das Urteil nie. Wo ich Teams diese Linie verwischen sah, ging das Vertrauen mit.

Wo der Drift endlich aufhörte: CI hält es aktuell

Lagen Policy, Kontext und Artefakte im Repository, sah ich die KI für jedes Produkt eine SDLC-Dokumentation erzeugen, die tatsächlich am Code ausgerichtet war — weil sie aus dem Code abgeleitet wurde. Zum ersten Mal beschrieb die Dokumentation das Produkt so, wie es an jenem Tag war, nicht wie es beim letzten manuellen Schreiben gewesen war.

Doch die eigentliche Wende kam, als Teams das in ihrer Pipeline automatisierten. Welches CI-System sie auch nutzten — ein Workflow kann die betroffene Dokumentation bei jeder Codeänderung neu erzeugen oder aktualisieren, sodass die Dokumente im Gleichschritt mit der Software laufen, statt hinterherzuhinken. Das war der Moment, in dem „aktuell halten“ aufhörte, ein Versprechen vor dem Audit zu sein, und einfach bei jedem Merge geschah.

• Bei jeder Änderung die Dokumentation für die bewegten Teile des Produkts neu erzeugen.
• Das Ergebnis gegen die Policy abgleichen und markieren, was eine Praktik nicht mehr erfüllt.
• Die Lücken als Review-Kommentare sichtbar machen, sodass sie beim Merge auffallen, nicht erst beim Audit.
• Eine menschliche Freigabe verlangen, bevor die aktualisierte Dokumentation committet wird.
• Die gesamte Historie — jede Erzeugung an einen Commit gebunden — als zeitgestempelte Nachweiskette bewahren.

Was mich überraschte: KI, die nach der Policy handelt

Womit ich nicht gerechnet hatte, war, wie sich die Dokumentation veränderte, sobald sie als strukturierter, aktueller Text neben dem Code lag. Sie war nicht mehr nur etwas zum Lesen. Die Teams, die am weitesten waren, nutzten Policy und erzeugte Dokumentation zusammen, um die beschriebene Arbeit auch zu tun: eine Sicherheitsanforderung umzusetzen, die die Policy verlangte, der Code aber vermissen ließ; die Behebung eines Befunds im Bedrohungsmodell zu entwerfen; eine Korrektur für eine von der Pipeline markierte Lücke vorzuschlagen. Die Dokumentation war kein totes, für Auditoren abgelegtes Artefakt mehr, sondern etwas, worauf der Entwicklungsprozess tatsächlich lief.

Dieselbe Disziplin gilt hier, nur strenger — und genau hier habe ich Menschen auf die Nase fallen sehen. Sicherheitsrelevante Änderungen sind die Stelle, an der eine ungeprüfte KI-Änderung den größten Schaden anrichtet; das menschliche Gate ist nicht verhandelbar: Die KI schlägt die Anforderung oder die Behebung vor, und ein Entwickler verantwortet die Entscheidung, sie zu übernehmen. So genutzt, sah ich die Schleife sich schließen — die Policy treibt die Dokumentation, die Dokumentation treibt die Korrekturen, und die Korrekturen werden in denselben Nachweis zurückgeführt.

Warum das aus meiner Sicht Nachweise für CRA und IEC 62443-4-1 unterstützt

Die IEC 62443-4-1 will einen definierten Prozess und den produktbezogenen Nachweis, dass er befolgt wurde. Der CRA will in Anhang I Sicherheitsprozesse, die über den Unterstützungszeitraum dokumentiert und gepflegt sind, sowie eine technische Dokumentation, die aktuell bleibt. Am Ende laufen beide auf die Frage hinaus, die sich am schwersten vortäuschen lässt — und die ich die meisten Audits versenken sah: Beweisen Sie, dass Ihre Dokumentation abbildet, was Sie tatsächlich gebaut haben und heute ausliefern.

Die Dokumentation unter CI aus dem Repository zu erzeugen, ist der einzige Ansatz, den ich diesen Beweis zum Nebenprodukt der Entwicklung statt zu einem eigenen Projekt machen sah:

• Definierter Prozess — die Policy as Code ist die Definition, versioniert und prüfbar.
• Produktbezogener Nachweis — die erzeugte Dokumentation liegt im jeweils eigenen Repository des Produkts.
• Aktuell gehalten — CI erzeugt bei Änderungen neu, sodass „gepflegt“ automatisch geschieht, nicht als Versprechen.
• Nachvollziehbar — die Versionshistorie bindet jede Version der Dokumentation an den Commit, den sie beschreibt.
• Menschliche Verantwortung — das Review-Gate hält fest, wer was freigegeben hat; genau danach fragt ein Auditor am Ende.

Was ich daraus mitnehme

Der typische Fehlermodus der SDLC-Dokumentation ist Drift: Sie stimmt am Tag, an dem sie geschrieben wird, und hört langsam auf zu stimmen. Alles, was ich funktionieren sah, dreht das um — Dokumentation, die aus dem Code abgeleitet, von Menschen geprüft und automatisch aktuell gehalten wird. Was mir geblieben ist: Das ist nicht nur weniger Arbeit zur Audit-Zeit. Es ist der bessere Nachweis, weil er nie veralten durfte.