Sichere Softwareentwicklung nach ISO 27001 (A.8.28), wenn KI-Agenten programmieren: Worauf der Auditor schaut

Was verlangt ISO 27001 A.8.28 konkret?

Maßnahme 8.28 von ISO/IEC 27001:2022, Secure coding, verlangt, dass eine Organisation Grundsätze der sicheren Programmierung auf ihre Softwareentwicklung anwendet. Sie kam mit der Ausgabe 2022 hinzu. Ihre Anleitung in ISO/IEC 27002:2022 kennt drei Phasen, Planung vor dem Programmieren, das Programmieren selbst sowie Prüfung und Wartung, und erfasst neben eigenem Code auch Komponenten von Dritten und aus Open Source.

Die Zertifizierungsstelle DQS hat die neue Maßnahme im Januar 2023 vorgestellt, in einem Beitrag ihres Auditors Markus Jegelka: Das Rahmenwerk „is to be applied holistically both to the company's own program code and to software from third parties and open source sources“, gilt also ganzheitlich für eigenen Programmcode ebenso wie für Software von Dritten und aus Open-Source-Quellen. Ein Auditor arbeitet heute nur noch mit der Ausgabe 2022. Die Übergangsfrist von der Vorgängerausgabe endete am 31. Oktober 2025, und Zertifikate nach der alten Fassung sind an diesem Tag abgelaufen, wie die irische Zertifizierungsstelle NSAI festhält, mit Verweis auf das verbindliche IAF-Dokument MD 26.

Ein Auditor liest 8.28 zusammen mit den Entwicklungsmaßnahmen, die sie umgeben, und jede davon wird zu einer einfachen Frage, sobald Agenten den Code schreiben:

Die Titel stehen hier in der englischen Fassung von Anhang A aus dem Jahr 2022; deutsche Umschreibungen in diesem Text sind sinngemäß und keine offiziellen Normtitel. ISO verkauft die Texte seiner Normen, deshalb stammen die Formulierungen, die dieser Leitfaden zitiert, von Zertifizierungsstellen und Beratungen, die sie wiedergeben.

Regelt ISO 27001 den Einsatz von KI-Coding-Agenten?

ISO 27001 regelt KI-Coding-Agenten nicht. Die Ausgabe 2022 stammt vom Oktober 2022, hat laut dem Katalog von ISO seitdem eine Änderung erhalten, und keine Maßnahme aus Anhang A befasst sich mit KI. Code, den ein Agent in Ihrem Repository unter einem Konto schreibt, das Sie ihm gegeben haben, ist Ihr Code, und für ihn gelten dieselben Entwicklungsmaßnahmen.

Wer eine eigene KI-Klausel erwartet, ist von dieser Antwort enttäuscht, dabei ist sie die nützlichere. Die Anleitung zu 8.28 verlangt bereits, unsichere Praktiken aus dem Code herauszuhalten, darunter hartcodierte Passwörter und nicht freigegebene Codebeispiele, so fasst ISMS.online ISO 27002 zusammen. Ein Agent, der ein Muster von anderswo im Repository oder aus seinem Training übernimmt, produziert genau das, ein nicht freigegebenes Codebeispiel, und zwar schneller, als ein Reviewer es Zeile für Zeile lesen kann. Die Maßnahme wurde für Code aus jeder Quelle geschrieben, und Agenten sind eine Quelle mehr.

Zwei weitere Fragen kommen auf, sobald ein Team Agenten einsetzt, und beide liegen außerhalb von 8.28. Was schickt der Agent an seinen Modellanbieter, und ist dieser Anbieter als Lieferant bewertet? Unsere Leitfäden dazu, was Claude Code an Anthropic sendet und was Cursor speichert, beantworten die erste Frage für das jeweilige Werkzeug. Und falls jemand fragt, ob Sie ISO/IEC 42001 brauchen: Das ist die Norm für KI-Managementsysteme, die ISO im Dezember 2023 veröffentlicht hat, für Organisationen „providing or utilizing AI-based products or services“, also für Anbieter und Nutzer KI-basierter Produkte und Dienste. Sie ist eine eigenständige Zertifizierung, und ISO 27001 verlangt sie nicht.

