AI-rettelse

For et lille sæt SAST-regler, hvis rettelse er snæver og kan kontrolleres, beder AI-rettelse din organisations egen AI-model om en rettelse og åbner en pull request med den. Knappen AI-rettelse står på hvert SAST-fund fra sådan en regel under Sikkerhed › Fund › SAST. Indstillingen, der slår funktionen til, hedder AI-rettelser til kodefund og ligger under Sikkerhed › Ret › AI-rettelse.

AI-rettelse gælder kun kodefund. Sårbare afhængigheder og base-images rettes uden AI af sikkerhedsrettelser. Indtil 2026-10-14 hed begge AutoFix; API-stierne .../autofix/..., labels og revisionshændelserne bruger stadig det navn.

Kun din egen udbyder, slået fra som standard

• Din egen nøgle. Modellen er din organisations egen udbyder under AI-integrationer, faktureret til dig og under din aftale med den leverandør, præcis som AI-gennemgang af pull requests. fremforge har ingen egen AI-nøgle og intet alternativ at falde tilbage på. Uden en udbyder er AI-rettelse deaktiveret og fortæller hvorfor. Er AI-rettelser slået til, og afviste udbyderen din nøgle, sidste gang den blev brugt (HTTP 401 eller 403), siger SAST-siden det, og AI-rettelser kan ikke køre, før du opdaterer nøglen under AI-integrationer; når du gemmer den der, testes den igen.
• Slået fra som standard. En ejer slår AI-rettelser til kodefund til under Sikkerhed › Ret › AI-rettelse eller med PUT .../code-security/autofix/settings og "ai_enabled": true. Funktionen autofix skal også være slået til under AI-integrationer: at tilføje en udbyder slår ikke i sig selv nogen AI-funktion til. Tilsidesættelser pr. repository gælder, og det gør dine loft over AI-forbrug også.
• En person klikker. Intet foreslås automatisk, heller ikke når automatiske sikkerhedsrettelser er slået til. Hver pull request begynder med, at nogen klikker AI-rettelse på ét fund eller kalder API’et for ét fund.

Hvad der sendes til modellen

• reglens offentlige beskrivelse og en rettelsesinstruks for netop den regel;
• højst 60 linjer af den berørte fil fra det commit, fundet blev rejst på: linjerne omkring fundet plus filens import-blok, når den kan være inden for de 60;
• filstien og fundets linjenummer.

Aldrig resten af repositoriet, andre filer, issues, tekst fra pull requests eller commit-beskeder. Koden pakkes ind som data, der ikke er til at stole på, med en instruks om, at den ikke indeholder instrukser.

Prompten, koden og diffen bliver hverken logget eller gemt af fremforge. De findes i hukommelsen, mens rettelsen forberedes, og bagefter kun i pull requesten i dit repository. Registreringen af anmodningen gemmer id’er, antal og udfaldet: hvilken regel, hvilken udbyder og model, hvor mange tokens og hvor mange ændrede linjer.

Hvad der kontrolleres, før en pull request findes

Modellens svar skal være præcis én unified diff og ét forklarende afsnit; alt andet afvises. Diffen skal derefter bestå hver eneste af disse kontroller, som fremforge foretager, ikke modellen:

• én fil: fundets egen;
• højst 40 ændrede linjer, og kun omkring fundet eller i filens imports;
• ingen ændring af CI-konfiguration (.forgejo/, .github/, …), CODEOWNERS, undertrykkelsesfiler (.trivyignore*, osv-scanner.toml, .gitleaks.toml, .semgrepignore), tests eller afhængighedsmanifester;
• ingen tilføjet undertrykkelseskommentar (nosemgrep, nolint, nosec, noqa, eslint-disable, type: ignore, …);
• ingen ny afhængighed: en tilføjet import skal være standardbiblioteket eller et modul, filen allerede importerer.

Derefter scannes den rettede fil igen med samme OpenGrep-binær og regelsæt som scanningen af pull requests. Fundet skal vise sig i den oprindelige fil (så et rent resultat betyder noget), være væk fra den rettede fil, og der må ikke opstå noget nyt fund i den. Først da åbnes pull requesten.

Et forsøg på prompt injection i koden kan i værste fald give en dårlig diff i den ene fil inden for vinduet. Den skal stadig bestå kontrollerne ovenfor, den nye scanning, din CI og en persons gennemgang.

