KI-Coding-Agent-Workflows absichern: Sandbox, Berechtigungen und Review für KI-generierten Code in Produktions-Pipelines

KI-Coding-Agenten schreiben Produktionscode im großen Maßstab. Branchenumfragen beziffern die Adoption auf 84% unter professionellen Entwicklern, und diese Zahl steigt. GitHub Copilot, Claude Code, Cursor, Amazon Q Developer und eine wachsende Reihe agentischer Tools generieren inzwischen alles von Boilerplate-Hilfsfunktionen bis hin zu vollständigen Feature-Implementierungen. Die Geschwindigkeitsgewinne sind real. Die Governance-Lücke ist ebenfalls real.

Die meisten Teams haben KI-Coding-Agenten eingeführt, aber keine Governance für KI-Coding-Agenten. Die Tools lieferten schneller als die Richtlinien. Das Ergebnis ist, dass KI-generierter Code durch dieselben Pull-Request-Workflows in die Produktion fließt, die für menschlich geschriebenen Code entworfen wurden, aber ohne dieselbe Prüfung. Menschliche Reviewer überfliegen KI-generierte PRs oft, weil sie annehmen, die KI habe es „richtig gemacht”, oder weil das Volumen KI-generierter Änderungen ihre Review-Kapazität übersteigt. Die Absicherung von KI-Coding-Agent-Workflows erfordert, KI-generierte PRs als eigene Vertrauensstufe zu behandeln, mit eigenen Erkennungsmechanismen, Richtlinienbeschränkungen, automatisierten Scans und Review-Gates.

Es geht nicht darum, Dinge zu verlangsamen. Es geht darum, eine Governance-Schicht aufzubauen, die der Geschwindigkeit und dem Maßstab entspricht, in dem KI-Agenten arbeiten. Teams, die das richtig machen, bewegen sich schneller, weil sie Vertrauen in ihr Sicherheitsnetz haben. Teams, die es überspringen, sammeln Risiko an, bis etwas in der Produktion bricht.

Bedrohungsmodell für KI-generierten Code

Bevor Sie Kontrollen aufbauen, müssen Sie verstehen, was schiefgehen kann. KI-generierter Code bringt eine spezifische Reihe von Risiken mit sich, die sich von den Bugs und Schwachstellen unterscheiden, die Menschen typischerweise erzeugen.

Geheimnisleckage. KI-Agenten können versehentlich API-Keys, Tokens oder Zugangsdaten in generierten Code einbinden. Sie können Muster aus Trainingsdaten kopieren, die Platzhalter-Geheimnisse enthalten, oder sie können Geheimnisse aus dem Kontextfenster (Dateien, die der Agent während seiner Sitzung gelesen hat) ziehen und in neuem Code einbetten. Anders als ein Mensch, der weiß, welche Strings sensibel sind, behandelt ein Agent allen Kontext als potenzielles Material.

Abhängigkeitsrisiken. Agenten schlagen häufig Pakete vor, die sie in Trainingsdaten gesehen haben, einschließlich Pakete, die veraltet, nicht mehr gepflegt oder bekannte Schwachstellen haben. Sie können auch Paketnamen halluzinieren, die nicht existieren, was eine Gelegenheit für Dependency-Confusion-Angriffe schafft, bei denen ein Angreifer ein bösartiges Paket unter dem halluzinierten Namen veröffentlicht.

Logikfehler im Maßstab. Ein menschlicher Entwickler, der einen subtilen Logikfehler schreibt, produziert eine Instanz. Ein KI-Agent, der dasselbe fehlerhafte Muster über zwanzig Dateien anwendet, produziert zwanzig Instanzen. Die Geschwindigkeit, die Agenten nützlich macht, verstärkt auch die Auswirkung systematischer Fehler.

