Worauf ein menschlicher Reviewer bei KI-generiertem Code wirklich achtet

Ein durch KI generierter Pull Request kann sauber, lesbar und voller grüner Tests sein. Er kann dem Projektstil folgen, die Dokumentation aktualisieren, sichtbare Bugs beheben und ein Feature in wenigen Stunden abschließen. Das Problem ist: Sicherheit lässt sich nicht daran beurteilen, ob der Code kompiliert oder die Demo funktioniert – man muss verstehen, was sich tatsächlich am Verhalten der Anwendung geändert hat.

Eine Secure Code Review bei KI-generiertem oder -modifiziertem Code sucht nicht nach „KI-Fehlern“ im Abstrakten. Sie liest das Diff innerhalb des Produkts: Welche Daten werden berührt, welche Routen sind exponiert, welche Rollen können Aktionen ausführen, welche Abfragen ändern sich, welche Geheimnisse gelangen in den Perimeter, welche Abhängigkeiten wurden hinzugefügt, welche Tests wurden geändert und welche Konfiguration geht in die Produktion.

Für Entwickler, CTOs und Softwarehäuser ist dies der kritische Punkt: KI-generierter Code kann plausibel wirken, selbst wenn er eine Sicherheitsregression einführt. Eine menschliche Überprüfung ist notwendig, um Code, Geschäftslogik, Vertrauensgrenzen (Trust Boundaries), Deployment und reales Risiko miteinander zu verknüpfen, bevor der Merge zu einer Schwachstelle in der Produktion wird.

Warum eine funktionale Überprüfung nicht ausreicht

Die funktionale Überprüfung fragt, ob das Feature das tut, was gefordert war. Die Secure Code Review fragt zusätzlich, was missbraucht werden kann, welche Annahmen sich geändert haben und welche Kontrollen abgeschwächt wurden. Dieser Unterschied ist entscheidend, wenn der Code von einer KI generiert wurde, da der Assistent dazu neigt, die Erledigung der Aufgabe zu optimieren, anstatt Sicherheitsgrenzen zu wahren, die im Prompt nicht explizit genannt wurden.

Ein menschlicher Reviewer liest den Code mit anderen Fragen als denen der Demo: Was passiert, wenn der Benutzer eine ID ändert, wenn das Token abgelaufen ist, wenn die Rolle niedrig ist, wenn der Mandant (Tenant) ein anderer ist, wenn der Upload eine unerwartete Datei enthält, wenn eine Abhängigkeit Skripte ausführt, wenn eine private Variable im Frontend landet oder wenn die Pipeline eine Kontrolle überspringt?

Scanner helfen, ersetzen aber nicht diese Lektüre. SAST, Dependency Scanning, Secret Scanning und Linter erkennen nützliche Muster, verstehen aber nicht immer Geschäftslogik, Mandantentrennung, Workflow-Zustände, den Missbrauch legitimer Funktionen, die Semantik von Rollen oder die Auswirkungen eines Refactorings über mehrere Dateien hinweg.

Die erste Kontrolle: Was hat der PR wirklich geändert?

KI-generierte PRs können umfangreich sein: Ein Prompt fordert „füge dieses Feature hinzu“ und der Agent ändert Routen, Komponenten, Middleware, Tests, Datenschemata, Abhängigkeiten, Konfigurationen und Dokumentation. Das Diff ist konsistent, aber der Reviewer muss Features, Refactoring, Tests und Sicherheitsänderungen voneinander trennen.

Die erste Aufgabe besteht darin, die betroffenen Dateien zu klassifizieren. Controller, API-Routen, Server-Actions, Middleware, Abfragen, Migrationen, Policies, .env.example-Dateien, CI/CD-Workflows, Dockerfiles, Paketmanager, Lockfiles, Speicher-Policies, Auth-Konfigurationen und Tests haben nicht das gleiche Gewicht. Eine kleine Änderung an Middleware oder CORS kann riskanter sein als hundert Zeilen UI-Code.

Wenn das Diff zu groß ist, muss es reduziert oder aufgeteilt werden. Eine effektive Review bedeutet, sagen zu können: Dieser Commit ändert die Anwendungslogik, dieser die Präsentation, dieser die Abhängigkeiten, dieser das Deployment. Wenn alles vermischt ist, steigt das Risiko, eine Regression zu akzeptieren.

