AI-fix

För ett litet antal SAST-regler vars rättning är snäv och går att kontrollera ber AI-fix din organisations egen AI-modell om en rättning och öppnar en pull request med den. Knappen AI-fix finns på varje SAST-fynd från en sådan regel, under Säkerhet › Fynd › SAST. Inställningen som slår på den är AI-fixar för kodfynd, under Säkerhet › Åtgärda › AI-fix.

AI-fix är bara för kodfynd. Sårbara beroenden och bas-images åtgärdas utan AI, med säkerhetsfixar. Fram till 2026-10-14 hette båda AutoFix; API-sökvägarna .../autofix/..., etiketterna och granskningshändelserna använder fortfarande det namnet.

Bara din egen leverantör, avstängt som standard

• Egen nyckel. Modellen är din organisations egen leverantör under AI-integrationer, som faktureras dig och omfattas av ditt avtal med den leverantören, precis som AI-granskning av pull requests. fremforge har ingen egen AI-nyckel och ingen reserv. Utan en leverantör är AI-fix inaktiverad och säger varför. Med AI-fixar påslagna gäller att om leverantören avvisade din nyckel senast den användes (HTTP 401 eller 403) säger SAST-sidan det, och AI-fixar kan inte köras förrän du uppdaterar nyckeln under AI-integrationer; när du sparar den där testas den igen.
• Avstängt som standard. En ägare slår på AI-fixar för kodfynd under Säkerhet › Åtgärda › AI-fix, eller med PUT .../code-security/autofix/settings och "ai_enabled": true. Funktionen autofix måste också vara påslagen under AI-integrationer: att lägga till en leverantör slår inte på någon AI-funktion av sig själv. Åsidosättningar per repo gäller, liksom dina utgiftstak för AI.
• En person klickar. Inget föreslås automatiskt, inte ens med automatiska säkerhetsfixar påslagna. Varje pull request börjar med att någon klickar på AI-fix på ett fynd, eller anropar API:t för ett fynd.

Vad som skickas till modellen

• regelns publika beskrivning och en instruktion för hur regeln ska rättas;
• högst 60 rader av den berörda filen, från den commit som fyndet togs upp på: raderna runt fyndet, plus filens importblock när det ryms inom de 60;
• filens sökväg och fyndets radnummer.

Aldrig resten av repot, andra filer, issues, text från pull requests eller commit-meddelanden. Koden paketeras som opålitlig data, med en instruktion om att den inte innehåller några instruktioner.

Prompten, koden och diffen loggas inte och lagras inte av fremforge. De finns i minnet medan rättningen förbereds, och därefter bara i pull requesten i ditt repo. Posten för begäran sparar id:n, antal och utfall: vilken regel, vilken leverantör och modell, hur många tokens, hur många rader som ändrades.

Vad som kontrolleras innan en pull request finns

Modellens svar måste vara exakt en unified diff och ett förklarande stycke; allt annat avvisas. Diffen måste sedan klara var och en av de här kontrollerna, som görs av fremforge och inte av modellen:

• en fil: fyndets egen;
• högst 40 ändrade rader, och bara runt fyndet eller i filens importer;
• ingen ändring i CI-konfiguration (.forgejo/, .github/, …), CODEOWNERS, undertryckningsfiler (.trivyignore*, osv-scanner.toml, .gitleaks.toml, .semgrepignore), tester eller beroendemanifest;
• ingen tillagd undertryckningskommentar (nosemgrep, nolint, nosec, noqa, eslint-disable, type: ignore, …);
• inget nytt beroende: en tillagd import måste vara standardbiblioteket eller en modul som filen redan importerar.

Sedan skannas den rättade filen om med samma OpenGrep-binär och regeluppsättning som skanningen av pull requests. Fyndet måste visas i originalfilen (så att ett rent resultat betyder något), vara borta ur den rättade filen, och inget nytt fynd får dyka upp i den. Först då öppnas pull requesten.

Ett försök till promptinjektion i koden kan i värsta fall ge en dålig diff i den enda filen, inom fönstret. Den måste ändå klara kontrollerna ovan, omskanningen, din CI och en persons granskning.

Pull requesten