Berechtigungsschleichung. Agenten neigen dazu, breite Berechtigungen anzufordern, wenn engere ausreichen würden. Ein Agent, der eine Datenbankmigration schreibt, könnte ALTER TABLE- und DROP TABLE-Privilegien hinzufügen, obwohl er nur CREATE TABLE braucht. Ein Agent, der eine IAM-Rolle konfiguriert, könnte AdministratorAccess anhängen, weil es den unmittelbaren Berechtigungsfehler löst, ohne den Schadensradius zu verstehen.

Supply-Chain-Injection. Wenn der Kontext eines Agenten durch externe Eingaben beeinflusst werden kann, sei es durch Prompt Injection in Dokumentation, die er liest, vergiftete Repository-Dateien oder kompromittierte MCP-Server, kann der generierte Code absichtlich bösartige Payloads enthalten. Das ist nicht theoretisch. Forschung hat Prompt-Injection-Angriffe demonstriert, die Agenten dazu bringen, Backdoors in generierten Code einzubauen.

Für eine breitere Behandlung der Bedrohungslandschaft siehe unseren Leitfaden zur Absicherung agentischer KI-Anwendungen. Für Supply-Chain-Risiken speziell siehe Software-Lieferkettensicherheit im Zeitalter der KI.

Die vier Schichten der KI-Code-Governance

Effektive Governance für KI-generierten Code arbeitet auf vier Schichten, wobei jede einen anderen Teil des Problems adressiert. Überspringen Sie eine Schicht, und Sie haben eine Lücke, die die anderen Schichten nicht kompensieren können.

Schicht 1: Erkennung

Was man nicht identifizieren kann, kann man nicht regieren. Die erste Anforderung ist die zuverlässige Erkennung, welche PRs, Commits und Codeänderungen von KI-Agenten generiert wurden.

Erkennungsmethoden umfassen:

• Commit-Metadaten: KI-Coding-Agenten fügen typischerweise Co-authored-by-Trailer mit identifizierbaren Mustern hinzu (z.B. Co-Authored-By: Claude <noreply@anthropic.com>). Parsen Sie diese systematisch.
• PR-Labels: Viele agentengesteuerte Workflows fügen automatisch Labels wie ai-generated, copilot oder claude hinzu. Verlangen Sie diese Labels als Teil Ihrer Agentenkonfiguration.
• Bot-Autoren: Wenn Agenten über GitHub Apps oder Bot-Konten arbeiten, identifiziert der PR-Autor selbst die Quelle.
• Branch-Namenskonventionen: Setzen Sie Namensmuster für von Agenten erstellte Branches durch (z.B. ai/feature-name oder agent/ticket-123).

Das Ziel ist eine boolesche Bestimmung auf PR-Ebene: Wurde diese Änderung von einem KI-Agenten produziert? Dieses Flag steuert alles Nachgelagerte. Wenn Ihre Erkennung falsch-negative Ergebnisse hat, umgeht nicht erkannter KI-generierter Code alle Ihre Governance-Kontrollen. Bauen Sie Redundanz in die Erkennung ein, indem Sie mehrere Signale prüfen.

Schicht 2: Richtlinien

Sobald Sie wissen, dass ein PR KI-generiert ist, wenden Sie eine Reihe von Beschränkungen an, die definieren, was der Agent tun durfte. Hier codieren Sie die Risikotoleranz Ihrer Organisation.

Richtlinien beantworten Fragen wie:

• Welche Dateien und Verzeichnisse darf der Agent modifizieren?
• Welche Dateien sind tabu (Authentifizierung, Infrastructure-as-Code, CI/CD-Pipelines)?
• Wie viele Dateien darf ein einzelner KI-PR betreffen?
• Wie viele Codezeilen darf ein einzelner KI-PR hinzufügen oder modifizieren?
• Muss der Agent Tests für jeden Code einschließen, den er schreibt?

