Sicherheitslücken im eigenen Code mit KI finden

Um Sicherheitslücken in deinem Code mit KI zu finden, lässt du zuerst die schnellen, deterministischen Scanner laufen (Secrets, Abhängigkeiten, statische Regeln). Danach gibst du einem Coding-Agenten jeweils eine Schwachstellenklasse und lässt ihn verfolgen, wie nicht vertrauenswürdige Eingaben durch deinen Code wandern. Behandle jeden Fund als Behauptung, die du prüfst, behebe ihn mit einem Regressionstest und halte den Agenten die ganze Zeit von echten Secrets fern.

In dieser Anleitung geht es um ein defensives Audit deines eigenen Codes. Wenn du wissen willst, wie du verhinderst, dass der Agent selbst Schaden anrichtet (Prompt Injection, zerstörerische Befehle, bösartige MCP-Server), lies zuerst Sicherheit von KI-Coding-Agenten; dieser Artikel setzt voraus, dass diese Schutzmaßnahmen stehen. Toolnamen und Befehle folgen der offiziellen Dokumentation mit Stand Oktober 2026.

Was ein KI-Audit gut kann und was nicht

Statische Scanner und Coding-Agenten finden unterschiedliche Bugs, deshalb willst du beide.

Ein Agent glänzt etwa bei einem Endpoint, der prüft, ob du angemeldet bist, aber nie, ob die Bestellung, die du liest, dir gehört. Das sieht kein Regex. Umgekehrt bemerkt ein Agent nicht zuverlässig, dass lodash in deinem Lockfile drei Jahre alt ist; npm audit schon.

Was keiner von beiden tut: dein laufendes System testen. Ein Agent liest den Quellcode in deinem Checkout. Falsch konfigurierter Cloud-Speicher, eine Firewall-Regel oder ein geleakter Token in einem Chatverlauf liegen außerhalb seines Blickfelds.

Bevor du anfängst: ein sicheres Setup

Ein Sicherheitsaudit besteht vor allem aus Lesen, also richte es auch so ein.

• Arbeite auf einem Branch oder in einem Git-Worktree. Audit und Fixes sollen leicht zu prüfen und leicht zu verwerfen sein.
• Beginne nur lesend. In Claude Code nutzt du für das Audit selbst den Plan Mode (Shift+Tab oder /plan); in Codex /permissions → Read Only oder --sandbox read-only. Auf Bearbeiten schaltest du erst um, wenn du behebst.
• Halte Secrets außer Reichweite. Füge niemals Keys, Tokens oder den Inhalt von .env in einen Prompt ein. Wenn der Agent wissen muss, dass eine Variable existiert, reicht der Name. Lesen sollte er eine .env.example mit Fantasiewerten.
• Nutze Entwicklungs-Zugangsdaten. Wenn der Agent deine Tests ausführt, sollten diese mit einer lokalen oder Staging-Datenbank und Wegwerf-Keys sprechen, nie mit Produktion.

Schritt 1: die deterministischen Scanner laufen lassen

Sie brauchen Sekunden und geben dem Agenten konkrete Spuren. Alle kannst du lokal kostenlos ausführen.

# Secrets in git history and in the working tree (gitleaks v8.19+)
gitleaks git -v .
gitleaks dir -v .

# Known-vulnerable dependencies
npm audit --audit-level=high
pip-audit -r requirements.txt

# Static analysis rules for your languages
semgrep scan --config auto

Ein paar Hinweise aus der offiziellen Dokumentation:

• gitleaks hat in v8.19.0 seinen alten Befehl detect in git (Commits scannen) und dir (Dateien scannen) aufgeteilt; die alten Befehle funktionieren noch, tauchen aber nicht mehr in der Hilfe auf.
• npm audit --audit-level ändert nur den Exit-Code, nicht den Bericht. npm audit fix führt eine echte Installation aus; npm audit fix --force kann SemVer-Major-Updates installieren, also nicht blind ausführen.
• pip-audit prüft ohne Argumente die aktuelle Python-Umgebung; -r prüft eine Requirements-Datei.
• Semgrep --config auto holt auf dein Projekt zugeschnittene Regeln aus der Semgrep Registry und braucht deshalb Netzwerkzugriff. Mit --error beendet es sich bei Funden mit 1, und genau das willst du in CI.

Speichere die Ausgabe in einer Datei. In Schritt 3 gibst du sie dem Agenten, statt sie abzutippen.

