AI-rettelse

For et lite sett SAST-regler der rettelsen er avgrenset og kan kontrolleres, ber AI-rettelse organisasjonens egen AI-modell om en rettelse og åpner en pull request med den. Knappen AI-rettelse står på hvert SAST-funn fra en slik regel, under Sikkerhet › Funn › SAST. Innstillingen som slår den på, heter AI-rettelser for kodefunn og ligger under Sikkerhet › Utbedre › AI-rettelse.

AI-rettelse gjelder bare kodefunn. Sårbare avhengigheter og base-imager rettes uten AI, av sikkerhetsrettelser. Fram til 2026-10-14 het begge AutoFix; API-stiene .../autofix/..., etikettene og revisjonshendelsene bruker fortsatt det navnet.

Bare din egen leverandør, av som standard

• Ta med din egen nøkkel. Modellen er organisasjonens egen leverandør under AI-integrasjoner, fakturert til deg og under din avtale med den leverandøren, akkurat som AI-gjennomgang av pull requests. fremforge har ingen egen AI-nøkkel og ingen reserveløsning. Uten en leverandør er AI-rettelse deaktivert og forteller hvorfor. Er AI-rettelser slått på og leverandøren avviste nøkkelen din sist den ble brukt (HTTP 401 eller 403), sier SAST-siden det, og AI-rettelser kan ikke kjøre før du oppdaterer nøkkelen under AI-integrasjoner; når du lagrer den der, testes den på nytt.
• Av som standard. En eier slår på AI-rettelser for kodefunn under Sikkerhet › Utbedre › AI-rettelse, eller med PUT .../code-security/autofix/settings og "ai_enabled": true. Funksjonen autofix må også være slått på under AI-integrasjoner: å legge til en leverandør slår ikke på noen AI-funksjon av seg selv. Overstyringer per repository gjelder, det samme gjør utgiftstakene dine for AI.
• En person klikker. Ingenting foreslås automatisk, heller ikke med automatiske sikkerhetsrettelser slått på. Hver pull request starter med at noen klikker AI-rettelse på ett funn, eller kaller API-et for ett funn.

Hva som sendes til modellen

• regelens offentlige beskrivelse og en instruks for hvordan regelen rettes;
• høyst 60 linjer fra den berørte filen, fra commiten funnet ble meldt på: linjene rundt funnet, pluss filens importblokk når den får plass innenfor de 60;
• filstien og linjenummeret til funnet.

Aldri resten av repositoryet, andre filer, issues, tekst fra pull requests eller commit-meldinger. Koden pakkes inn som upålitelige data, med en instruks om at den ikke inneholder instrukser.

Prompten, koden og diffen blir verken logget eller lagret av fremforge. De finnes i minnet mens rettelsen forberedes, og etterpå bare i pull requesten i repositoryet ditt. Oppføringen av forespørselen beholder id-er, antall og utfallet: hvilken regel, hvilken leverandør og modell, hvor mange tokener, hvor mange linjer som ble endret.

Hva som sjekkes før det finnes en pull request

Svaret fra modellen må være nøyaktig én unified diff og ett avsnitt med forklaring; alt annet avvises. Diffen må deretter bestå hver eneste av disse sjekkene, som utføres av fremforge og ikke av modellen:

• én fil: funnets egen;
• høyst 40 endrede linjer, og bare rundt funnet eller i filens importer;
• ingen endring i CI-konfigurasjon (.forgejo/, .github/, …), CODEOWNERS, undertrykkingsfiler (.trivyignore*, osv-scanner.toml, .gitleaks.toml, .semgrepignore), tester eller avhengighetsmanifester;
• ingen ny undertrykkingskommentar (nosemgrep, nolint, nosec, noqa, eslint-disable, type: ignore, …);
• ingen ny avhengighet: en ny import må være standardbiblioteket eller en modul filen allerede importerer.

Deretter skannes den patchede filen på nytt med den samme OpenGrep-binærfilen og det samme regelsettet som skanningen av pull requests. Funnet må dukke opp i den opprinnelige filen (slik at et rent resultat betyr noe), være borte fra den patchede filen, og ingen nye funn kan dukke opp i den. Først da åpnes pull requesten.

Et forsøk på prompt-injeksjon i koden kan i verste fall gi en dårlig diff i den ene filen, innenfor vinduet. Den må fortsatt bestå sjekkene over, den nye skanningen, CI-en din og en persons gjennomgang.