• Öppnas av din organisations AI-fix-bot, <org>-fremforge-bot-autofix, på en ny branch under autofix-ai/. Boten skriver bara till branches som den själv skapar och kan aldrig godkänna.
• Titeln är fix(security): <rule> in <path>, och etiketterna autofix och ai-generated sätts så snart pull requesten är öppen. En etikett som repot ännu inte har skapas på samma sätt som för säkerhetsfixar: en gång, en befintlig etikett lämnas som den är, och om den inte kan skapas förblir pull requesten öppen utan den.
• Brödtexten namnger fyndet, ger modellens förklaring, leverantören och modellen som användes och de tokens som gick åt, säger hur den kontrollerades och listar vad du ska kontrollera innan merge. Den innehåller upplysningen enligt EU:s AI-förordning art. 50: ett läsbart påstående om att ändringen är AI-genererad, och en maskinläsbar markör fremforge:ai-disclosure som namnger funktionen, leverantören och modellen.
• Aldrig aktiverad för auto-merge, och AI-fix-botens pull requests är inte undantagna från krav på godkännanden: en person granskar och mergar den. En auto-merge som aktiveras på den utan en godkännande granskning avbryts.

Regler som omfattas

Andra regler visar Inte på regellistan för AI-fix: deras fynd behöver en persons omdöme mer än en patch. En regel tas bort från listan om färre än 30 % av dess pull requests mergas.

När ingen pull request öppnas

Fyndet visar då Ingen PR: den föreslagna ändringen klarade inte kontrollerna eller Ingen PR: rättningen kunde inte slutföras, och GET .../code-security/autofix/ai-requests ger orsaken, till exempel scope_ci_config, new_dependency, suppression_comment, rescan_finding_still_present, rescan_new_finding eller ai_over_cap. Du kan be igen efter 10 minuter.

Gränser

• En aktiv begäran per fynd. Be igen efter 10 minuter om en begäran slutade utan pull request.
• Högst 3 öppna pull requests från AI-fix per repo och 20 begäranden om AI-fix per organisation under valfria 24 timmar, som standard.

De här gränserna är AI-fixens egna. De är skilda från gränserna för säkerhetsfixar, som har en egen räknare. En ägare ställer in dem med max_open_per_repo och max_per_org_per_day på PUT .../code-security/autofix/settings (0 till 3 och 0 till 20). Det utfasade anropet ställer också in gränserna för säkerhetsfixar; se Utfasat API.

API

• Begär en AI-fix POST /_app/api/v1/orgs/{org}/code-security/sast/findings/{id}/ai-fix, scope findings:write. Svarar 202 med id för begäran och "automerge": false; pull requesten följer inom några minuter. Ett avslag är problem+json vars type är ai-fix-<reason> och som innehåller reason, till exempel not_curated, ai_disabled eller no_provider. Den äldre sökvägen .../sast/findings/{id}/autofix är utfasad, fortsätter fungera fram till 2027-10-15 och svarar autofix-<reason>.
• Lista AI-begäranden GET /_app/api/v1/orgs/{org}/code-security/autofix/ai-requests, scope findings:read: status, orsak, pull request, leverantör, modell och antal tokens.
• Slå på eller av PUT /_app/api/v1/orgs/{org}/code-security/autofix/settings med "ai_enabled": true eller false (policy:write). ai_provider_configured i GET säger om organisationen har en egen leverantör.

Varje SAST-fynd från GET .../code-security/sast/findings innehåller autofix_eligible, autofix_unavailable_reason och autofix, den senaste begäran om AI-fix som omfattar det.

Granskning

Begäranden om AI-fix finns i granskningsloggen som autofix.proposed, autofix.pr_opened, autofix.rejected, autofix.merged och autofix.closed, med engine: ai, leverantörens id och antal tokens, aldrig prompten eller diffen. Att slå på eller av reglaget registreras som autofix.settings.updated.

Se även

• AI-integrationer: där din organisations egen modelleverantör konfigureras.
• SAST: fynden som knappen sitter på.
• Säkerhetsfixar: rättningar för sårbara beroenden och bas-images, utan AI.
• Regelbaserade fixar: rättningar för fynd av hemligheter och IaC, gjorda av en fast regel, utan AI.