Trust Boundary: Wo der Code aufhören muss, zu vertrauen

Ein menschlicher Reviewer sucht nach Vertrauensgrenzen. Der Browser ist nicht vertrauenswürdig, der Body einer Anfrage ist nicht vertrauenswürdig, und das Gleiche gilt für Header, Query-Strings, Local Storage, vom Client gesendete Rollen, hochgeladene Dateien und die Ausgabe eines Modells. Selbst ein interner Dienst kann weniger vertrauenswürdig sein als er scheint, wenn er Eingaben von Benutzern oder externen Integrationen erhält.

KI-generierter Code kann diese Grenzen überschreiten, ohne sie zu markieren: Er kann eine user_id vom Client verwenden, anstatt den Benutzer aus der Session zu nehmen, eine Abfrage mit nicht validierten Parametern erstellen, einen Token-Claim ohne Anwendungsprüfung als finale Berechtigung behandeln oder die Ausgabe eines LLM an HTML, SQL, Shell, Tickets, E-Mails oder nachgelagerte Tools weitergeben.

Bei der Review muss jede Vertrauensgrenze eine präzise Frage aufwerfen: Wer kontrolliert diese Daten, wo werden sie validiert, wo autorisiert, wo protokolliert, was passiert, wenn der Wert manipuliert wird? Wenn die Antwort nicht im Code steht, ist das Verhalten nicht verifizierbar.

Auth, Rollen und serverseitige Autorisierungen

Einer der wichtigsten Bereiche ist die Zugriffskontrolle (Access Control). Der Reviewer prüft, ob neue Routen einen Login erfordern, ob sie Rolle, Eigentümerschaft und Mandanten verifizieren, ob sie die korrekte Middleware anwenden und ob sie Sicherheitsentscheidungen nicht an die UI delegieren. Eine App kann korrekte Schaltflächen anzeigen, aber über APIs verfügen, die direkt aufgerufen werden können.

Die Review muss sensiblen Routen folgen: Daten lesen, ändern, löschen, exportieren, hochladen, Einladungen, Rollenwechsel, Admin-Funktionen, Abrechnung, Rückerstattungen, Genehmigungen und Identitätswechsel. Für jede muss der Code beantworten, wer sie aufrufen darf, auf welchen Objekten, in welchem Zustand und mit welchen Limits.

In KI-generiertem Code sind die häufigsten verdächtigen Muster: if (user) ohne Rollenprüfung, Abfragen nach ID ohne Eigentümerprüfung, tenant_id aus dem Body, isAdmin vom Client gelesen, Middleware nicht auf neue Routen angewendet, Tests, die nur den korrekten Benutzer prüfen. Diese Probleme tauchen oft nicht in der Demo auf.

Geschäftslogik und Workflows außerhalb der Sequenz

Die Geschäftslogik ist einer der Hauptgründe, warum eine menschliche Review erforderlich ist. Ein Agent kann die einzelnen Schritte gut implementieren, aber die Sequenz nicht schützen: Eine abgelaufene Einladung kann wiederverwendet werden, eine Bestellung nach der Zahlung geändert werden, eine Rückerstattung von einer falschen Rolle aufgerufen werden, eine Anfrage doppelt genehmigt werden, ein Export Daten außerhalb des Perimeters enthalten.

Der Reviewer sucht nach Invarianten: Was muss immer wahr sein? Eine bezahlte Bestellung ändert ihren Preis nicht. Ein Dokument eines Mandanten erscheint nicht bei einem anderen. Ein gesperrter Benutzer generiert keine API-Keys. Ein Einmal-Link kann nicht wiederverwendet werden. Eine Zahlung kann nicht allein deshalb bestätigt werden, weil das Frontend Erfolg anzeigt.

Die Code-Review muss auch die Zustände lesen, nicht nur die Funktionen. Wenn der Code Status, Rollen, Zahlungen, Quoten, Limits, Einladungen oder Autorisierungen ändert, sind Zustandsprüfungen, Idempotenz und negative Fälle erforderlich.

Abfragen, ORM und Access Layer

