Correctif IA

Pour un petit ensemble de règles SAST dont la correction est étroite et vérifiable, le Correctif IA demande un correctif au modèle d’IA de votre organisation et ouvre une pull request avec celui-ci. Le bouton Correctif IA se trouve sur chaque résultat SAST d’une telle règle, sous Sécurité › Résultats › SAST. Le paramètre qui l’active est Correctifs IA pour les résultats de code, sous Sécurité › Corriger › Correctif IA.

Le correctif IA ne concerne que les résultats de code. Les dépendances et images de base vulnérables sont corrigées sans IA, par les correctifs de sécurité. Jusqu’au 2026-10-14, les deux s’appelaient AutoFix ; les chemins d’API .../autofix/..., les labels et les événements d’audit utilisent encore ce nom.

Votre propre fournisseur uniquement, désactivé par défaut

• Votre propre clé. Le modèle est le fournisseur propre à votre organisation sous Intégrations IA, facturé à vous et sous votre contrat avec ce fournisseur, exactement comme la revue de pull request par IA. fremforge ne détient aucune clé d’IA à lui et n’a pas de solution de repli. Sans fournisseur, Correctif IA est désactivé et indique pourquoi. Avec les correctifs IA activés, si le fournisseur a refusé votre clé lors de sa dernière utilisation (HTTP 401 ou 403), la page SAST le signale et les correctifs IA ne peuvent pas s’exécuter tant que vous n’avez pas mis à jour la clé sous Intégrations IA ; l’enregistrer à cet endroit la teste à nouveau.
• Désactivé par défaut. Un propriétaire active Correctifs IA pour les résultats de code sous Sécurité › Corriger › Correctif IA, ou avec PUT .../code-security/autofix/settings et "ai_enabled": true. La fonctionnalité autofix doit aussi être activée sous Intégrations IA : ajouter un fournisseur n’active à lui seul aucune fonctionnalité d’IA. Les dérogations par dépôt s’appliquent, de même que vos plafonds de dépenses d’IA.
• Une personne clique. Rien n’est proposé automatiquement, même avec les correctifs de sécurité automatiques activés. Chaque pull request commence par quelqu’un qui clique sur Correctif IA sur un résultat, ou qui appelle l’API pour un résultat.

Ce qui est envoyé au modèle

• la description publique de la règle et une instruction de correction propre à cette règle ;
• au plus 60 lignes du fichier concerné, issues du commit sur lequel le résultat a été relevé : les lignes autour du résultat, plus le bloc d’imports du fichier s’il tient dans les 60 ;
• le chemin du fichier et le numéro de ligne du résultat.

Jamais le reste du dépôt, d’autres fichiers, des tickets, le texte des pull requests ou des messages de commit. Le code est encapsulé comme donnée non fiable, avec une instruction précisant qu’il ne contient aucune instruction.

Le prompt, le code et le diff ne sont ni journalisés ni stockés par fremforge. Ils n’existent en mémoire que pendant la préparation du correctif, puis uniquement dans la pull request de votre dépôt. L’enregistrement de la demande conserve des identifiants, des compteurs et le résultat : quelle règle, quel fournisseur et quel modèle, combien de tokens, combien de lignes modifiées.

Ce qui est vérifié avant qu’une pull request existe

La réponse du modèle doit être exactement un diff unifié et un paragraphe d’explication ; toute autre chose est rejetée. Le diff doit ensuite passer chacun de ces contrôles, effectués par fremforge et non par le modèle :

• un seul fichier : celui du résultat ;
• au plus 40 lignes modifiées, et uniquement autour du résultat ou dans les imports du fichier ;
• aucune modification de la configuration CI (.forgejo/, .github/, …), de CODEOWNERS, des fichiers de suppression (.trivyignore*, osv-scanner.toml, .gitleaks.toml, .semgrepignore), des tests ou des manifestes de dépendances ;
• aucun commentaire de suppression ajouté (nosemgrep, nolint, nosec, noqa, eslint-disable, type: ignore, …) ;
• aucune nouvelle dépendance : un import ajouté doit provenir de la bibliothèque standard ou d’un module que le fichier importe déjà.

Le fichier corrigé est ensuite réanalysé avec le même binaire OpenGrep et le même jeu de règles que l’analyse de la pull request. Le résultat doit apparaître sur le fichier d’origine (pour qu’un résultat propre ait un sens), avoir disparu du fichier corrigé, et aucun nouveau résultat ne doit y apparaître. Ce n’est qu’alors que la pull request est ouverte.

Une tentative d’injection de prompt dans le code peut au pire produire un mauvais diff dans ce seul fichier, à l’intérieur de la fenêtre. Ce diff doit encore passer les contrôles ci-dessus, la réanalyse, votre CI et la revue d’une personne.

