KI & Sicherheit

KI-Code und Reviews

Wie KI-generierter oder KI-unterstützter Code geprüft, verstanden und verantwortet werden sollte.

Stand: 2026-06-05

Kurzfassung

  • KI-Code ist eigener Code: verstehen, prüfen, testen, verantworten.
  • Ungeprüfter KI-Code ist tabu.
  • Der Entwickler trägt Verantwortung für Code, Tests, Commit-Message und MR-/PR-Inhalt.
  • KI-Beteiligung soll im Merge Request oder Pull Request sichtbar sein.
  • Sensible Bereiche brauchen zweites Review oder Lead-/Maintainer-Review.
  • KI-generierte Tests sind erlaubt, aber keine unabhängige Kontrolle.
  • KI darf Review unterstützen, aber nicht abschließend freigeben.
  • Automatisch formulierte Commit-Messages sind erlaubt, müssen aber fachlich geprüft werden.

Thema

Code, Tests, Refactorings, Commit-Messages und Reviews, die mit KI-Unterstützung entstehen oder stark durch KI beeinflusst wurden.

Ausgangslage

KI-Assistenten werden im Entwickleralltag für Code, Refactoring, Tests, Erklärungen, Commit-Messages und Review-Unterstützung genutzt.

Direktes Pushen oder Mergen in den Hauptbranch ist tabu. Änderungen laufen über Merge Requests oder Pull Requests auf GitHub, GitLab oder Bitbucket.

Commit-Messages werden teilweise automatisch formuliert. Das ist zulässig und kann sogar helfen: Wenn die KI den Diff nicht richtig beschreibt, ist das ein Warnsignal für den Entwickler.

Die wichtigste praktische Erkenntnis:

KI kann Code erzeugen, aber keine Verantwortung übernehmen.

Risiko in einem Satz

KI-Code kann plausibel, sauber und vollständig wirken, aber fachlich falsch, unsicher, ungetestet oder nur scheinbar durch passende Tests abgesichert sein.

Grundsatz

KI-Code ist eigener Code.

KI-Code ist eigener Code: verstehen, prüfen, testen, verantworten.

Daraus folgt:

  • KI-Code darf nicht ungeprüft übernommen werden.
  • Der einbringende Entwickler trägt die Verantwortung.
  • Hat die KI so gemacht ist keine Begründung.
  • Code darf nur gemerged werden, wenn der Entwickler ihn fachlich und technisch erklären kann.
  • Review bleibt menschliche Verantwortung.

Verantwortung

Der Entwickler verantwortet:

  • den eingebrachten Code,
  • die fachliche Wirkung,
  • die technischen Seiteneffekte,
  • die Tests,
  • die Commit-Message,
  • die MR-/PR-Beschreibung,
  • die Einhaltung von Projektregeln,
  • die Einhaltung von Sicherheitsgrenzen.

Das gilt auch dann, wenn:

  • KI den Code geschrieben hat,
  • KI Tests vorgeschlagen hat,
  • KI die Commit-Message formuliert hat,
  • KI den Diff vorher geprüft hat,
  • ein zweiter KI-Agent den ersten KI-Agenten gegengeprüft hat.

Kernregel:

KI-Unterstützung entlastet nicht von Entwicklerverantwortung.

MR-/PR-Hinweis bei KI-Beteiligung

Wenn KI wesentlich beteiligt war, soll das im Merge Request oder Pull Request sichtbar sein.

Empfohlene Angaben:

  • KI-Unterstützung: ja/nein,
  • genutzt für Code, Refactoring, Tests, Review, Dokumentation oder Commit-Message,
  • sensible Bereiche betroffen: ja/nein,
  • Code wurde vom Entwickler geprüft: ja/nein,
  • Tests wurden vom Entwickler geprüft: ja/nein.

Beispiel:

KI-Unterstützung: ja
Genutzt für: Refactoring und Testvorschläge
Sensible Bereiche betroffen: nein
Code geprüft: ja
Tests geprüft: ja

Das Ziel ist keine Bürokratie, sondern Sichtbarkeit.

Kernregel:

KI-Beteiligung ist kein Makel, aber sie darf nicht unsichtbar bleiben.

Sensible Bereiche

Sensible KI-Codeänderungen brauchen zweites Review oder Lead-/Maintainer-Review.