Viele Schwachstellen in KI-generiertem Code liegen nicht in der Syntax, sondern in der Abfrage. Ein ORM macht den Code lesbar, verhindert aber keine Abfragen ohne Mandantenfilter, zu breite Joins, fehlende Bedingungen oder Filter, die erst nach dem Abrufen der Daten angewendet werden. Eine Funktion kann alle Datensätze laden und clientseitig oder unvollständig anwendungsseitig filtern.

Der Reviewer prüft, wo Eigentümerschaft, Rolle und Mandant angewendet werden: in der Abfrage, im Service-Layer, in der Datenbank-Policy oder im Controller. Wenn der Filter in vielen Routen dupliziert wird, steigt das Risiko, dass eine neue, von der KI generierte Route ihn vergisst. Wenn der Service-Key die Policies umgeht und der Code nicht filtert, wird die Datenbank über das Backend exponiert.

Auch Migrationen und Seeds müssen gelesen werden: Die KI kann sensible Spalten hinzufügen, Standardwerte ändern, Indizes auf persönlichen Daten erstellen, ein kritisches Feld auf nullable setzen oder temporäre Tabellen einführen, die dann in der Produktion verbleiben. Das Datenmodell ist Teil der Angriffsfläche.

Eingabevalidierung, Ausgabeverarbeitung und Uploads

KI-generierter Code handhabt die vom Formular erwarteten Eingaben oft gut. Die Review muss sich die unerwarteten Eingaben ansehen: manipulierte JSON-Bodys, Query-Strings, Header, Pfadparameter, Datei-Uploads, gefälschte MIME-Typen, Dateinamen, Markdown, HTML, numerische Werte außerhalb des Bereichs, zu große Arrays, verschachtelte Objekte und Teil-Payloads.

Die Validierung muss serverseitig und konsistent mit der Domänenlogik sein. Wenn eine Menge positiv sein muss, wenn eine Rolle nur bestimmte Werte haben darf, wenn eine Datei ein PDF sein muss, wenn ein Datum nicht in der Vergangenheit liegen darf – diese Einschränkungen dürfen nicht nur im Frontend-Formular existieren.

Auch die Ausgabe muss gelesen werden. Nicht maskiertes HTML, gesprächige Fehlermeldungen, Stack-Traces, Abfragen, interne Pfade, Token, Datenbankdetails und Daten anderer Benutzer können aus Antworten, Logs, Exporten oder E-Mail-Vorlagen austreten. Eine sichere Review prüft sowohl, was hineingeht, als auch, was herauskommt.

Geheimnisse, Konfigurationen und Logs

Eine Code-Review bei KI-generiertem Code sucht an gewöhnlichen und ungewöhnlichen Orten nach Geheimnissen: Quellen, Tests, .env.example, README, Dockerfiles, Workflows, Skripte, Logs, Seeds, Fixtures, Cloud-Konfigurationen, Source-Maps und Frontend-Bundles. Die KI kann einen „temporären“ Schlüssel an eine Stelle kopieren, die dann im Deployment landet.

Die Review beschränkt sich nicht darauf zu sagen: „Verschiebe es in die env-Datei“. Sie prüft, ob dieses Geheimnis bereits nach außen gedrungen ist, ob es rotiert werden muss, ob es öffentlich oder privat ist, ob es den minimalen Scope hat und ob es im Client landen kann. Ein Service-Role-Key, eine Datenbank-URL oder ein Cloud-Token an der falschen Stelle können unmittelbare Auswirkungen haben.

Logging und Fehlerbehandlung sind weitere sensible Bereiche. Beim Debugging kann die KI sehr gesprächige Logs hinzufügen und im Code belassen: Der Reviewer prüft, ob in der Produktion keine Payloads, Token, Abfragen, PII, internen Pfade, vollständigen Stack-Traces oder Kundendaten ausgegeben werden.

Abhängigkeiten und Supply Chain im Diff

Wenn die KI auf einen Fehler stößt, schlägt sie oft eine Bibliothek vor. Das kann korrekt sein, aber jede neue Abhängigkeit vergrößert die Angriffsfläche des Produkts. Fast gleichnamige Pakete, wenig gewartete Bibliotheken, inkompatible Lizenzen, postinstall-Skripte, anfällige transitive Abhängigkeiten und geänderte Lockfiles müssen sorgfältig gelesen werden.