Richtlinienverletzungen sind harte Blockaden. Wenn ein KI-generierter PR eine Datei in der blocked_patterns-Liste modifiziert, scheitert der PR an der Governance-Prüfung, unabhängig davon, wie der Code aussieht. Das ist beabsichtigt. Einige Bereiche der Codebasis erfordern menschliche Autorenschaft, nicht weil die KI keinen korrekten Code schreiben kann, sondern weil das Risiko eines unentdeckten Fehlers in diesen Bereichen zu hoch ist.

Schicht 3: Scanning

Automatisiertes Sicherheits-Scanning läuft gegen jeden KI-generierten PR, bevor er zum Review weitergehen kann. Diese Schicht umfasst:

• Geheimnis-Erkennung: Scan auf API-Keys, Tokens, Passwörter und andere Credentials im Diff. Tools wie TruffleHog, GitLeaks und GitHubs eingebautes Secret Scanning fangen die meisten Muster.
• Abhängigkeitsanalyse: Neu hinzugefügte Abhängigkeiten auf bekannte Schwachstellen (CVEs), Lizenzkompatibilitätsprobleme und Wartungsstatus prüfen. Halluzinierte Pakete markieren, die in der Registry nicht existieren.
• Statische Analyse (SAST): Sprachspezifische statische Analyse ausführen, um häufige Schwachstellenmuster wie SQL-Injection, Path Traversal und Cross-Site Scripting zu fangen.
• Infrastructure-as-Code-Scanning: Wenn der PR Terraform-, CloudFormation- oder Docker-Konfiguration modifiziert, Tools wie Checkov oder Trivy ausführen, um Fehlkonfigurationen zu markieren.

Der wichtige Unterschied zum Standard-CI-Sicherheits-Scanning ist, dass die Schwellenwerte für KI-generierten Code strenger sein sollten. Ein mittelgradiger Fund, der bei einem menschlichen PR eine Warnung erzeugen würde, könnte bei einem KI-generierten PR eine harte Blockade erzeugen, weil die Wahrscheinlichkeit höher ist, dass die KI die Schwachstelle eingeführt hat, ohne die Auswirkungen zu verstehen, als bei einem Menschen, der sich bewusst entschieden hat, das Risiko zu akzeptieren.

Schicht 4: Review

Die letzte Schicht ist menschliches Review, aber anders strukturiert für KI-generierten Code. Anstelle der Standard-Regel „eine Genehmigung” durchlaufen KI-generierte PRs einen risikostufenbasierten Review-Prozess.

Ein Risiko-Score wird basierend auf Faktoren berechnet wie:

• Anzahl der geänderten Dateien
• Welche Verzeichnisse und Dateitypen betroffen sind
• Ob der PR sicherheitssensible Bereiche modifiziert
• Ob Scanning Warnungen gefunden hat (auch nicht-blockierende)
• Größe und Komplexität des Diffs

Änderungen mit geringem Risiko (kleiner Scope, nicht-sensible Dateien, saubere Scans) können automatisch gemergt werden. Änderungen mit mittlerem Risiko erfordern eine menschliche Genehmigung. Änderungen mit hohem Risiko erfordern zwei Genehmigungen einschließlich jemand aus dem Sicherheitsteam. Diese Staffelung ermöglicht Geschwindigkeit für die 70% der KI-generierten Änderungen, die wirklich risikoarm sind, während Review-Aufwand dort konzentriert wird, wo er zählt.

Policy-as-Code für KI-Agenten

Die oben beschriebenen Governance-Schichten brauchen eine konkrete Implementierung. Der empfohlene Ansatz ist eine deklarative Konfigurationsdatei, die im Repository neben dem Code lebt, den sie regiert. Wir nennen diese Datei .ai-code-gate.yml.

detection:
  labels: ["ai-generated", "copilot", "claude"]
  co_authors: ["*[bot]@*", "*noreply@anthropic.com"]

policy:
  allowed_patterns:
    - "src/**/*.ts"
    - "src/**/*.tsx"
    - "tests/**"
  blocked_patterns:
    - "*.env*"
    - "**/auth/**"
    - "docker-compose*.yml"
    - ".github/workflows/**"
  scope_limits:
    max_files: 20
    max_lines_added: 500