Schritt 2: eine Schwachstellenklasse nach der anderen prüfen

„Finde Sicherheitsbugs in diesem Repo“ bringt dir eine oberflächliche Liste. Ein fokussierter Prompt pro Klasse bringt echte Analyse. Die OWASP Top 10:2025 sind eine gute Landkarte; diese Klassen lohnen sich in einer typischen Web-App zuerst:

Ein Prompt, der funktioniert, im Plan Mode:

Prüfe dieses Repository auf fehlerhafte Zugriffskontrolle. Bearbeite keine Dateien.

1. Liste jede HTTP-Route auf, die einen Datensatz per ID liest, aktualisiert
   oder löscht.
2. Finde für jede, woher die Identität des Aufrufers kommt und ob die
   Query auf Datensätze beschränkt ist, die dem Aufrufer gehören (User oder Tenant).
3. Melde nur Routen, bei denen du die fehlende Prüfung belegen kannst.

Gib für jeden Fund an: file:line, die Route, woher die ID kommt,
warum die vorhandene Middleware sie nicht abdeckt, und einen Schweregrad
(high/medium/low). Wenn du unsicher bist, sag das, statt zu raten.

Wiederhole dieselbe Form für Injection, Authentifizierung und SSRF. Eine Klasse pro Unterhaltung hält das Kontextfenster fokussiert, und du kannst sie parallel in getrennten Sessions laufen lassen.

Bei Injection hilft es, dem Agenten zu sagen, wie „sicher“ in deinem Stack aussieht, damit er nicht jede Query markiert:

Wir nutzen überall parametrisierte Queries über db.query(sql, params).
Finde jede Stelle, die SQL, Shell-Befehle oder HTML aus Request-Daten
baut, ohne über die Parameter von db.query, execFile mit einem
Argument-Array oder das Escaping der Template-Engine zu gehen.
Ignoriere Code unter tests/.

Schritt 3: die eingebauten Sicherheitsreviews nutzen

Mehrere Agenten bringen inzwischen ein Sicherheitsreview mit, das du nicht selbst schreiben musst.

Claude Code /security-review. Die offizielle Befehlsreferenz beschreibt ihn als Analyse der Änderungen auf deinem aktuellen Branch auf Sicherheitslücken: Er prüft den Diff zwischen deinem Branch und dem Standard-Branch von origin und sucht nach Risiken wie Injection, Problemen bei der Authentifizierung und offengelegten Daten. Er braucht ein origin-Remote. Er deckt nur die Änderungen deines Branches ab, also führ ihn aus, bevor du einen Pull Request öffnest. Anthropics Repository claude-code-security-review erklärt, wie du ihn anpasst: Kopiere dessen security-review.md nach .claude/commands/ und ergänze eigene Regeln, zum Beispiel welche Muster in deiner Codebasis sicher sind.