La pull request

• Ouverte par le bot de correctif IA de votre organisation, <org>-fremforge-bot-autofix, sur une nouvelle branche sous autofix-ai/. Le bot n’écrit que sur les branches qu’il crée et ne peut jamais approuver.
• Titre fix(security): <rule> in <path>, labels autofix et ai-generated, ajoutés dès que la pull request est ouverte. Un label que le dépôt n’a pas encore est créé de la même manière que pour les correctifs de sécurité : une seule fois, en laissant un label existant tel quel, et s’il ne peut pas être créé, la pull request reste ouverte sans lui.
• La description nomme le résultat, donne l’explication du modèle, le fournisseur et le modèle utilisés et les tokens consommés, indique comment le correctif a été vérifié et liste ce qu’il faut vérifier avant de fusionner. Elle porte la mention exigée par l’article 50 de l’AI Act de l’UE : une déclaration lisible indiquant que la modification est générée par IA, et un marqueur lisible par machine fremforge:ai-disclosure qui nomme la fonctionnalité, le fournisseur et le modèle.
• Jamais armée pour la fusion automatique, et les pull requests du bot de correctif IA ne sont pas exemptées des approbations requises : une personne la relit et la fusionne. Une fusion automatique armée dessus sans revue d’approbation est annulée.

Règles couvertes

Les autres règles affichent Hors de la liste de règles du correctif IA : leurs résultats demandent le jugement d’une personne plus qu’un patch. Une règle quitte la liste si moins de 30 % de ses pull requests sont fusionnées.

Quand aucune pull request n’est ouverte

Le résultat affiche alors Pas de PR : la modification proposée n’a pas passé les contrôles ou Pas de PR : le correctif n’a pas pu aboutir, et GET .../code-security/autofix/ai-requests donne la raison, par exemple scope_ci_config, new_dependency, suppression_comment, rescan_finding_still_present, rescan_new_finding ou ai_over_cap. Vous pouvez redemander au bout de 10 minutes.

Limites

• Une seule demande active par résultat. Redemandez au bout de 10 minutes si une demande s’est terminée sans pull request.
• Au plus 3 pull requests de correctif IA ouvertes par dépôt et 20 demandes de correctif IA par organisation sur toute période de 24 heures, par défaut.

Ces limites sont propres au correctif IA. Elles sont distinctes des limites des correctifs de sécurité, qui ont leur propre compteur. Un propriétaire les règle avec max_open_per_repo et max_per_org_per_day sur PUT .../code-security/autofix/settings (de 0 à 3 et de 0 à 20). Cet appel obsolète règle aussi les limites des correctifs de sécurité ; voir API obsolète.

API

• Demander un correctif IA POST /_app/api/v1/orgs/{org}/code-security/sast/findings/{id}/ai-fix, portée findings:write. Répond 202 avec l’identifiant de la demande et "automerge": false ; la pull request suit en quelques minutes. Un refus est un problem+json dont le type est ai-fix-<reason> et qui porte reason, par exemple not_curated, ai_disabled ou no_provider. L’ancien chemin .../sast/findings/{id}/autofix est obsolète, continue de fonctionner jusqu’au 2027-10-15, et répond autofix-<reason>.
• Lister les demandes IA GET /_app/api/v1/orgs/{org}/code-security/autofix/ai-requests, portée findings:read : statut, raison, pull request, fournisseur, modèle et nombre de tokens.
• L’activer ou le désactiver PUT /_app/api/v1/orgs/{org}/code-security/autofix/settings avec "ai_enabled": true ou false (policy:write). ai_provider_configured dans le GET indique si l’organisation a son propre fournisseur.

Chaque résultat SAST de GET .../code-security/sast/findings porte autofix_eligible, autofix_unavailable_reason et autofix, la dernière demande de correctif IA qui le couvre.

Audit

Les demandes de correctif IA figurent dans le journal d’audit sous autofix.proposed, autofix.pr_opened, autofix.rejected, autofix.merged et autofix.closed, avec engine: ai, l’identifiant du fournisseur et le nombre de tokens, jamais le prompt ni le diff. Activer ou désactiver le commutateur donne autofix.settings.updated.

Voir aussi

• Intégrations IA : là où le fournisseur de modèles propre à votre organisation est configuré.
• SAST : les résultats sur lesquels se trouve le bouton.
• Correctifs de sécurité : les correctifs des dépendances et images de base vulnérables, sans IA.
• Correctifs à base de règles : les correctifs des résultats de secrets et d’IaC, produits par une règle fixe, sans IA.