Welche Nachweise will der Auditor sehen, wenn KI-Agenten programmieren?

Der Auditor verlangt drei Arten von Nachweisen: Dokumente, die beschreiben, wie Sie sicher entwickeln, Konfiguration, die zeigt, dass Ihre Prüfungen erzwungen werden, und Aufzeichnungen, dass sie bei den Änderungen des Auditzeitraums gelaufen sind. Mit Agenten müssen die Dokumente die Agenten benennen, und die Aufzeichnungen müssen jede gemergte Änderung abdecken, auch die, die kein Mensch geschrieben hat.

Die Beratung Advisera fasst den Prüfmaßstab für 8.28 auf ihrer Seite zur Maßnahme in einem Satz zusammen. Der Auditor prüft, „if principles for secure coding are integrated into the software lifecycle process“, ob also Grundsätze der sicheren Programmierung in den Lebenszyklus der Software eingebunden sind, und findet er sie nicht, gilt: „this is considered a nonconformity“, es ist eine Abweichung. Die Dokumente selbst „are not mandatory, but are recommended“, sind also keine Pflicht, aber empfohlen: eine Secure Development Policy für ein kleines oder mittleres Unternehmen, eine eigene Secure Coding Policy für ein größeres. In der Praxis stellt der Auditor eine Handvoll Fragen und zieht Stichproben aus den Änderungen, um die Antworten zu überprüfen:

Bei Tests ist eine eigene Warnung angebracht. Schreibt der Agent das Feature und die Tests dazu in derselben Sitzung, beweist ein grüner Testlauf nur, dass der Code tut, was der Agent verstanden hat. In der kontrollierten Studie von CybeDefend war mindestens ein Drittel der Regelabweichungen, die der Agent im Code hinterließ, durch seine eigenen, bestandenen Tests abgedeckt, die CI hätte sie also nie gemeldet. Erst ein Sicherheitstest, den nicht der Agent geschrieben hat, ein Scan oder eine Prüfung aus Ihrer CI, gibt 8.29 seinen Sinn.

Reicht eine CLAUDE.md oder AGENTS.md als Nachweis für sichere Programmierung?

Eine Regeldatei ist kein Nachweis: Sie ist eine Richtlinie, die der Agent zu Beginn einer Sitzung liest, und nichts darin hält fest, ob der Code ihr gefolgt ist. In der kontrollierten Studie von CybeDefend vom 24. August 2026 hinterließ ein realistischer Regelabschnitt pro Ticket so viele gebrochene Regeln wie gar keine Datei, 2,27 gegenüber 2,28.

Teams, die ein Audit mit Agenten vorbereiten, legen ihren Standard für sichere Programmierung oft in CLAUDE.md oder AGENTS.md ab, und als Ort, an dem der Agent ihn findet, ist das durchaus sinnvoll. Die Dokumentation von Anthropic zum Gedächtnis zieht selbst die Grenze: Claude behandelt diese Dateien „as context, not enforced configuration“, also als Kontext und nicht als erzwungene Konfiguration, und „there's no guarantee of strict compliance“, eine strikte Einhaltung ist nicht garantiert. Unsere Studie hat gemessen, was das bei echten Tickets bedeutet. Ein Agent, Claude Opus 5, bearbeitete 30 Entwicklertickets in drei Konfigurationen, insgesamt 90 Läufe, blind bewertet anhand versiegelter Bewertungsraster. Mit einem von Hand gepflegten Regelabschnitt setzte der Agent 7 von 55 Regeldetails exakt um, genauso viele wie ohne Datei. Mit dem vollständigen Regelkorpus, wortgleich in die Datei kopiert, kam er auf 7 von 11. Die Einzelheiten stehen in unserem Artikel darüber, ob Claude Code die CLAUDE.md befolgt.