Der Reviewer vergleicht den tatsächlichen Bedarf mit den Kosten für die Einführung des Pakets: Gibt es bereits eine Bibliothek im Projekt? Wird die Abhängigkeit gewartet? Hat sie bekannte CVEs? Führt sie Skripte aus? Ändert sie Parsing, Auth, Krypto, Uploads, Sanitization, Templates oder Netzwerk? Zeigt das Lockfile mehr Änderungen als erwartet?

Bei KI-generiertem Code ist es wichtig, auch das zu lesen, was entfernt wird. Das Ersetzen einer Bibliothek kann implizite Kontrollen eliminieren, ein Framework-Update kann Sicherheitsstandards ändern und das Verschieben einer Funktion in ein „einfacheres“ Paket kann bereits vorhandene Validierungen verlieren.

KI-generierte Tests: Was sie bestätigen und was sie nicht herausfordern

Von der KI geschriebene Tests neigen dazu, das implementierte Verhalten zu bestätigen. Sie sind nützlich, decken aber oft nur den „Happy Path“ ab: korrekte Eingabe, korrekte Rolle, korrekter Status, erwartete Antwort. Eine Secure Code Review betrachtet auch das Diff der Tests, um zu sehen, ob sie abgeschwächt wurden.

Zu prüfende Signale: entfernte Tests, weniger präzise Assertionen, zu freizügige Mocks, fehlende negative Fälle, Snapshots ohne Erklärung aktualisiert, fehlende Autorisierungstests, als Erfolg behandelte Fehler, steigende Coverage, die aber keine Vertrauensgrenzen abdeckt.

Für jeden sensiblen Bereich sind negative Tests erforderlich: falscher Benutzer, falscher Mandant, abgelaufenes Token, niedrige Rolle, böswillige Eingabe, ungültige Datei, Zustand außerhalb der Sequenz, doppelte Anfrage, überschrittenes Limit. Wenn ein Sicherheitsbug gefunden wird, muss er zu einer Regression in der Pipeline werden.

Konfigurationen, CI/CD und Deployment

Ein KI-generierter PR kann auch das ändern, was den Code in die Produktion schickt: Dockerfiles, CI/CD-Workflows, Umgebungsvariablen, CORS, Sicherheits-Header, Debug-Modus, Logging, IaC, Cloud-Berechtigungen, Deployment-Skripte, Branch-Protection, Test-Gates. Diese Dateien sind kein „Beiwerk“.

Der Reviewer sucht nach gefährlichen Vereinfachungen: deaktivierte Tests, entferntes SAST, umgangenes Secret Scanning, aktives Debugging, CORS *, geschwächte CSP, Token mit zu weitem Scope, automatisches Deployment von ungeschützten Branches, gesprächigere Logs, mit der Produktion verbundene Staging-Umgebungen.

Wenn eine Konfigurationsänderung notwendig ist, muss sie explizit und verhältnismäßig sein. Ein Build, der durchgeht, weil die Kontrollen abgeschaltet wurden, ist kein stabileres Release: Es ist ein weniger beobachtbares Release.

Prompts, Rules-Dateien und persistente Anweisungen

Wenn das Projekt Cursor-Rules, AGENTS.md, Claude-Anweisungen, Projekt-Prompts oder ähnliche Dateien verwendet, muss die Review diese einbeziehen, wenn sie den generierten Code beeinflussen. Diese Anweisungen können Stil, Bibliotheken, Tests, Sicherheit, Deployment und Entscheidungen des Agenten steuern.

Eine Regeldatei kann nützliche Hinweise enthalten, aber auch gefährliche Abkürzungen: „deaktiviere Kontrollen in dev“, „verwende diesen Schlüssel“, „ignoriere flaky Tests“, „frage nicht nach Bestätigung“, „verwende freizügige Policies“. Wenn der Agent diese Anweisungen befolgt, gelangt das Risiko in den PR, auch wenn die Datei wie Dokumentation aussieht.

Der Reviewer prüft, ob die persistenten Anweisungen mit dem Verantwortungsbereich des Projekts konsistent sind. Für Teams, die KI-Coding kontinuierlich nutzen, werden diese Regeln Teil des Entwicklungsprozesses und verdienen explizite Eigentümerschaft.

