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

Das Problem: Dokumentation driftet, der Code zieht weiter

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 schreiben Sie einmal. Den Nachweis müssen Sie fortlaufend erbringen, Release für Release, während sich der Code darunter verändert.

In den meisten Teams wird die Dokumentation einmal nahe einem Release geschrieben und verrottet danach. Ein halbes Jahr später hat sich die Architektur verschoben, Abhängigkeiten haben sich geändert, und das Sicherheitsdesign-Dokument beschreibt ein Produkt, das es nicht mehr gibt. Ein Auditor muss nicht feindselig sein, um diese Lücke zu finden — sie ist das Erste, was eine sorgfältige Prüfung zutage fördert. Die übliche Reaktion ist, vor jedem Audit manuellen Aufwand in die Neudokumentation zu stecken. Das ist teuer, zermürbend und liefert dennoch nur eine Momentaufnahme, die beim nächsten Sprint bereits veraltet ist.

Schritt eins: die Norm in eine maschinenlesbare Policy überführen

Der Ausgangspunkt ist, die IEC 62443-4-1 von einem PDF, das Sie in Meetings auslegen, in eine strukturierte SDLC-Policy in einem Format zu überführen, das Menschen und Modelle nativ lesen — Markdown. Jede der acht Praktiken der Norm wird 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 ist Ihre Auslegung der Norm, festgehalten als schlichter, versionierter Text.

Markdown ist keine ästhetische Wahl. Klartext ist diff-fähig, sodass jede Änderung an der Policy in einem Pull Request prüfbar ist. Sie liegt im Repository statt in einem Dokumentenmanagementsystem, das niemand öffnet. Und große Sprachmodelle lesen sie ohne jeden Konvertierungsschritt, was für alles Weitere entscheidend ist. Das ist „Policy as Code“ im wörtlichen Sinn: Die Compliance-Absicht liegt in derselben Versionsverwaltung wie die Software, die sie regelt.

Schritt zwei: die Policy nahe an Code und Artefakten halten

Legen Sie die SDLC-Policy — und die daraus erzeugte Dokumentation — in dieselben Git- oder Azure-DevOps-Repositories wie das Produkt selbst. Der Punkt ist 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.

• 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 — GitHub-Actions- oder Azure-Pipelines-Definitionen, die selbst 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.

Schritt drei: den menschlichen Kontext vorbereiten, bevor die KI schreibt

Diesen Schritt überspringen Teams, und er entscheidet, ob das Ergebnis vertrauenswürdig ist. Bevor irgendetwas erzeugt wird, bereiten Menschen 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 einem Auditor ist beides wichtig.

Prüfer legen außerdem vorab fest, wie „gute“ Dokumentation für jede Praktik aussieht — welche Fragen sie beantworten und welche Nachweise sie anführen muss. Gegen diese Vorgabe erzeugt die KI, und an ihr prüft ein Mensch das Ergebnis hinterher. Die Erzeugung ist automatisiert; das Urteil nicht.

Schritt vier: die Dokumentation erzeugen und von CI aktuell halten lassen

Liegen Policy, Kontext und Artefakte im Repository, kann die KI für jedes Produkt eine SDLC-Dokumentation erzeugen, die am tatsächlichen Code ausgerichtet ist — weil sie aus dem tatsächlichen Code abgeleitet wird. Das Ergebnis beschreibt das Produkt, wie es jetzt ist, nicht wie es beim letzten manuellen Schreiben war.

Der eigentliche Gewinn entsteht, wenn Sie das in der Pipeline automatisieren. Ein GitHub-Actions-Workflow — oder die entsprechende Azure-Pipeline — kann die betroffene Dokumentation bei jeder Codeänderung neu erzeugen oder aktualisieren, sodass die Dokumente im Gleichschritt mit der Software laufen, statt hinterherzuhinken.

• Bei jedem Pull Request die Dokumentation für die geänderten 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.

Über die Dokumentation hinaus: KI, die nach der Policy handelt

Sobald die SDLC-Dokumentation als strukturierter, aktueller Text neben dem Code liegt, wird sie zu mehr als einer Lesequelle. Die KI kann Policy und erzeugte Dokumentation zusammen nutzen, um die beschriebene Arbeit auch zu tun: eine Sicherheitsanforderung umsetzen, die die Policy verlangt, der Code aber vermissen lässt; die Behebung eines Befunds im Bedrohungsmodell entwerfen; oder eine Korrektur für eine von der Pipeline markierte Lücke vorschlagen. Die Dokumentation ist dann kein totes, für Auditoren abgelegtes Artefakt mehr, sondern eine operative Quelle, auf der der Entwicklungsprozess tatsächlich läuft.

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

Warum das die Anforderungen von CRA und IEC 62443-4-1 erfüllt

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. Beide laufen auf die Frage hinaus, die sich am schwersten vortäuschen lässt: Beweisen Sie, dass Ihre Dokumentation abbildet, was Sie tatsächlich gebaut haben und heute ausliefern.

Die Dokumentation unter CI aus dem Repository zu erzeugen, macht diesen Beweis zum Nebenprodukt der Entwicklung statt zu einem eigenen Projekt:

• 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 Git-Historie 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.

Das Fazit

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