Pull requesten

• Åbnes af din organisations bot til AI-rettelser, <org>-fremforge-bot-autofix, på en ny branch under autofix-ai/. Botten skriver kun til branches, den selv opretter, og kan aldrig godkende.
• Titlen er fix(security): <rule> in <path>, og labels autofix og ai-generated sættes på, så snart pull requesten er åben. Et label, som repositoriet endnu ikke har, oprettes på samme måde som for sikkerhedsrettelser: én gang, uden at røre et eksisterende label, og kan det ikke oprettes, forbliver pull requesten åben uden det.
• Beskrivelsen nævner fundet, giver modellens forklaring, den brugte udbyder og model og de forbrugte tokens, fortæller hvordan den er kontrolleret og lister, hvad du bør tjekke før merge. Den indeholder oplysningen efter EU AI Act art. 50: en læsbar erklæring om, at ændringen er AI-genereret, og en maskinlæsbar fremforge:ai-disclosure-markør, der nævner funktionen, leverandøren og modellen.
• Aldrig sat til auto-merge, og pull requests fra botten til AI-rettelser er ikke undtaget fra påkrævede godkendelser: en person gennemgår og merger den. En auto-merge, der sættes på den uden en godkendende gennemgang, annulleres.

Dækkede regler

Andre regler viser Ikke på regellisten for AI-rettelse: deres fund kræver mere en persons vurdering end en patch. En regel tages af listen, hvis under 30 % af dens pull requests bliver merget.

Når der ikke åbnes en pull request

Fundet viser så Ingen PR: den foreslåede ændring bestod ikke kontrollerne eller Ingen PR: rettelsen kunne ikke gennemføres, og GET .../code-security/autofix/ai-requests giver årsagen, for eksempel scope_ci_config, new_dependency, suppression_comment, rescan_finding_still_present, rescan_new_finding eller ai_over_cap. Du kan spørge igen efter 10 minutter.

Grænser

• Én aktiv anmodning pr. fund. Spørg igen efter 10 minutter, hvis en anmodning sluttede uden en pull request.
• Som standard højst 3 åbne pull requests fra AI-rettelse pr. repository og 20 anmodninger om AI-rettelse pr. organisation inden for 24 timer.

Disse grænser tilhører AI-rettelse alene. De er adskilt fra grænserne for sikkerhedsrettelser, som har deres egen tæller. En ejer sætter dem med max_open_per_repo og max_per_org_per_day på PUT .../code-security/autofix/settings (0 til 3 og 0 til 20). Det forældede kald sætter også grænserne for sikkerhedsrettelser; se Forældet API.

API

• Anmod om en AI-rettelse POST /_app/api/v1/orgs/{org}/code-security/sast/findings/{id}/ai-fix, scope findings:write. Svarer 202 med anmodningens id og "automerge": false; pull requesten følger inden for få minutter. En afvisning er problem+json, hvis type er ai-fix-<reason>, og som indeholder reason, for eksempel not_curated, ai_disabled eller no_provider. Den ældre sti .../sast/findings/{id}/autofix er forældet, virker indtil 2027-10-15 og svarer autofix-<reason>.
• List AI-anmodninger GET /_app/api/v1/orgs/{org}/code-security/autofix/ai-requests, scope findings:read: status, årsag, pull request, udbyder, model og antal tokens.
• Slå til eller fra PUT /_app/api/v1/orgs/{org}/code-security/autofix/settings med "ai_enabled": true eller false (policy:write). ai_provider_configured i GET fortæller, om organisationen har sin egen udbyder.

Hvert SAST-fund fra GET .../code-security/sast/findings har autofix_eligible, autofix_unavailable_reason og autofix, den seneste anmodning om AI-rettelse, der dækker det.

Revision

Anmodninger om AI-rettelse står i revisionsloggen som autofix.proposed, autofix.pr_opened, autofix.rejected, autofix.merged og autofix.closed med engine: ai, udbyderens id og antal tokens, aldrig prompten eller diffen. At slå kontakten til eller fra er autofix.settings.updated.

Se også

• AI-integrationer: hvor din organisations egen modeludbyder konfigureres.
• SAST: de fund, knappen står på.
• Sikkerhedsrettelser: rettelser af sårbare afhængigheder og base-images uden AI.
• Regelbaserede rettelser: rettelser af fund af secrets og i IaC, lavet af en fast regel uden AI.