Zum Hauptinhalt springen

KI-Korrektur

Für eine kleine Gruppe von SAST-Regeln, deren Korrektur eng umrissen und überprüfbar ist, fragt die KI-Korrektur das eigene KI-Modell deiner Organisation nach einer Korrektur und öffnet damit einen Pull Request. Die Schaltfläche KI-Korrektur steht an jedem SAST-Befund einer solchen Regel, unter Sicherheit › Befunde › SAST. Die Einstellung, die sie einschaltet, heißt KI-Korrekturen für Code-Befunde und liegt unter Sicherheit › Beheben › KI-Korrektur.

Die KI-Korrektur ist nur für Code-Befunde gedacht. Verwundbare Abhängigkeiten und Basis-Images werden ohne KI behoben, durch Sicherheitskorrekturen. Bis zum 2026-10-14 hießen beide AutoFix; die API-Pfade .../autofix/..., die Labels und die Audit-Ereignisse tragen noch diesen Namen.

Nur dein eigener Anbieter, standardmäßig aus

  • Eigener Schlüssel. Das Modell ist der eigene Anbieter deiner Organisation unter KI-Integrationen, abgerechnet an dich und unter deinem Vertrag mit diesem Anbieter, genau wie beim KI-Review von Pull Requests. fremforge hält keinen eigenen KI-Schlüssel und hat keinen Ausweichweg. Ohne Anbieter ist KI-Korrektur deaktiviert und nennt den Grund. Sind KI-Korrekturen eingeschaltet und hat der Anbieter deinen Schlüssel bei der letzten Verwendung abgelehnt (HTTP 401 oder 403), zeigt die SAST-Seite das an, und KI-Korrekturen können nicht laufen, bis du den Schlüssel unter KI-Integrationen aktualisierst; beim Speichern dort wird er erneut getestet.
  • Standardmäßig aus. Ein Owner schaltet KI-Korrekturen für Code-Befunde unter Sicherheit › Beheben › KI-Korrektur ein oder mit PUT .../code-security/autofix/settings und "ai_enabled": true. Zusätzlich muss die Funktion autofix unter KI-Integrationen eingeschaltet sein: Das Hinzufügen eines Anbieters schaltet von sich aus keine KI-Funktion ein. Überschreibungen pro Repository gelten, ebenso deine Obergrenzen für KI-Ausgaben.
  • Eine Person klickt. Nichts wird automatisch vorgeschlagen, auch nicht mit eingeschalteten automatischen Sicherheitskorrekturen. Jeder Pull Request beginnt damit, dass jemand bei einem Befund auf KI-Korrektur klickt oder die API für einen Befund aufruft.

Was an das Modell gesendet wird

  • die öffentliche Beschreibung der Regel und eine Korrekturanweisung für diese Regel;
  • höchstens 60 Zeilen der betroffenen Datei, aus dem Commit, in dem der Befund entstand: die Zeilen rund um den Befund, dazu der Import-Block der Datei, wenn er in die 60 passt;
  • der Dateipfad und die Zeilennummer des Befunds.

Niemals der Rest des Repositorys, andere Dateien, Issues, Pull-Request-Texte oder Commit-Nachrichten. Der Code wird als nicht vertrauenswürdige Daten eingeschlossen, mit der Anweisung, dass er keine Anweisungen enthält.

Prompt, Code und Diff werden von fremforge weder protokolliert noch gespeichert. Sie existieren im Speicher, während die Korrektur vorbereitet wird, und danach nur im Pull Request in deinem Repository. Der Datensatz der Anforderung enthält IDs, Zählwerte und das Ergebnis: welche Regel, welcher Anbieter und welches Modell, wie viele Tokens, wie viele geänderte Zeilen.

Was geprüft wird, bevor ein Pull Request entsteht

Die Antwort des Modells muss genau aus einem Unified Diff und einem Absatz Erklärung bestehen; alles andere wird abgewiesen. Danach muss der Diff jede dieser Prüfungen bestehen, durchgeführt von fremforge und nicht vom Modell:

  • eine Datei: die des Befunds selbst;
  • höchstens 40 geänderte Zeilen, und nur rund um den Befund oder in den Imports der Datei;
  • keine Änderung an der CI-Konfiguration (.forgejo/, .github/, …), an CODEOWNERS, an Unterdrückungsdateien (.trivyignore*, osv-scanner.toml, .gitleaks.toml, .semgrepignore), an Tests oder an Abhängigkeitsmanifesten;
  • kein hinzugefügter Unterdrückungskommentar (nosemgrep, nolint, nosec, noqa, eslint-disable, type: ignore, …);
  • keine neue Abhängigkeit: Ein hinzugefügter Import muss aus der Standardbibliothek stammen oder ein Modul sein, das die Datei bereits importiert.

Anschließend wird die gepatchte Datei mit demselben OpenGrep-Binary und demselben Regelsatz wie beim Pull-Request-Scan erneut gescannt. Der Befund muss in der Originaldatei auftauchen (damit ein sauberes Ergebnis etwas bedeutet), in der gepatchten Datei verschwunden sein, und es darf kein neuer Befund darin erscheinen. Erst dann wird der Pull Request geöffnet.

Ein Prompt-Injection-Versuch im Code kann schlimmstenfalls einen schlechten Diff in dieser einen Datei erzeugen, innerhalb des Ausschnitts. Er muss trotzdem die obigen Prüfungen, den erneuten Scan, deine CI und das Review einer Person bestehen.