Wie man einen zu großen KI-PR liest

Wenn ein von der KI generierter PR zu umfangreich ist, muss der Reviewer eine Sequenz rekonstruieren, die das Diff oft nicht gut wiedergibt. Zuerst wird das neue Verhalten identifiziert: Welches Feature wurde hinzugefügt, welcher Bug behoben, welcher Fluss geändert? Dann werden die unterstützenden Änderungen getrennt: Refactoring, Dateiverschiebungen, Umbenennungen, Testaktualisierungen, Abhängigkeiten, Konfigurationen.

Der nächste Schritt ist die Isolierung der Bereiche mit hoher Verantwortung. Selbst in einem riesigen PR wiegen manche Dateien schwerer als andere: Middleware, API-Routen, Auth-Provider, Abfragen, Migrationen, Secret-Handling, Deployment-Dateien, CI/CD-Workflows, Datenbank-Policies, serverseitige Funktionen und Zahlungslogik. Die Review muss dort beginnen, nicht bei den leicht zu lesenden visuellen Komponenten.

Wenn der PR gleichzeitig UI, API, Datenbank und Deployment ändert, kann die Forderung nach einer Trennung eine Sicherheitsentscheidung sein. Das ist keine Bürokratie: Es dient dazu, zu verhindern, dass eine Änderung an CORS, ein neues Paket, eine freizügigere Policy oder eine Abfrage ohne Mandantenfilter in einem scheinbar harmlosen Feature verborgen bleiben.

Für Softwarehäuser ist diese Disziplin noch wichtiger. Ein an den Kunden gelieferter KI-PR muss erklärt werden können: Was hat sich geändert, welche Dateien wurden generiert, welche Annahmen wurden akzeptiert, welche Tests beweisen, dass die Grenzen korrekt geblieben sind? Wenn man das Diff nicht erklären kann, ist es schwierig, dessen Sicherheit zu verteidigen.

Was aus der Review hervorgehen muss: Findings und Remediation

Eine nützliche Code-Review produziert nicht nur eine Liste von Problemen. Sie muss das Diff in Entscheidungen umwandeln: Was blockiert den Merge, was muss vor dem Deployment korrigiert werden, was kann geplant werden, welche Tests müssen hinzugefügt werden und welche Risiken bleiben mit einem Verantwortlichen bestehen? Dies ist bei KI-generiertem Code besonders wichtig, da sich dasselbe Muster in nachfolgenden PRs wiederholen kann.

Die Findings sollten mit Anwendungskontext beschrieben werden. „Fehlende Autorisierungskontrolle“ ist weniger nützlich als „der Export-Endpunkt verwendet die vom Client empfangene Mandanten-ID und ermöglicht es einem authentifizierten Benutzer, Daten eines anderen Workspaces zu exportieren“. Die zweite Formulierung ermöglicht es Entwicklern, CTOs und PMs, Auswirkungen, Priorität und Remediation zu verstehen.

Die Remediation sollte strukturelle Korrekturen bevorzugen. Wenn einem Endpunkt die Mandantentrennung fehlt, reicht es möglicherweise nicht aus, nur diese Route zu korrigieren: Es könnte ein zentraler Helper, eine Datenbank-Policy, ein negativer Test und eine Review-Regel für neue Routen erforderlich sein. Wenn eine Abhängigkeit ohne Grund hinzugefügt wurde, kann der Fix darin bestehen, sie zu entfernen, durch eine bereits genehmigte Bibliothek zu ersetzen oder automatische Installationen ohne Review zu blockieren.

Der Abschlussbericht sollte mindestens enthalten: überprüfter Perimeter, berücksichtigte Dateien und Commits, ausgeschlossene Bereiche, blockierende Findings, planbare Findings, vorgeschlagene Tests, Nachweise für Fixes, Restrisiken und Empfehlungen für zukünftige KI-PRs. Dies macht die Review wiederverwendbar, nicht nur korrigierend.

Wann eine unabhängige Code-Review erforderlich ist