Das gilt mindestens für:

  • Authentifizierung,
  • Rollen und Rechte,
  • Kundendaten,
  • Zahlungs- oder Vertragslogik,
  • Datenmigrationen,
  • Deployment/CI/CD,
  • Secrets und Konfiguration,
  • externe APIs mit Schreibwirkung,
  • Security-Fixes,
  • Lösch- und Schreiboperationen,
  • SQL, Queries und Datenmodelländerungen,
  • Datei-Uploads und Dateiverarbeitung.

Warum:

  • Fehler sind dort oft nicht sofort sichtbar.
  • Tests decken Seiteneffekte oft nur teilweise ab.
  • KI kann Sicherheitsannahmen plausibel, aber falsch formulieren.
  • Kleine Änderungen können große produktive Wirkung haben.

Kernregel:

Sensibler KI-Code braucht mehr Aufmerksamkeit, nicht nur grüne Tests.

Tests

Tests sind Prüfmittel, kein Freifahrtschein.

KI darf Tests vorschlagen oder schreiben. Diese Tests gelten aber nicht automatisch als unabhängige Kontrolle.

Besonders kritisch:

  • Code und Tests kommen aus derselben KI-Sitzung.
  • Tests prüfen nur den Happy Path.
  • Tests bestätigen nur die neue Implementierung.
  • Randfälle, Rechtefälle oder Fehlerfälle fehlen.
  • Tests sind schwer lesbar oder fachlich unklar.

Der Entwickler muss prüfen:

  • ob die Tests das tatsächliche Risiko abdecken,
  • ob relevante Fehlerfälle enthalten sind,
  • ob Rechte- und Sicherheitsfälle geprüft werden,
  • ob bestehendes Verhalten geschützt bleibt,
  • ob die Tests fachlich sinnvoll sind.

Bei sensiblen Bereichen reichen reine Happy-Path-Tests nicht aus.

Kernregel:

KI-generierte Tests prüfen nicht unabhängig, wenn sie dieselbe Annahme wie der KI-Code teilen.

Commit-Messages

Automatisch formulierte Commit-Messages sind erlaubt, aber sie sind ein Kontrollpunkt.

Jeder Commit braucht eine aussagekräftige Beschreibung.

Nicht ausreichend:

  • fix,
  • update,
  • changes,
  • KI Anpassungen,
  • misc,
  • cleanup.

Die Commit-Message muss grob erklären:

  • was geändert wurde,
  • warum es geändert wurde,
  • ob relevante Risiken betroffen sind.

Wenn KI die Commit-Message formuliert, prüft der Entwickler vor dem Commit:

  • Beschreibt die Message wirklich die Änderung?
  • Fehlt eine riskante Änderung?
  • Behauptet sie Tests, Reviews oder Sicherheit, die nicht stattgefunden haben?
  • Verharmlost sie Migrationen, Config-, Rechte- oder Security-Änderungen?
  • Passt die Beschreibung zum Diff?

Beispiel:

Validate customer export permissions before export

- checks explicit export permission before job creation
- prevents exports for users without assigned role
- adds regression test for missing permission case

Wenn Merge Requests oder Pull Requests gesquasht werden, muss die finale Squash- oder Merge-Message genauso geprüft werden.

Wandregel:

Wenn die KI den Diff nicht richtig erklärt, prüfe den Diff doppelt.

Review mit KI-Unterstützung

KI darf Review unterstützen, aber nicht abschließend freigeben.

Erlaubt:

  • KI fasst den MR/PR zusammen,
  • KI sucht Risiken im Diff,
  • KI schlägt Testfälle vor,
  • KI erklärt fremden Code,
  • KI prüft KI-generierten Code als zweite technische Sicht,
  • ein KI-Agent prüft Arbeit eines anderen KI-Agenten.

Nicht erlaubt:

  • KI als alleiniger Reviewer,
  • KI-Approval als Ersatz für menschliches Review,
  • Merge nur wegen KI hat nichts gefunden,
  • sensible Bereiche ohne menschliches Lead-/Maintainer-Review mergen.

Kernregel:

KI-gegen-KI ist Plausibilitätsprüfung, keine Freigabe.

Copy/Paste und Herkunft

KI kann Code vorschlagen, dessen Herkunft unklar ist. Deshalb gelten bei größeren Snippets und fremden Mustern zusätzliche Vorsichtspunkte.

Nicht erlaubt:

  • große fremde Codeblöcke ungeprüft übernehmen,
  • unbekannte Snippets ohne Verständnis einbauen,
  • Lizenztexte oder Copyright-Hinweise entfernen,
  • proprietäre Namen oder fremde interne Bezeichner übernehmen,
  • auffällige 1:1-Bibliothekskopien ins Projekt kopieren.