Für einen Auditor ist das der Unterschied zwischen der Ausgestaltung einer Kontrolle und ihrer Wirksamkeit im Betrieb. Die Datei zeigt, dass Sie den Standard aufgeschrieben und dem Agenten übergeben haben, und das hilft bei 8.25 und 8.28. Über den Code, der dabei herauskam, sagt sie nichts. In derselben Studie schnitt ein anderer Weg besser ab: jede Regel genau in dem Moment bereitzustellen, in dem der Agent die Zeile schreibt. Das ergab 0,28 gebrochene Regeln pro Ticket, und genau das macht VibeDefend. Selbst dann akzeptiert der Auditor als Nachweis die Prüfung, die auf der Änderung gelaufen ist, und die Aufzeichnung, die sie hinterlassen hat.

Wie lässt sich nachweisen, welchen Code ein KI-Agent geschrieben hat?

Ihre Git-Historie zeigt es, sofern Ihre Agenten dort eine Spur hinterlassen. Claude Code hängt standardmäßig an jeden Commit einen Co-Authored-By-Trailer an, der das Modell nennt, und eine einzige Einstellung entfernt ihn. Am 27. Oktober 2026 trugen 467 der 494 Commits auf dem Main-Branch unseres eigenen Website-Repositorys aus den vorangegangenen 90 Tagen diesen Trailer.

Gezählt haben wir sie mit zwei Befehlen auf diesem Repository:

git log origin/main --since=2026-07-29 --no-merges --format=%H | wc -l
git log origin/main --since=2026-07-29 --no-merges -i --grep="Co-Authored-By: Claude" --format=%H | wc -l

Die Trailer nennen über den Zeitraum fünf verschiedene Claude-Modelle, die Historie sagt also, welches Modell welche Änderung geschrieben hat, und die übrigen 27 Commits tragen gar keinen Trailer. Woher er kommt, erklärt die Referenz der Einstellungen: Standardmäßig fügt Claude Code Co-Authored-By: <name> <noreply@anthropic.com> hinzu, wobei der Name das gerade verwendete Modell ist, und wer attribution auf false setzt, blendet ihn aus. Eine Spur, die jeder Entwickler abschalten kann, ist eine Konvention. Wenn Sie sie in Ihren Nachweisen haben wollen, legen Sie sie in den Managed Settings fest, die Ihre Organisation verteilt, und prüfen Sie, was Ihre anderen Agenten in Commits und Pull Requests hinterlassen, denn jedes Werkzeug macht das anders.

Die Urheberschaft sagt dem Auditor, welche Änderungen er sich ansehen sollte, die eigentliche Kontrolle sind aber die Gates, die jede Änderung durchläuft. Unser Artikel über das Review der Pull Requests eines KI-Agenten erklärt, warum ein eigenes Maschinenkonto mit signierten Commits mehr taugt als ein Label, das ein Beitragender einfach weglassen kann.

Verlangt SOC 2 dasselbe wie ISO 27001?

SOC 2 verlangt über zwei Kriterien weitgehend dasselbe. CC8.1 fordert, dass Änderungen an Software autorisiert, entworfen, entwickelt, dokumentiert, getestet, freigegeben und umgesetzt werden. CC7.1 fordert Erkennung und Überwachung, die neue Schwachstellen aufdecken, und Schwachstellenscans gehören zu seinen Points of Focus. Ein Type-II-Bericht prüft dann, ob diese Kontrollen über einen Zeitraum funktioniert haben.

Die Trust Services Criteria des AICPA liegen auf dessen Website hinter einem Login, deshalb zitieren wir sie in der Fassung, die die Dokumentation von Wazuh wiedergibt. CC8.1: „The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.“ CC7.1: „To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.“ Unter den Points of Focus, die zu diesen Kriterien aufgeführt sind, nennt CC8.1 „Tests System Changes“ und „Approves System Changes“, CC7.1 nennt „Conducts Vulnerability Scans“. Änderungen werden also getestet und freigegeben, und nach Schwachstellen wird gescannt.