Eine interne Review kann für kleine, isolierte Änderungen ausreichen, ohne echte Daten, ohne Rollen, ohne exponierte APIs und mit Reviewern, die in den betroffenen Bereichen Experten sind. Eine unabhängige Code-Review ist erforderlich, wenn der KI-generierte PR Auth, Autorisierungen, Abfragen, Datenbanken, Geheimnisse, Abhängigkeiten, Deployment, CI/CD, Cloud, Zahlungen, Uploads, Workflows oder kritische Geschäftslogik ändert.

Sie ist auch erforderlich, wenn das Diff zu umfangreich ist, um es zu verstehen, wenn das Team viele „Accept All“-Vorschläge akzeptiert hat, wenn die Scanner sauber sind, das Risiko aber in der Anwendungslogik liegt, oder wenn ein Softwarehaus Code an einen Kunden liefern muss und vor der Veröffentlichung Nachweise für die Kontrolle wünscht.

Die Code-Review verlangsamt nicht die Geschwindigkeit des KI-Codings: Sie verhindert, dass die Geschwindigkeit die Kosten auf die Zeit nach dem Go-Live verschiebt. Ein vor dem Merge korrigiertes Finding kostet weniger als eine Regression bei Daten, Rollen oder Deployments in der Produktion.

Wie ISGroup KI-generierten oder -modifizierten Code verifizieren kann

ISGroup kann eine gezielte Code-Review für die Hochrisikobereiche des KI-generierten Codes durchführen: Diff, Auth, Access Control, Geschäftslogik, Abfragen, Geheimnisse, Logging, Abhängigkeiten, Konfigurationen, Tests und Pipelines. Der Perimeter kann ein einzelner PR, ein Feature, ein Modul, ein Repository oder ein Fluss vor dem Go-Live sein.

Wenn der KI-Code geändert hat…	Hauptrisiko	Empfohlene Kontrolle
Auth, Rollen, Middleware, Abfragen, API, Geschäftslogik, Geheimnisse oder Abhängigkeiten	Schwachstellen im Code und Anwendungsregressionen	Code Review
Web-App, API, Uploads, Exporte oder online exponierte Flüsse	Von außen missbrauchbare Verhaltensweisen	Web Application Penetration Testing
CI/CD, Review-Policies, Branch-Protection, Test-Gates und kontinuierliche Nutzung von Agenten	Nicht wiederholbare Kontrollen bei Releases	Software Assurance Lifecycle
Cloud, IaC, IAM, Buckets, Datenbanken, Env und Deploy	Fehlkonfigurationen oder übermäßige Privilegien	Cloud Security Assessment
Dienste, Hosts oder Komponenten mit bekannten Versionen und Konfigurationen	Bekannte Schwachstellen und technische Oberflächen	Vulnerability Assessment

Die Wahl der Kontrolle hängt davon ab, was berührt wurde. Für KI-generierten Code sind Code Review und WAPT oft komplementär: Die Review findet die Ursache im Code, der Anwendungstest beweist das reale Verhalten.

Haben Sie einen PR oder ein Feature, das mit KI generiert wurde und Daten, APIs, Rollen, Abhängigkeiten oder Deployments berührt? ISGroup kann eine gezielte Review vor dem Merge oder Go-Live durchführen.

Vorbereitende Nachweise

Bereiten Sie Repository, Branch, PR, Feature-Beschreibung, relevante Prompts oder Anweisungen, Liste der geänderten Dateien, durchgeführte Tests, von der KI generierte Teile, hinzugefügte Abhängigkeiten, geänderte Konfigurationen, betroffene Umgebungen und bereits bekannte Risiken vor.

Für eine effektive Review sind auch Kontextdaten erforderlich: Benutzerrollen, Vertrauensgrenzen, exponierte APIs, Datenschemata, Auth-Provider, Datenbanken, Speicher, Pipelines, Umgebungsvariablen, Cloud-Dienste und kritische Flüsse. Der Code spricht nicht für sich selbst, wenn die Schwachstelle von der Domäne abhängt.

Wenn der PR umfangreich ist, ist es sinnvoll anzugeben, was als Refactoring betrachtet werden soll und was das Verhalten ändert. Wenn dies nicht klar ist, kann das erste Finding genau das Fehlen der Trennung zwischen funktionalen Änderungen und Sicherheitsänderungen sein.

Entscheidung vor dem Merge