Empfohlen:

  • Snippets verstehen,
  • Lösung an Projektstil anpassen,
  • kleine eigene Implementierung bevorzugen,
  • bei Unsicherheit neu formulieren,
  • bei größeren Fremdanteilen Herkunft und Lizenz klären,
  • unnötige neue Dependencies vermeiden.

Kernregel:

Unklare Herkunft ist ein Review-Signal.

P0-No-Gos

Nicht erlaubt ist ungeprüfter KI-Code.

Nicht erlaubt ist Code, den der einbringende Entwickler nicht erklären kann.

Nicht erlaubt sind ungeprüfte KI-Tests.

Nicht erlaubt sind sensible KI-Codeänderungen ohne zweites Review oder Lead-/Maintainer-Review.

Nicht erlaubt ist KI als abschließender Reviewer.

Nicht erlaubt ist Merge oder Push in den Hauptbranch außerhalb des MR-/PR-Prozesses.

Nicht erlaubt sind Commit-Messages, die falsche Aussagen über Tests, Review oder Sicherheit enthalten.

Nicht erlaubt ist blindes Copy/Paste großer oder unbekannter Codeblöcke.

Nicht erlaubt ist die Übernahme von Lizenz-, Copyright- oder proprietär wirkenden Fremdteilen ohne Klärung.

Mindeststandard

Für KI-unterstützte Codeänderungen gilt mindestens:

  • Code wurde vom Entwickler gelesen,
  • Code wurde fachlich verstanden,
  • Diff wurde geprüft,
  • Commit-Message wurde geprüft,
  • relevante Tests wurden ausgeführt oder bewusst begründet,
  • KI-generierte Tests wurden geprüft,
  • MR/PR enthält Hinweis auf wesentliche KI-Beteiligung,
  • sensible Bereiche sind markiert,
  • sensible Bereiche haben zweites Review oder Lead-/Maintainer-Review.

Praktischer Review-Check

Vor Commit:

  • Diff lesen,
  • Commit-Message prüfen,
  • Tests prüfen,
  • sensible Bereiche erkennen,
  • keine Secrets, Dumps oder Logs im Diff.

Vor MR/PR:

  • KI-Beteiligung angeben,
  • sensible Bereiche markieren,
  • relevante Tests nennen oder sichtbar machen,
  • ungewöhnliche KI-Entscheidungen erklären,
  • bei sensiblen Bereichen Lead-/Maintainer-Review einplanen.

Im Review:

  • fachliche Wirkung prüfen,
  • Sicherheitswirkung prüfen,
  • Tests gegen Risiken prüfen,
  • Commit-/MR-Text gegen Diff prüfen,
  • KI-Review nur als Zusatzsignal behandeln.

Teamentscheidung

KI-Code ist eigener Code: verstehen, prüfen, testen, verantworten.

Ungeprüfter KI-Code ist tabu.

Der Entwickler trägt die Verantwortung für Code, Tests, Commit-Message und MR-/PR-Inhalt.

Wesentliche KI-Beteiligung soll im MR/PR sichtbar sein, inklusive Hinweis, dass Code und Tests geprüft wurden.

Sensible Bereiche brauchen zweites Review oder Lead-/Maintainer-Review.

KI-generierte Tests sind erlaubt, aber keine unabhängige Kontrolle.

KI darf Review unterstützen, aber nicht abschließend freigeben.

Automatisch formulierte Commit-Messages sind erlaubt, müssen aber fachlich geprüft werden.

Wandregeln

KI-Code ist eigener Code: verstehen, prüfen, testen, verantworten.

Ungeprüfter Code ist tabu.

Grüne KI-Tests sind kein Freifahrtschein.

KI-Review unterstützt, Menschen geben frei.

Wenn die KI den Diff nicht richtig erklärt, prüfe den Diff doppelt.

Offene Teamfragen

  • Wie genau wird KI-Beteiligung im MR-/PR-Template abgefragt?
  • Welche Projektbereiche gelten zusätzlich als sensibel?
  • Wer darf Lead-/Maintainer-Review für sensible KI-Codeänderungen geben?
  • Welche Testnachweise sollen bei sensiblen Bereichen Pflicht sein?
  • Wie wird mit Squash-Messages in GitHub, GitLab oder Bitbucket umgegangen?