review:
  risk_tiers:
    low:
      threshold: 30
      approvals: 0
      auto_merge: true
    medium:
      threshold: 70
      approvals: 1
    high:
      threshold: 100
      approvals: 2
      require_security_team: true

Diese Konfiguration codiert die Richtlinien Ihrer Organisation als strukturierte Daten, die Ihre CI/CD-Pipeline automatisch durchsetzen kann. Gehen wir jeden Abschnitt durch.

Erkennungsregeln

Der detection-Block definiert, wie die Pipeline KI-generierte PRs identifiziert. Er prüft PR-Labels und Commit-Co-authored-by-Trailer gegen von Ihnen definierte Muster. Glob-artige Wildcards ermöglichen breite Musterübereinstimmung, ohne eine erschöpfende Liste jeder Bot-E-Mail-Adresse zu pflegen. Wenn ein Erkennungssignal übereinstimmt, wird der PR als KI-generiert markiert und die verbleibenden Governance-Prüfungen greifen.

Erlaubte und blockierte Muster

Die allowed_patterns-Liste ist eine Whitelist von Dateipfaden, die der Agent modifizieren darf. Die blocked_patterns-Liste ist eine Blacklist, die Vorrang hat. Wenn eine Datei beiden entspricht, gewinnt die Blockade.

Das ist konzeptionell ähnlich einer CODEOWNERS-Datei, dient aber einem anderen Zweck. CODEOWNERS kontrolliert, wer eine Änderung reviewen muss. .ai-code-gate.yml kontrolliert, ob die Änderung überhaupt existieren darf. Ein KI-Agent könnte von der Modifizierung von .github/workflows/ blockiert werden, unabhängig davon, wer es reviewt, weil Modifikationen an CI/CD-Pipelines durch eine KI zu viel Risiko für die Toleranz Ihrer Organisation einführen.

Scope-Limits

Der scope_limits-Abschnitt begrenzt die Größe KI-generierter PRs. Ein Limit von 20 Dateien und 500 hinzugefügten Zeilen zwingt Agenten (und die Menschen, die sie konfigurieren), große Änderungen in reviewbare Stücke zu brechen. Das ist eine Leitplanke gegen das häufige Muster, bei dem ein Agent gebeten wird, „das Authentifizierungsmodul zu refaktorisieren” und einen 2.000-Zeilen-PR produziert, den niemand tatsächlich reviewt, weil er zu groß ist, um darüber nachzudenken.

Risikostufen

Der review-Abschnitt definiert drei Stufen basierend auf einem berechneten Risiko-Score (0-100). Die Score-Berechnung berücksichtigt Dateianzahl, Diff-Größe, welche Verzeichnisse berührt werden und Scan-Ergebnisse. PRs mit geringem Risiko werden automatisch gemergt, wenn Scans sauber sind. PRs mit mittlerem Risiko brauchen eine Genehmigung. PRs mit hohem Risiko brauchen zwei Genehmigungen und jemanden aus dem Sicherheitsteam.

Diese Schwellenwerte sind anpassbar. Starten Sie konservativ und passen Sie an, wenn Sie Vertrauen in Ihre Erkennungs- und Scanning-Schichten aufbauen. Die meisten Teams stellen fest, dass 60-70% der KI-generierten PRs nach einigen Wochen Tuning in die Niedrigrisiko-Stufe fallen, was bedeutet, dass Governance für die Mehrheit der Änderungen fast keine Reibung hinzufügt.

Sandbox-Ausführung

Statische Analyse fängt viel, aber nicht alles. Einige Klassen von Bugs zeigen sich nur zur Laufzeit: Missbrauch von Umgebungsvariablen, falsche API-Aufrufsequenzen, Race Conditions, kaputte Integrationen. Sandbox-Ausführung gibt Ihnen eine Möglichkeit, KI-generierten Code vor dem Mergen auszuführen, ohne Ihre Produktionsumgebung oder CI-Infrastruktur zu exponieren.