Claude-Code-Plugin security-guidance. Installiert mit /plugin install security-guidance@claude-plugins-official, prüft es Code, während Claude ihn schreibt: eine Musterprüfung bei jeder Bearbeitung (Dinge wie eval(, child_process.exec, .innerHTML =), ein Sicherheitsreview des Diffs jedes Turns im Hintergrund und ein gründlicheres Review, wenn Claude committet. Projektregeln kannst du in .claude/claude-security-guidance.md ergänzen. Die Dokumentation sagt klar, dass es keine Schreibvorgänge blockiert und Probleme übersehen kann; es ist eine Schicht von mehreren.

Codex /review. Der Review-Befehl von Codex (und codex review --uncommitted oder --base main in der Shell) ist ein allgemeines Code-Review. Bitte ihn ausdrücklich, sich auf Sicherheit zu konzentrieren, wenn du das willst.

Gemini-CLI-Erweiterung security. Installiert mit gemini extensions install https://github.com/gemini-cli-extensions/security, ergänzt sie /security:analyze für die Änderungen auf deinem Branch und /security:scan-deps, das Abhängigkeiten mit OSV-Scanner prüft.

Für Code, den du schon hast, statt der Änderungen eines Branches, nimmst du die Prompts pro Klasse aus Schritt 2. Du kannst auch die Scanner-Ausgabe hineingeben:

Hier ist die Ausgabe von semgrep und npm audit in scan-results.txt.
Prüfe für jeden Fund, ob er in dieser Codebasis von Benutzereingaben
aus erreichbar ist. Markiere jeden als bestätigt, wahrscheinlich
Fehlalarm oder braucht einen Menschen, mit einer einzeiligen Begründung.
Bearbeite keine Dateien.

Schritt 4: echte Funde von Fehlalarmen trennen

KI-Sicherheitsreviews klingen gleich überzeugt, ob sie recht haben oder nicht. Verlange Belege statt Urteile:

• Quelle: Wo kommt der nicht vertrauenswürdige Wert herein? Ein Request-Body, ein Query-String, ein Datei-Upload, ein Webhook?
• Pfad: Durch welche Funktionen läuft er, bis er den riskanten Aufruf erreicht? Lass dir die Kette mit file:line für jeden Schritt geben.
• Schutz: Welche Validierung, welches Escaping oder welche Autorisierung liegt auf diesem Pfad, und warum deckt sie diesen Fall nicht ab?
• Erreichbarkeit: Ist die Route erreichbar? Ein Fund in einem toten Admin-Skript ist etwas anderes als einer in einer öffentlichen API.

Dann hol dir eine zweite Meinung. Eine frische Session, besser noch ein anderes Modell, sollte Funde mit hohem Schweregrad prüfen, bevor jemand einen Fix schreibt. Gib ihr den Fund und den Code, nicht die Begründung des ersten Agenten, damit sie nicht einfach zustimmt. KI-Code-Review beschreibt, wie du Funde gewichtest und diese Schleife begrenzt hältst.

Typische Fehlalarme, mit denen du rechnen solltest: SQL, das nur aus Konstanten gebaut wird, HTML, das durch das automatische Escaping eines Frameworks läuft, Test-Fixtures mit Fantasie-Keys und serverseitige Anfragen an eine feste interne URL. Schreib die sicheren Muster in CLAUDE.md oder AGENTS.md, damit spätere Audits sie nicht mehr markieren.

Schritt 5: mit einem Regressionstest beheben

Ein Sicherheitsfix ohne Test kommt gern zurück. Verlange zuerst den Test:

Behebe die fehlende Besitzerprüfung in GET /api/orders/:id (Fund #2).

1. Schreib zuerst einen Test, in dem User A die Bestellung von User B
   anfragt, und erwarte ein 404. Führ ihn aus und zeig mir, dass er fehlschlägt.
2. Ergänze dann die Prüfung auf die kleinste Art, die zu unserer
   vorhandenen Middleware passt. Ändere keinen Code, der nichts damit zu tun hat.
3. Führ die komplette Testsuite aus und zeig mir den Diff.

Der erst fehlschlagende, dann bestandene Test beweist, dass der Bug existierte und dass der Fix ihn abdeckt. Lege jeden Fix in einen eigenen Commit mit einer klaren Nachricht, damit die History erklärt, was falsch war. Zur allgemeinen Gewohnheit, test-first zu beheben, siehe Code mit KI debuggen.

Dieselbe Disziplin gilt für Funde bei Abhängigkeiten: ein Paket nach dem anderen aktualisieren, die Tests ausführen, das Changelog auf Breaking Changes lesen. Ein massenhaftes npm audit fix --force ist der Weg, auf dem aus einem Audit ein Ausfall wird.

Wenn du ein echtes Secret im Repo findest

Das ist der eine Fall, in dem die Reihenfolge der Schritte zählt:

1. Rotiere das Secret zuerst. Widerrufe den Key beim Anbieter und stelle einen neuen aus. Sobald ein Secret gepusht wurde, gilt es als kompromittiert; das Löschen der Datei macht das Leak nicht rückgängig.
2. Leg das neue Secret in deinen Secret-Manager oder die Umgebung, nicht wieder in den Code.
3. Dann aufräumen: Entferne es aus dem Code und entscheide mit deinem Team, ob ihr die History umschreibt. Die History umzuschreiben hilft nichts, wenn der Key nicht rotiert wurde.
4. Verhindere das nächste Mal mit einem Pre-Commit-Hook. gitleaks dokumentiert diesen Eintrag für .pre-commit-config.yaml:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Lass dir vom Agenten bei den Schritten 2 bis 4 helfen, aber nie, indem du das Secret in die Unterhaltung einfügst. „Der Stripe-Key in src/config.ts muss in eine Umgebungsvariable namens STRIPE_SECRET_KEY umziehen“ ist alles, was er braucht.

Mach es dauerhaft

Ein einmaliges Audit veraltet, sobald neuer Code dazukommt. Pack die deterministischen Prüfungen in CI und behalte das KI-Review für Pull Requests:

# .github/workflows/security.yml (excerpt)
- run: npm audit --audit-level=high
- run: semgrep scan --config auto --error

Für einen KI-Durchlauf bei jedem Pull Request kommentiert Anthropics GitHub Action anthropics/claude-code-security-review die Funde im PR. Ihr Pflicht-Input ist claude-api-key; zu den optionalen Inputs gehören comment-pr, exclude-directories und false-positive-filtering-instructions. Wenn du Claude schon in GitHub Actions nutzt, behandelt Claude Code GitHub Actions Einrichtung und Umgang mit Secrets.

So geht es mit AgentVera

AgentVera ist eine Desktop-App für macOS, Windows und Linux, die Claude Code, Codex, Gemini CLI und andere CLI-Agenten in echten Terminals nebeneinander ausführt. Für Sicherheitsaudits macht das einige Setups einfach:

• Workspace: Stell einen nur lesenden Auditor (Berechtigung auf Ask) neben einen Fixer, der in einem Worktree arbeitet, und ein drittes Pane mit einem anderen CLI als zweite Meinung. Jeder Agent behält seine eigene Berechtigungsstufe.
• Code-Review: Schalte in den Projekteinstellungen das Review am Ende jedes Turns ein, und ein Claude-Modell deiner Wahl prüft die Änderungen des Fixers; Funde kommen mit Schweregrad und file:line-Link und können zurück an den Agenten gehen, höchstens zwei Runden am Stück.
• Review-Inbox: Fertige Arbeit wartet als Karten, und riskante Änderungen werden markiert: Auth- und Sicherheitscode, Abhängigkeitsdateien, CI- und Infra-Dateien, .env und Änderungen ohne Tests.
• Verify (Pro und Team): Ein separater, nur lesender Prüfer gleicht das Ergebnis mit den Kriterien aus deiner Anfrage ab, etwa „es gibt einen Regressionstest, und er schlägt ohne den Fix fehl“.
• Agenten in Docker: Führe Claude Code oder Codex in einem Container aus, der nur den Projektordner sieht, sodass Dateien und SSH-Keys an anderen Stellen deines Rechners während eines Audits außer Reichweite bleiben.
• Checkpoints: Jeder Turn wird als Snapshot gesichert, ein missglückter Fix ist also mit einem Klick rückgängig gemacht.

Raster, Worktrees, Code-Review und Docker-Agenten gehören zum Free-Tarif. Lade AgentVera herunter und führe dein erstes Audit auf einem Branch aus.

Häufige Fehler

• Nach „allen Sicherheitsproblemen“ auf einmal fragen. Du bekommst eine generische Checkliste. Prüfe eine Klasse nach der anderen.
• Beheben, bevor geprüft ist. Ein „behobener“ Fehlalarm fügt Code hinzu, den niemand versteht. Hol dir zuerst Belege.
• Secrets einfügen, um zu „prüfen, ob sie gültig sind“. Niemals. Rotiere sie stattdessen.
• npm audit fix --force in einer Agenten-Schleife ausführen. Major-Upgrades machen Dinge kaputt, die scheinbar nichts damit zu tun haben.
• Ein sauberes KI-Review als Garantie sehen. Es heißt nur, dass der Agent diesmal nichts gefunden hat. Lass die Scanner in CI.
• Den Auditor bearbeiten lassen. Halte das Audit nur lesend und die Fixes in einem separaten, geprüften Schritt.

Fazit

Fang mit gitleaks, deinem Abhängigkeits-Auditor und Semgrep an. Prüfe dann mit einem nur lesenden Agenten eine OWASP-Klasse nach der anderen und verlange Belege mit file:line und einen erreichbaren Pfad. Führe vor jedem Pull Request /security-review (oder das Gegenstück deines Agenten) aus, lass eine zweite Session die ernsten Funde prüfen und behebe jeden mit einem Regressionstest, der zuerst fehlschlägt. Wenn ein Secret leakt, rotiere es vor allem anderen. Wenn du Agenten an die Fixes setzen willst, zeigt KI-Pair-Programming, wie du selbst auf dem Platz des Navigators bleibst. Wenn das alles neu für dich ist, ist Programmieren lernen mit KI ein sanfterer Einstieg.