Blockieren Sie den Merge, wenn die Review unvollständige Zugriffskontrollen, exponierte Geheimnisse, ungefilterte Abfragen, Service-Keys im Client, entfernte Sicherheitstests, verdächtige Abhängigkeiten, Debugging in der Produktion, grundloses freizügiges CORS, datenexponierende Fehlerbehandlung oder eine geschwächte Pipeline findet.

Sie können nach dem Merge nur Verbesserungen mit geringem Restrisiko und klarem Verantwortlichen planen: Dokumentation, nicht dringendes Refactoring, schrittweise Erhöhung der Tests, Reduzierung von Duplikaten, Verbesserung der Benennung. Schwachstellen, die Daten, Rollen, Zahlungen, Cloud oder Deployment exponieren, müssen vorher korrigiert werden.

Die Entscheidung muss Nachweise produzieren: Was wurde überprüft, welche Findings wurden korrigiert, welche negativen Tests wurden hinzugefügt, welche Risiken bleiben bestehen und wer besitzt sie?

Checkliste für die Review von KI-generiertem Code

• Klassifizieren Sie die vom Diff betroffenen Dateien und Bereiche.
• Trennen Sie Features, Refactorings, Tests, Abhängigkeiten und Konfigurationen.
• Überprüfen Sie Auth, Rollen, Mandanten, Middleware und serverseitige Kontrollen.
• Lesen Sie Abfragen, Migrationen, Policies und Access Layer.
• Prüfen Sie Geschäftslogik, Zustände, Idempotenz und Fälle außerhalb der Sequenz.
• Verifizieren Sie Eingabevalidierung, Ausgabe-Encoding, Uploads und Fehlerbehandlung.
• Suchen Sie nach Geheimnissen, gesprächigen Logs, .env-Dateien, Connection-Strings und Token.
• Überprüfen Sie Abhängigkeiten, Lockfiles, Skripte und neue Pakete.
• Kontrollieren Sie CI/CD, CORS, Header, Dockerfiles, Env, IaC und Deployments.
• Fordern Sie negative Tests für jeden sensiblen Bereich.

FAQ

• Wenn SAST und Tests grün sind, ist dann noch eine Code-Review nötig?
• Ja. Scanner und Tests erkennen Muster und erwartete Pfade, aber nicht immer Geschäftslogik, Autorisierungen, Vertrauensgrenzen, Workflows und die Auswirkungen des Diffs auf das Produkt.
• Worauf achtet ein menschlicher Reviewer, was die KI nicht sieht?
• Auf den Anwendungskontext: Wer darf was tun, welche Daten sind sensibel, welche Grenzen dürfen nicht überschritten werden, welche Geschäftsannahmen müssen wahr bleiben und welches Risiko gelangt in die Produktion.
• Welche KI-PRs sind am riskantesten?
• Diejenigen, die Auth, Rollen, APIs, Datenbanken, Geheimnisse, Abhängigkeiten, CI/CD, Cloud, Zahlungen, Uploads, Exporte, Logging oder Deployment-Konfigurationen berühren.
• Ersetzt die Code-Review das WAPT?
• Nein. Die Code-Review findet Probleme im Code und in der Logik. Das WAPT verifiziert das reale Verhalten von außen. Bei exponierten Apps sind oft beide erforderlich.
• Wann ist der Software Assurance Lifecycle erforderlich?
• Wenn KI-Coding stabil vom Team genutzt wird und es notwendig ist, Reviews, Tests, Policies, Gates und Kontrollen bei jedem Release wiederholbar zu machen.
• Kann ich nur ein Feature überprüfen lassen?
• Ja, wenn der Perimeter klar ist: PR, Modul, Fluss, Route oder Komponente. Bei Features, die Daten und Rollen berühren, müssen auch Tests, Konfigurationen und zugehörige Abhängigkeiten einbezogen werden.

[Callforaction-CR-Footer]

Quellen und nützliche Referenzen

• OWASP Code Review Guide: https://owasp.org/www-project-code-review-guide/
• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
• OWASP Top 10 2021: https://owasp.org/Top10/2021/
• OWASP Broken Access Control: https://owasp.org/Top10/en/A01_2021-Broken_Access_Control/
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
• OWASP SAMM: https://owasp.org/www-project-samm/