AI-fix

Voor een kleine set SAST-regels waarvan de fix beperkt en controleerbaar is, vraagt AI-fix het eigen AI-model van je organisatie om een fix en opent het een pull request daarmee. De knop AI-fix staat bij elke SAST-bevinding van zo’n regel, onder Beveiliging › Bevindingen › SAST. De instelling die het aanzet heet AI-fixes voor codebevindingen, onder Beveiliging › Herstellen › AI-fix.

AI-fix is alleen voor codebevindingen. Kwetsbare afhankelijkheden en base images worden zonder AI opgelost, door Beveiligingsfixes. Tot 2026-10-14 heetten beide AutoFix; de API-paden .../autofix/..., de labels en de auditgebeurtenissen gebruiken die naam nog.

Alleen je eigen provider, standaard uit

• Je eigen sleutel. Het model is de eigen provider van je organisatie onder AI-integraties, gefactureerd aan jou en onder je contract met die leverancier, precies zoals bij AI-review van pull requests. fremforge heeft zelf geen AI-sleutel en geen terugvaloptie. Zonder provider is AI-fix uitgeschakeld en staat erbij waarom. Als AI-fixes aanstaan en de provider je sleutel de laatste keer dat hij werd gebruikt heeft geweigerd (HTTP 401 of 403), meldt de SAST-pagina dat en kunnen AI-fixes niet draaien tot je de sleutel bijwerkt onder AI-integraties; bij het opslaan daar wordt hij opnieuw getest.
• Standaard uit. Een eigenaar zet AI-fixes voor codebevindingen aan onder Beveiliging › Herstellen › AI-fix, of met PUT .../code-security/autofix/settings en "ai_enabled": true. Ook de functie autofix moet aanstaan onder AI-integraties: een provider toevoegen zet uit zichzelf geen enkele AI-functie aan. Overschrijvingen per repository gelden, net als je bestedingslimieten voor AI.
• Een persoon klikt. Er wordt niets automatisch voorgesteld, ook niet als automatische Beveiligingsfixes aanstaan. Elke pull request begint ermee dat iemand op AI-fix klikt bij één bevinding, of de API aanroept voor één bevinding.

Wat er naar het model gaat

• de openbare beschrijving van de regel en een fix-instructie voor die regel;
• hoogstens 60 regels van het betreffende bestand, uit de commit waarop de bevinding is ontstaan: de regels rond de bevinding, plus het importblok van het bestand als dat binnen de 60 past;
• het bestandspad en het regelnummer van de bevinding.

Nooit de rest van de repository, andere bestanden, issues, tekst van pull requests of commitberichten. De code wordt verpakt als niet-vertrouwde gegevens, met de instructie dat ze geen instructies bevat.

De prompt, de code en de diff worden door fremforge niet gelogd en niet opgeslagen. Ze bestaan in het geheugen zolang de fix wordt voorbereid, en daarna alleen in de pull request in je repository. Het record van de aanvraag bewaart id’s, aantallen en de uitkomst: welke regel, welke provider en welk model, hoeveel tokens, hoeveel regels er zijn gewijzigd.

Wat er wordt gecontroleerd voordat er een pull request is

Het antwoord van het model moet precies een unified diff en één alinea uitleg zijn; al het andere wordt afgewezen. De diff moet daarna aan elk van deze voorwaarden voldoen, gecontroleerd door fremforge en niet door het model:

• één bestand: dat van de bevinding zelf;
• hoogstens 40 gewijzigde regels, en alleen rond de bevinding of in de imports van het bestand;
• geen wijziging aan CI-configuratie (.forgejo/, .github/, …), CODEOWNERS, onderdrukkingsbestanden (.trivyignore*, osv-scanner.toml, .gitleaks.toml, .semgrepignore), tests of manifesten van afhankelijkheden;
• geen toegevoegd onderdrukkingscommentaar (nosemgrep, nolint, nosec, noqa, eslint-disable, type: ignore, …);
• geen nieuwe afhankelijkheid: een toegevoegde import moet uit de standaardbibliotheek komen of een module zijn die het bestand al importeert.

Daarna wordt het aangepaste bestand opnieuw gescand met dezelfde OpenGrep-binary en dezelfde regelset als de scan van pull requests. De bevinding moet in het oorspronkelijke bestand verschijnen (zodat een schoon resultaat iets betekent), uit het aangepaste bestand verdwenen zijn, en er mag geen nieuwe bevinding in verschijnen. Pas dan wordt de pull request geopend.

Een poging tot prompt-injectie in de code kan in het ergste geval een slechte diff in dat ene bestand opleveren, binnen het venster. Die moet dan nog steeds door de controles hierboven, de nieuwe scan, je CI en de review van een persoon.