Warum Code vor dem Mergen ausführen

Das traditionelle Modell ist, Code zu mergen und dann in einer Staging-Umgebung auszuführen. Für KI-generierten Code wollen Sie das nach links verschieben. Code in einer Sandbox vor dem Merge auszuführen gibt Ihnen ein Signal über Laufzeitverhalten, das kein statisches Analysetool bieten kann. Startet der Code tatsächlich? Laufen die Tests? Versucht er, unerwartete Netzwerkaufrufe zu machen? Verbraucht er übermäßig Speicher oder CPU?

Container-basierte Sandboxes

Der praktischste Ansatz ist, KI-generierten Code in isolierten Docker-Containern mit eingeschränkten Fähigkeiten auszuführen:

• Isoliertes Dateisystem: Der Container erhält eine Kopie des Repositorys mit den angewandten PR-Änderungen, kann aber nicht auf den Host zurückschreiben oder auf andere Repositories zugreifen.
• Netzwerkeinschränkungen: Der Container hat keinen ausgehenden Netzwerkzugang oder Zugang beschränkt auf spezifische interne Endpunkte, die für Tests benötigt werden.
• Ressourcenlimits: CPU, Speicher und Ausführungszeit sind begrenzt. Wenn der KI-generierte Code eine Endlosschleife oder ein Speicherleck enthält, wird der Container nach dem Timeout beendet.
• Kein privilegierter Zugriff: Der Container läuft ohne Root-Privilegien und ohne Zugang zum Docker-Socket.

Ansätze im Vergleich

Mehrere Ansätze existieren für Sandbox-Ausführung, jeweils mit unterschiedlichen Trade-offs:

• Docker-basiert (DIY): Sie verwalten eigene Container-Images, Sicherheitskonfiguration und Bereinigung. Maximale Kontrolle, meister operativer Overhead.
• E2B: Ein verwalteter Dienst, der Sandbox-Umgebungen für KI-Agent-Codeausführung bereitstellt. Geringerer operativer Overhead, fügt aber eine externe Abhängigkeit und Kosten hinzu.
• Kubernetes Jobs: Ephemere Pods mit Security Contexts, Network Policies und Resource Quotas. Gut für Teams, die bereits Kubernetes betreiben.

Für die meisten Teams sind Docker-basierte Sandboxes in ihrer bestehenden CI-Infrastruktur der richtige Startpunkt.

Der Audit-Trail

Jede Governance-Entscheidung braucht eine Aufzeichnung. Wenn in sechs Monaten ein Vorfall eintritt und Sie verstehen müssen, wie ein Stück KI-generierter Code in die Produktion gelangt ist, müssen Sie die vollständige Kette rekonstruieren: wer den Agenten ausgelöst hat, welcher Prompt verwendet wurde, welcher Code generiert wurde, welche Scans liefen, was die Ergebnisse waren, wer genehmigt hat und wann es gemergt wurde.

Was protokolliert werden sollte

Ein vollständiger Audit-Trail für KI-generierten Code umfasst:

• Auslösendes Event: Wer die Agentensitzung initiiert hat, welches Ticket oder welche Aufgabe referenziert wurde, was die ursprüngliche Anweisung war
• Generierungskontext: Welches Modell verwendet wurde, welche Dateien der Agent als Kontext gelesen hat, welche Tools der Agent während der Generierung aufgerufen hat
• Code-Diff: Die genauen Änderungen, die der Agent produziert hat, als versioniertes Artefakt gespeichert
• Erkennungsergebnis: Wie der PR als KI-generiert identifiziert wurde, welche Signale übereinstimmten
• Richtlinienprüfungsergebnis: Welche Muster evaluiert wurden, ob Verletzungen gefunden wurden
• Scan-Ergebnisse: Vollständige Ausgabe von Geheimnis-Erkennung, Abhängigkeitsanalyse, SAST und anderen Scannern
• Risiko-Score: Der berechnete Score, die Faktoren, die dazu beigetragen haben, und die resultierende Stufenzuweisung
• Review-Entscheidungen: Wer reviewt hat, wann, welche Kommentare gemacht wurden, ob ein Review überstimmt wurde
• Merge-Event: Wann der Code gemergt wurde, von wem, in welchen Branch