Der Unterschied zu ISO 27001 liegt in der Form des Ergebnisses. ISO zertifiziert ein Managementsystem, mit den Maßnahmen aus Anhang A, die Sie in Ihrer Erklärung zur Anwendbarkeit (Statement of Applicability) ausgewählt haben. SOC 2 ist ein Testat. Die Prüfungsgesellschaft TrustNet formuliert es so: „A licensed CPA gives an opinion on whether your controls are properly designed (Type I) and, if applicable, effectively operating over time (Type II)“. Ein zugelassener Wirtschaftsprüfer beurteilt also, ob Ihre Kontrollen richtig ausgestaltet sind, und beim Type II zusätzlich, ob sie über die Zeit wirksam waren. Mit Agenten bedeutet ein Type-II-Zeitraum Aufzeichnungen zu jeder Änderung über Monate hinweg, und der Auditor zieht seine Stichproben so, wie es ein ISO-Auditor tut. Ein Team, das für das eine bereit ist, ist für das andere fast bereit.

Was sollte vor dem Audit bereitliegen?

Bereitliegen sollten eine Richtlinie zur sicheren Entwicklung, die Ihre Agenten nennt, ein Standard für sichere Programmierung, ein Scan auf jeder Änderung hinter einem Gate, das kritische Befunde ablehnt, ein Ausnahmeregister mit Genehmigenden und Ablaufdaten, getestete und freigegebene Pull Requests sowie ein Bericht über den Auditzeitraum, alles aktuell an dem Tag, an dem der Auditor Stichproben zieht.

1. Die Richtlinie nennt die Agenten. Welche Agenten, welche Konten, welche Repositorys, und was der Agent nicht selbstständig tun darf, etwa mergen oder deployen.
2. Der Standard ist kurz und durchsetzbar. Er listet auf, was Sie verbieten, und verweist für jeden Punkt auf die Prüfung, die ihn findet. Eine Regel, die keine Prüfung finden kann, kann nur ein Reviewer durchsetzen.
3. Jede Änderung bekommt denselben Scan. Code, Abhängigkeiten, Secrets und Infrastrukturdateien, bei jedem Pull Request, egal ob ein Mensch oder ein Agent ihn geöffnet hat.
4. Das Gate entscheidet und protokolliert. Ein kritischer Befund blockiert den Merge; bei geringerem Risiko gibt es eine Warnung, und die Änderung geht raus. Jede Ausnahme ist eingegrenzt, datiert, begründet und namentlich genehmigt.
5. Freigabe und Tests bleiben bei der Änderung. Der Pull Request trägt die Freigabe, den CI-Lauf und das Ergebnis des Scans, sodass sich eine gezogene Änderung von selbst erklärt.
6. Der Bericht deckt den Zeitraum ab. Ein Dokument, das der Auditor lesen kann, erzeugt aus den Scans und nicht aus einer Tabellenkalkulation zusammenkopiert.

Ticket mit AnforderungenAgent schreibt die ÄnderungScan auf der ÄnderungGate blockiert oder warntFreigegeben und getestetIm Bericht

Die Punkte 3, 4 und 6 liefert die AppSec-Plattform von CybeDefend. Sie scannt in jedem Repository den Code auf Schwachstellen (SAST), dazu Abhängigkeiten (SCA), Secrets, Infrastructure as Code, Container und CI/CD-Pipelines. Eine als Code geschriebene Sicherheitsrichtlinie blockiert den Merge bei einem kritischen Befund und warnt bei geringerem Risiko, über die Organisation, ihre Teams und deren Projekte hinweg. Eine Ausnahme ist auf einen Pfad begrenzt, datiert, begründet und namentlich genehmigt, und jede hinterlässt eine Zeile im Audit-Log. Sicherheitsberichte ordnen die Befunde den OWASP Top 10 und den CWE Top 25 zu, nach Organisation, Team oder Projekt, exportiert als PDF für den Auditor, als HTML oder als JSON für ein GRC-Tool. Wenn Sie ISO 27001 oder SOC 2 mit einem Team vorbereiten, das mit Agenten entwickelt, gehen wir das gern gemeinsam mit Ihnen durch. Das größere Bild, was sich ändert, wenn Agenten Code schreiben, zeigt unser Leitfaden zur Sicherheit von KI-Coding-Agenten.

Häufige Fragen

Darf man unter ISO 27001 KI-Coding-Agenten einsetzen?