Der Pull Request

  • Geöffnet vom KI-Korrektur-Bot deiner Organisation, <org>-fremforge-bot-autofix, auf einem neuen Branch unter autofix-ai/. Der Bot schreibt nur in Branches, die er selbst anlegt, und kann niemals genehmigen.
  • Titel fix(security): <rule> in <path>, Labels autofix und ai-generated, angehängt, sobald der Pull Request offen ist. Ein Label, das es im Repository noch nicht gibt, wird so angelegt wie bei Sicherheitskorrekturen: einmalig, ein bestehendes Label bleibt unverändert, und lässt es sich nicht anlegen, bleibt der Pull Request ohne dieses Label offen.
  • Die Beschreibung nennt den Befund, gibt die Erklärung des Modells, den verwendeten Anbieter und das Modell sowie die verbrauchten Tokens an, sagt, wie geprüft wurde, und listet, was vor dem Mergen zu prüfen ist. Sie enthält die Offenlegung nach Art. 50 der EU-KI-Verordnung: einen lesbaren Hinweis, dass die Änderung KI-generiert ist, und eine maschinenlesbare Markierung fremforge:ai-disclosure, die Funktion, Anbieter und Modell nennt.
  • Nie für Auto-Merge vorgemerkt, und die Pull Requests des KI-Korrektur-Bots sind nicht von erforderlichen Genehmigungen ausgenommen: Eine Person prüft und mergt ihn. Ein Auto-Merge, der ohne genehmigendes Review darauf vorgemerkt wird, wird abgebrochen.

Abgedeckte Regeln

RegelSpracheDie Korrektur
SQL-Stringverkettung (go_sql_rule-concat-sqli)GoEine parametrisierte Abfrage
Zu weit gefasste Dateiberechtigungen (go_file-permissions_rule-fileperm, -mkdir)GoEin engerer Modus
HTTP-Server ohne Timeouts (go_http_rule-http-serve)GoEin http.Server mit ReadHeaderTimeout
SQL-Stringverkettung (python_sql_rule-hardcoded-sql-expression)PythonEine parametrisierte Abfrage
Unsicheres XML-Parsing (python_xml_rule-element, python_xml_rule-etree)Pythondefusedxml, nur wenn die Datei es bereits importiert
Zu weit gefasste Dateiberechtigungen (python_file-permissions_rule-general-bad-permission)PythonEin engerer Modus
Nicht-literale RegExp (javascript_dos_rule-non-literal-regexp)JavaScript, TypeScriptEine String-Operation oder literale Muster

Andere Regeln zeigen Nicht auf der Regelliste der KI-Korrektur: Ihre Befunde brauchen eher das Urteil einer Person als einen Patch. Eine Regel fällt von der Liste, wenn weniger als 30 % ihrer Pull Requests gemergt werden.

Wenn kein Pull Request geöffnet wird

Der Befund zeigt dann Kein PR: Die vorgeschlagene Änderung hat die Prüfungen nicht bestanden oder Kein PR: Die Korrektur konnte nicht abgeschlossen werden, und GET .../code-security/autofix/ai-requests liefert den Grund, zum Beispiel scope_ci_config, new_dependency, suppression_comment, rescan_finding_still_present, rescan_new_finding oder ai_over_cap. Nach 10 Minuten kannst du erneut anfragen.

Grenzen

  • Eine laufende Anforderung pro Befund. Endete eine Anforderung ohne Pull Request, frag nach 10 Minuten erneut an.
  • Standardmäßig höchstens 3 offene Pull Requests der KI-Korrektur pro Repository und 20 Anforderungen der KI-Korrektur pro Organisation innerhalb von 24 Stunden.

Diese Grenzen gehören der KI-Korrektur allein. Sie sind getrennt von den Grenzen der Sicherheitskorrekturen, die einen eigenen Zähler haben. Ein Owner setzt sie mit max_open_per_repo und max_per_org_per_day über PUT .../code-security/autofix/settings (0 bis 3 und 0 bis 20). Dieser veraltete Aufruf setzt auch die Grenzen der Sicherheitskorrekturen; siehe Veraltete API.

API

  • Eine KI-Korrektur anfordern POST /_app/api/v1/orgs/{org}/code-security/sast/findings/{id}/ai-fix, Scope findings:write. Antwortet mit 202, der ID der Anforderung und "automerge": false; der Pull Request folgt innerhalb weniger Minuten. Eine Ablehnung ist problem+json, deren type ai-fix-<reason> ist und die reason enthält, zum Beispiel not_curated, ai_disabled oder no_provider. Der ältere Pfad .../sast/findings/{id}/autofix ist veraltet, funktioniert bis 2027-10-15 weiter und antwortet mit autofix-<reason>.
  • KI-Anforderungen auflisten GET /_app/api/v1/orgs/{org}/code-security/autofix/ai-requests, Scope findings:read: Status, Grund, Pull Request, Anbieter, Modell und Token-Zahlen.
  • Ein- oder ausschalten PUT /_app/api/v1/orgs/{org}/code-security/autofix/settings mit "ai_enabled": true oder false (policy:write). ai_provider_configured im GET gibt an, ob die Organisation einen eigenen Anbieter hat.

Jeder SAST-Befund aus GET .../code-security/sast/findings enthält autofix_eligible, autofix_unavailable_reason und autofix, die jüngste Anforderung der KI-Korrektur, die ihn abdeckt.

Audit

Anforderungen der KI-Korrektur stehen im Audit-Log als autofix.proposed, autofix.pr_opened, autofix.rejected, autofix.merged und autofix.closed, mit engine: ai, der Anbieter-ID und den Token-Zahlen, nie mit dem Prompt oder dem Diff. Das Ein- oder Ausschalten ist autofix.settings.updated.

Siehe auch

Image-ScanningKomponenteninventar