Compliance-Relevanz

Wenn Ihre Organisation unter SOC 2, ISO 27001, FedRAMP oder ähnlichen Compliance-Frameworks arbeitet, erzeugt KI-generierter Code spezifische Dokumentationsanforderungen. Auditoren werden fragen, wie Sie sicherstellen, dass KI-generierter Code denselben Sicherheitsstandards wie menschlich geschriebener Code entspricht. Einen strukturierten Audit-Trail zu haben, der Erkennung, Richtliniendurchsetzung, Scanning und Review demonstriert, ist der Unterschied zwischen einem reibungslosen Audit und einem Finding.

Die OWASP Top 10 für agentische Anwendungen listet unzureichendes Logging und Monitoring als Top-Risiko für agentische Systeme. Der OpenSSF AI Code Assistant Security Guide betont ebenfalls Audit-Trails als grundlegende Kontrolle.

Die ai-code-gate-Referenzimplementierung

Um das Governance-Framework konkret und sofort nutzbar zu machen, haben wir ai-code-gate gebaut, eine Referenzimplementierung, die Sie in jedes GitHub-Repository installieren können.

Repository-Struktur

Das Repo ist als Satz von GitHub Actions Composite Actions organisiert, die zu einer vollständigen Governance-Pipeline verkettet werden:

ai-code-gate/
  .github/
    actions/
      detect-ai-pr/    # KI-generierte PRs identifizieren
      policy-check/    # Datei- und Scope-Richtlinien durchsetzen
      security-scan/   # Geheimnis-, Abhängigkeits- und SAST-Scans
      sandbox-test/    # Tests in isoliertem Docker-Container
      risk-assessment/ # Risiko-Score berechnen und Stufe zuweisen
    workflows/
      ai-code-gate.yml # Haupt-Workflow, der alle Actions verkettet
  src/
    detect.ts          # KI-PR-Erkennungs-Engine
    policy.ts          # Richtlinien-Laden und Diff-Validierung
    risk.ts            # Risikobewertung und Stufenzuweisung
  examples/
    .ai-code-gate.yml  # Standard-Konfiguration für Anwender
  sample-app/          # Demo-Express-API zum Testen der Pipeline
  .ai-code-gate.yml    # Richtlinien für dieses Repo selbst
  README.md

Risikobewertung

Der Risikokalkulator bewertet mehrere Faktoren und erzeugt einen gewichteten Score von 0 bis 100:

interface RiskFactors {
  filesChanged: number;
  linesAdded: number;
  sensitivePathsModified: string[];
  newDependenciesAdded: number;
  scanFindings: ScanFinding[];
  hasTests: boolean;
}

function calculateRiskScore(factors: RiskFactors): number {
  let score = 0;
  score += Math.min(20, factors.filesChanged * 2);
  score += Math.min(20, Math.floor(factors.linesAdded / 50));
  score += factors.sensitivePathsModified.length * 15;
  score += factors.newDependenciesAdded * 5;
  for (const finding of factors.scanFindings) {
    score += finding.severity === "high" ? 20 : finding.severity === "medium" ? 10 : 5;
  }
  if (factors.hasTests) {
    score = Math.max(0, score - 10);
  }
  return Math.min(100, score);
}

Schrittweise Adoption

Sie müssen nicht alle fünf Actions auf einmal deployen. Der empfohlene Adoptionspfad:

1. Woche 1: Nur Erkennung deployen. KI-generierte PRs labeln, aber keine blockierende Aktion.
2. Woche 2: Richtlinienprüfungen im Warnmodus hinzufügen. Verletzungen in PR-Kommentaren markieren, aber Merge nicht blockieren.
3. Woche 3: Sicherheits-Scanning hinzufügen. Wieder nur Ergebnisse melden.
4. Woche 4: Blockiermodus für Richtlinienverletzungen und hochgradige Scan-Funde aktivieren.
5. Woche 5+: Risikostufenbasierte Review-Gates aktivieren. Schwellenwerte basierend auf beobachteten Daten tunen.

Wie es weitergeht

Wenn Sie dieses Framework hands-on implementieren möchten, folgen Sie dem Begleittutorial: KI-Coding-Agent-Pipelines absichern. Es führt durch die Installation von ai-code-gate, die Konfiguration von Richtlinien für Ihre Codebasis und die Validierung jeder Governance-Schicht mit Test-PRs.

Für mehr zu den in diesem Leitfaden behandelten Themen:

• KI-Coding-Agenten im Jahr 2026: Wie MCP und tool-erweiterte Modelle die Entwicklung verändern behandelt die Fähigkeiten und Architektur moderner KI-Coding-Agenten.
• Wie man agentische KI-Anwendungen absichert: Das Playbook für 2026 bietet ein breiteres Sicherheits-Framework für KI-gestützte Systeme.
• Software-Lieferkettensicherheit im Zeitalter der KI adressiert Abhängigkeits- und Build-Pipeline-Risiken.
• Härten Sie Ihre CI/CD-Pipeline mit Sigstore, SLSA und SBOMs behandelt ergänzende CI/CD-Härtungstechniken.

Holen Sie sich die AI Code Gate Pipeline →

Holen Sie sich die kostenlose KI-Code-Governance-Checkliste →

Häufig gestellte Fragen

Wie erkennt man KI-generierte Pull Requests?

Die Erkennung nutzt mehrere geschichtete Signale: Co-authored-by-Commit-Trailer von Tools wie GitHub Copilot und Claude Code, PR-Labels wie ai-generated oder copilot, bekannte Bot-Autorenkonten und Branch-Namenskonventionen wie copilot/- oder claude/-Präfixe. Die Kombination dieser Signale reduziert falsch-negative Ergebnisse. Der Erkennungsschritt läuft zuerst in der Pipeline und steuert, ob die verbleibenden KI-spezifischen Prüfungen ausgelöst werden.

Worauf sollte man KI-generierten Code scannen?

KI-generierter Code sollte auf vier Kategorien gescannt werden: Geheimnisse und Zugangsdaten (mit Tools wie Gitleaks), Abhängigkeitsschwachstellen und halluzinierte Paketnamen (mit npm audit, pip-audit oder ähnlichem), statische Analysefunde (mit Semgrep oder ähnlichen SAST-Tools) und Infrastructure-as-Code-Fehlkonfigurationen (für Terraform, CloudFormation oder Dockerfiles). Schwellenwerte für KI-generierten Code sollten strenger sein als für menschlich geschriebenen Code, weil Volumen und Geschwindigkeit des KI-Outputs die Auswirkung systematischer Fehler verstärkt.

Wie funktionieren risikostufenbasierte Review-Gates?

Risikostufenbasierte Review-Gates weisen jedem KI-generierten Pull Request einen zusammengesetzten Risiko-Score zu, basierend auf Faktoren wie der Anzahl geänderter Dateien, ob sensible Pfade berührt werden, Sicherheits-Scan-Funden und Richtlinienverletzungen. Der Score wird einer Stufe zugeordnet: PRs mit geringem Risiko können nach Bestehen aller Scans automatisch gemergt werden, PRs mit mittlerem Risiko brauchen eine menschliche Genehmigung, und PRs mit hohem Risiko brauchen zwei Genehmigungen einschließlich eines Sicherheitsreviewers. Die Stufenschwellenwerte und Bewertungsgewichte sind in der Richtliniendatei konfigurierbar.