De pull request

• Geopend door de AI-fixbot van je organisatie, <org>-fremforge-bot-autofix, op een nieuwe branch onder autofix-ai/. De bot schrijft alleen naar branches die hij zelf aanmaakt en kan nooit goedkeuren.
• Titel fix(security): <rule> in <path>, labels autofix en ai-generated, toegevoegd zodra de pull request open is. Een label dat de repository nog niet heeft, wordt op dezelfde manier aangemaakt als bij Beveiligingsfixes: één keer, een bestaand label blijft zoals het is, en als het niet kan worden aangemaakt, blijft de pull request zonder label open.
• De beschrijving noemt de bevinding, geeft de uitleg van het model, de gebruikte provider en het gebruikte model en de verbruikte tokens, vertelt hoe er is gecontroleerd en somt op wat je moet controleren voordat je samenvoegt. Ze bevat de vermelding uit artikel 50 van de EU AI Act: een leesbare verklaring dat de wijziging door AI is gegenereerd, en een machineleesbare markering fremforge:ai-disclosure die de functie, de leverancier en het model noemt.
• Nooit ingesteld op automatisch samenvoegen, en de pull requests van de AI-fixbot zijn niet vrijgesteld van verplichte goedkeuringen: een persoon reviewt en voegt samen. Automatisch samenvoegen dat erop wordt ingesteld zonder goedkeurende review, wordt geannuleerd.

Gedekte regels

Andere regels tonen Niet op de regellijst voor AI-fix: hun bevindingen vragen meer om het oordeel van een persoon dan om een patch. Een regel gaat van de lijst af als minder dan 30 % van zijn pull requests wordt samengevoegd.

Als er geen pull request wordt geopend

De bevinding toont dan Geen PR: de voorgestelde wijziging doorstond de controles niet of Geen PR: de oplossing kon niet worden afgerond, en GET .../code-security/autofix/ai-requests geeft de reden, bijvoorbeeld scope_ci_config, new_dependency, suppression_comment, rescan_finding_still_present, rescan_new_finding of ai_over_cap. Je kunt het na 10 minuten opnieuw vragen.

Limieten

• Eén lopende aanvraag per bevinding. Vraag het na 10 minuten opnieuw als een aanvraag zonder pull request is geëindigd.
• Standaard hoogstens 3 open pull requests van AI-fix per repository en 20 AI-fixaanvragen per organisatie binnen elke 24 uur.

Deze limieten zijn van AI-fix zelf. Ze staan los van de limieten van Beveiligingsfixes, die hun eigen teller hebben. Een eigenaar stelt ze in met max_open_per_repo en max_per_org_per_day op PUT .../code-security/autofix/settings (0 tot 3 en 0 tot 20). Die verouderde aanroep stelt ook de limieten van Beveiligingsfixes in; zie Verouderde API.

API

• Een AI-fix aanvragen POST /_app/api/v1/orgs/{org}/code-security/sast/findings/{id}/ai-fix, scope findings:write. Antwoordt 202 met het id van de aanvraag en "automerge": false; de pull request volgt binnen een paar minuten. Een weigering is problem+json met als type ai-fix-<reason> en met reason, bijvoorbeeld not_curated, ai_disabled of no_provider. Het oudere pad .../sast/findings/{id}/autofix is verouderd, blijft werken tot 2027-10-15 en antwoordt autofix-<reason>.
• AI-aanvragen opvragen GET /_app/api/v1/orgs/{org}/code-security/autofix/ai-requests, scope findings:read: status, reden, pull request, provider, model en aantallen tokens.
• Aan- of uitzetten PUT /_app/api/v1/orgs/{org}/code-security/autofix/settings met "ai_enabled": true of false (policy:write). ai_provider_configured in de GET geeft aan of de organisatie een eigen provider heeft.

Elke SAST-bevinding uit GET .../code-security/sast/findings bevat autofix_eligible, autofix_unavailable_reason en autofix, de laatste AI-fixaanvraag die haar dekt.

Audit

AI-fixaanvragen staan in het auditlog als autofix.proposed, autofix.pr_opened, autofix.rejected, autofix.merged en autofix.closed, met engine: ai, het id van de provider en de aantallen tokens, nooit de prompt of de diff. De schakelaar aan- of uitzetten is autofix.settings.updated.

Zie ook

• AI-integraties: waar de eigen modelprovider van je organisatie wordt ingesteld.
• SAST: de bevindingen waar de knop bij staat.
• Beveiligingsfixes: fixes voor kwetsbare afhankelijkheden en base images, zonder AI.
• Fixes op basis van regels: fixes voor secret- en IaC-bevindingen, gemaakt door een vaste regel, zonder AI.