Ja. Nichts in ISO/IEC 27001:2022 verbietet sie, und keine Maßnahme aus Anhang A befasst sich mit KI. Code, den ein Agent in Ihrem Repository schreibt, ist Ihr Code, also gelten die Maßnahmen 8.25 bis 8.29 und 8.32 für ihn genauso wie für Code, den ein Entwickler getippt hat. Ihre Richtlinie muss festlegen, welche Agenten zugelassen sind und wie ihre Änderungen geprüft werden.

Kann ich A.8.28 in der Erklärung zur Anwendbarkeit ausschließen?

Für ein Unternehmen, das Software entwickelt, praktisch nicht. ISO 27001 erlaubt, eine Maßnahme aus Anhang A auszuschließen, aber Abschnitt 6.1.3 d) verlangt dafür eine Begründung in Ihrer Erklärung zur Anwendbarkeit, und sichere Programmierung auszuschließen, während Sie Code schreiben, lässt sich kaum verteidigen. Findet ein Auditor in Ihrem Entwicklungsprozess keine Grundsätze für sichere Programmierung, stellt er eine Abweichung fest.

Brauche ich für ISO 27001 eine Secure Coding Policy?

Vorgeschrieben ist sie nicht, erwartet wird sie in irgendeiner Form. Gemeint ist ein Dokument, das die Programmiergrundsätze festlegt, denen Ihre Entwickler und Agenten folgen, und beschreibt, wie Sie deren Einhaltung prüfen. Auditoren wollen diese Grundsätze schriftlich sehen: in einer Secure Development Policy bei kleinen und mittleren Unternehmen, in einer eigenen Secure Coding Policy bei größeren.

Reicht eine CLAUDE.md oder AGENTS.md für das ISO-27001-Audit?

Nein. Sie zeigt, dass Sie dem Agenten Ihren Standard gegeben haben, nicht, dass der Code ihn einhält. Anthropic schreibt, dass Claude diese Dateien als Kontext behandelt und nicht als erzwungene Konfiguration, und in der Studie von CybeDefend vom 24. August 2026 hinterließ eine realistische Regeldatei 2,27 gebrochene Regeln pro Ticket, ohne Datei waren es 2,28. Der Auditor will Aufzeichnungen über Prüfungen, die auf jeder Änderung gelaufen sind.

Muss jeder Pull Request eines KI-Agenten von einem Menschen reviewt werden?

Der Auditor erwartet, dass jede Änderung vor dem Release freigegeben wird: Die Freigabe von Systemänderungen ist ein Point of Focus von SOC 2 CC8.1, und ISO 27001 8.32 regelt das Change Management. Wie Änderungen von Agenten freigegeben werden, legt Ihre Richtlinie fest, und der Auditor prüft, ob die gezogenen Pull Requests dem entsprechen, was die Richtlinie sagt.

Brauchen wir ISO 42001, wenn wir KI-Coding-Agenten nutzen?

Nein. ISO/IEC 42001:2023 ist eine eigenständige Norm für ein KI-Managementsystem, von ISO für Organisationen gedacht, die KI-basierte Produkte oder Dienste anbieten oder nutzen. ISO 27001 verlangt sie nicht, und Ihr 27001-Auditor bewertet Ihren Einsatz von Agenten anhand der Maßnahmen von 27001.

Sind Schwachstellenscans für SOC 2 Pflicht?

Das Kriterium CC7.1 verlangt Erkennung und Überwachung, die neue Schwachstellen aufdecken, und „Conducts Vulnerability Scans“ ist einer seiner Points of Focus. Ein bestimmtes Werkzeug nennen die Kriterien nicht. Der Auditor prüft die Kontrollen, die Sie beschrieben haben, und bei einem Type-II-Bericht prüft er sie über den gesamten Zeitraum.

Wie erkenne ich in Git, welche Commits von einem KI-Agenten stammen?

Über das, was Ihre Agenten in Git schreiben. Claude Code hängt standardmäßig an jeden Commit einen Co-Authored-By-Trailer mit dem Namen des Modells an, und die Einstellung attribution kann ihn entfernen, legen Sie sie also in den Managed Settings fest. Stärker ist ein eigenes Maschinenkonto mit signierten Commits. Die Urheberschaft grenzt für den Auditor den Umfang ein; der Nachweis sind die Kontrollen auf jeder Änderung.