Pull requesten

• Åpnes av organisasjonens bot for AI-rettelser, <org>-fremforge-bot-autofix, på en ny branch under autofix-ai/. Boten skriver bare til brancher den selv oppretter og kan aldri godkjenne.
• Tittelen er fix(security): <rule> in <path>, med etikettene autofix og ai-generated, som legges på så snart pull requesten er åpen. En etikett repositoryet ikke har ennå, opprettes på samme måte som for sikkerhetsrettelser: én gang, og en eksisterende etikett får være som den er; kan den ikke opprettes, forblir pull requesten åpen uten den.
• Beskrivelsen navngir funnet, gir modellens forklaring, leverandøren og modellen som ble brukt og tokenene som gikk med, forteller hvordan den ble sjekket, og lister opp hva du bør sjekke før du merger. Den har med opplysningen etter EUs AI-forordning art. 50: en lesbar erklæring om at endringen er AI-generert, og en maskinlesbar fremforge:ai-disclosure-markør som navngir funksjonen, leverandøren og modellen.
• Klargjøres aldri for automerge, og pull requestene fra boten for AI-rettelser er ikke unntatt fra påkrevde godkjenninger: en person gjennomgår og merger den. En automerge som klargjøres på den uten en godkjennende gjennomgang, avbrytes.

Regler som dekkes

Andre regler viser Not on the AI fix rule list: funnene deres trenger en persons skjønn mer enn en patch. En regel fjernes fra listen hvis færre enn 30 % av pull requestene dens blir merget.

Når ingen pull request åpnes

Funnet viser da No PR: the proposed change did not pass the checks eller No PR: the fix could not be completed, og GET .../code-security/autofix/ai-requests gir årsaken, for eksempel scope_ci_config, new_dependency, suppression_comment, rescan_finding_still_present, rescan_new_finding eller ai_over_cap. Du kan be på nytt etter 10 minutter.

Grenser

• Én aktiv forespørsel per funn. Be på nytt etter 10 minutter hvis en forespørsel endte uten en pull request.
• Høyst 3 åpne pull requests med AI-rettelser per repository og 20 forespørsler om AI-rettelser per organisasjon i løpet av 24 timer, som standard.

Disse grensene tilhører AI-rettelse. De er adskilt fra grensene for sikkerhetsrettelser, som har sin egen teller. En eier setter 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 utfasede kallet setter også grensene for sikkerhetsrettelser; se Utfaset API.

API

• Be om en AI-rettelse POST /_app/api/v1/orgs/{org}/code-security/sast/findings/{id}/ai-fix, scope findings:write. Svarer 202 med id-en til forespørselen og "automerge": false; pull requesten kommer i løpet av noen minutter. Et avslag er problem+json der type er ai-fix-<reason> og som har med reason, for eksempel not_curated, ai_disabled eller no_provider. Den eldre stien .../sast/findings/{id}/autofix er utfaset, fortsetter å virke til 2027-10-15 og svarer autofix-<reason>.
• List AI-forespørsler GET /_app/api/v1/orgs/{org}/code-security/autofix/ai-requests, scope findings:read: status, årsak, pull request, leverandør, modell og antall tokener.
• Slå av eller på PUT /_app/api/v1/orgs/{org}/code-security/autofix/settings med "ai_enabled": true eller false (policy:write). ai_provider_configured i GET forteller om organisasjonen har sin egen leverandør.

Hvert SAST-funn fra GET .../code-security/sast/findings har med autofix_eligible, autofix_unavailable_reason og autofix, den siste forespørselen om AI-rettelse som dekker funnet.

Revisjon

Forespørsler om AI-rettelser står i revisjonsloggen som autofix.proposed, autofix.pr_opened, autofix.rejected, autofix.merged og autofix.closed, med engine: ai, leverandørens id og antall tokener, aldri prompten eller diffen. Å slå bryteren av eller på registreres som autofix.settings.updated.

Se også

• AI-integrasjoner: der organisasjonens egen modelleverandør konfigureres.
• SAST: funnene knappen står på.
• Sikkerhetsrettelser: rettelser for sårbare avhengigheter og base-imager, uten AI.
• Regelbaserte rettelser: rettelser for funn av secrets og IaC, laget etter en fast regel, uten AI.