Remediation : du constat vérifié à la modification relue

« Détecter n’est pas corriger » : ce qu’est une modification à relire, et pourquoi votre équipe garde la maîtrise de la fusion

Un constat vous signale qu’il y a un problème. Il ne modifie pas une seule ligne de votre code. Entre les deux se trouve un travail que les scanners ne font pas. Quelqu’un doit écrire le correctif et vérifier qu’il élimine la cause racine sans rien casser. La modification doit ensuite passer la revue de votre équipe.

Remediation correspond à l’étape Remédier de Proof-Driven AppSec. AI Swarm Pentest valide ce qui est exploitable (module 6), et Deep Code Analysis explique comment une faiblesse affecte votre application (module 5). Remediation transforme ces connaissances en une modification que votre équipe peut relire. Partez de constats que vous avez triés (module 4), idéalement étayés par des preuves, comme un constat de pentest confirmé ou un chemin de code atteignable : le temps de revue est ainsi consacré à des risques réels.

Ce que contient une modification à relire

Dans Plexicus, une remédiation de code est une proposition de modification portant sur un ou plusieurs constats. Ce n’est ni un commit sur votre branche principale, ni un simple ticket « merci de corriger ». Elle comporte quatre éléments :

• Un diff. Les lignes exactes ajoutées et supprimées, fichier par fichier.
• Une explication et un titre. L’IA les rédige à l’intention du relecteur, en indiquant ce qui a changé et pourquoi. Ils deviennent la description et le titre de la pull request.
• Un badge de vérification. Il indique si le correctif a été testé, et avec quel résultat.
• Une destination. La modification part sur une nouvelle branche de votre dépôt, avec une pull request vers votre branche de base. Sur GitLab, il s’agit d’une merge request.

Prenons une injection SQL dans un gestionnaire de connexion, où le gestionnaire concatène l’adresse e-mail saisie dans une chaîne de requête. Une modification à relire remplace, dans ce gestionnaire, la concaténation par une requête paramétrée et explique pourquoi. Elle arrive sous forme de pull request que vos relecteurs peuvent lire à côté des preuves du constat. Elle ne réécrit pas votre couche d’accès aux données, et rien n’atteint votre branche principale tant qu’un membre de votre équipe ne l’a pas fusionnée.

Pourquoi votre équipe garde la maîtrise de la fusion

Plexicus ne fusionne jamais une pull request de remédiation. La fusion a lieu dans votre SCM, dans le respect de vos protections de branche, de vos revues obligatoires et de votre CI, et ce sont des membres de votre équipe qui l’effectuent. Trois raisons à cela.

• Le code écrit par l’IA peut être erroné ou incomplet. L’écran de revue comporte un avertissement qui vous demande de valider la suggestion au regard du contexte et des exigences de votre projet.
• C’est votre équipe qui détient le contexte. Prenons une IDOR dans une API de factures, où n’importe quel client connecté peut lire la facture d’un autre client en modifiant l’identifiant. Un correctif peut ajouter un contrôle de propriété. Seule votre équipe sait si le personnel du support doit encore pouvoir ouvrir toutes les factures.
• La responsabilité. La description de la pull request nomme l’utilisateur qui l’a ouverte, et votre SCM enregistre qui l’a approuvée et fusionnée. Plexicus consigne les demandes de remédiation dans le journal d’audit (Audit Log) de l’organisation, et la section Activity de chaque constat indique quand une remédiation a été générée et quand sa pull request a été créée.

Quels constats peuvent être corrigés dans le code

Plexicus ne peut corriger que ce qui se trouve dans un dépôt. Ce que propose le panneau de détail dépend de l’origine du constat.

Constat	Ce que propose le panneau de détail
Un constat qui pointe vers un fichier d’un dépôt connecté	Create AI Remediation
Un constat de registre de conteneurs dont l’image est liée à un dépôt source	Remediate in repo
Un constat dont le type de remédiation est Issue, par exemple lorsqu’il n’y a aucune ligne source à modifier	Create Issue
Un constat AI Pentest	Aucun correctif de code, sauf si le pentest est lié à un dépôt source ; vérifiez auprès de Plexicus que les correctifs de pentest sont disponibles dans votre version
Une erreur de configuration cloud, un constat de posture SCM, ou une image de registre non liée à un dépôt	Aucune action de remédiation

Si un AI Pentest n’a pas de dépôt lié, Plexicus vous indique que la remédiation nécessite un dépôt source lié et que vous pouvez en configurer un dans les paramètres du pentest.

Créer une remédiation par IA : vérifications, stratégies de correction et progression en direct

Les vérifications que Plexicus effectue d’abord

Plexicus s’assure d’abord que le travail peut aboutir.

1. Connexion IA. Il teste la connexion IA de votre organisation, qu’il s’agisse de celle de Plexicus par défaut ou de la vôtre (leçon 5).
2. Connexion SCM. Il valide votre jeton de gestion de code source. Si le jeton n’est plus valide, Plexicus vous demande de reconnecter votre gestion de code source.
3. Accès au dépôt. Il confirme que le dépôt est joignable.
4. Verdict de faux positif. Un constat encore en attente de revue de faux positif, ou que la passe IA a signalé comme faux positif, ne peut pas faire l’objet d’une remédiation. L’infobulle l’indique, et le serveur applique aussi cette règle. Annuler le marquage de faux positif posé par l’IA (module 4) lève le blocage.
5. Une personne à la fois. Si un collègue travaille déjà sur la remédiation de ce constat, le bouton est désactivé et affiche « Another user is working on this finding ».

Les dépôts de démonstration (sandbox) ignorent les vérifications SCM et peuvent générer des correctifs, mais pas ouvrir de pull requests ni d’issues. Si votre quota mensuel d’utilisation de l’IA est épuisé, le bouton est désactivé (leçon 5).

Comment Plexicus choisit une stratégie de correction

Vous ne choisissez pas la stratégie : Plexicus la détermine à partir du constat.

Situation	Stratégie	Mode de production de la modification
Une personne a marqué le constat comme faux positif	Commentaire de suppression	Un commentaire en ligne qui neutralise cette règle à cet emplacement
Un constat de dépendance avec une version corrigée connue dans la même version majeure	Montée de version de dépendance	Une modification déterministe du manifeste, sans code écrit par une IA
Tous les autres cas, y compris les mises à niveau de dépendances qui changent de version majeure	Agent de correction IA	Une modification de code écrite par l’agent

Le commentaire de suppression fait suite à une décision humaine. Lorsque quelqu’un marque un constat comme faux positif (module 4), Plexicus demande une modification qui ajoute ce commentaire. Selon votre fournisseur de gestion de code source, elle arrive sous forme de pull request que votre équipe relit, sans être décomptée de votre quota d’utilisation de l’IA.

La montée de version de dépendance couvre les manifestes courants, dont npm, Composer, requirements.txt, Gemfile, les fichiers TOML, go.mod, Gradle et .csproj. La version proposée est vérifiée auprès du registre de paquets ; si elle ne peut pas l’être, la remédiation porte l’avertissement « review before merging ». Un saut de version majeure peut modifier l’API de la bibliothèque : il est donc confié à l’agent de correction IA. Aucune IA n’écrit la montée de version, mais elle est tout de même décomptée de votre quota d’utilisation de l’IA.

Ce que fait l’agent de correction IA, et ce qu’il ne fait pas

L’agent travaille sur un clone récent de la branche configurée du dépôt. Son périmètre est volontairement restreint :

• Il corrige uniquement le problème signalé, dans le fichier et à la ligne signalés.
• Il ne touche à un autre fichier que si le correctif l’exige, par exemple un utilitaire partagé.
• Il a pour consigne de ne pas refactoriser, de ne pas corriger d’autres problèmes qu’il remarque, de ne pas modifier les fichiers de test et de ne pas committer. Plexicus capture le résultat sous forme de diff git.

Des consignes ne sont pas des garanties : vérifiez donc que le diff ne va pas au-delà du constat.

Pour les classes de vulnérabilités courantes, l’agent reçoit le pattern de codage sécurisé propre au langage du fichier : injection SQL (CWE-89), cross-site scripting (CWE-79), injection de commandes système (CWE-78), traversée de répertoires (CWE-22) et fichiers temporaires non sécurisés (CWE-377). Cela l’oriente vers une requête paramétrée plutôt que vers un filtre par liste de blocage. Pour un secret exposé, l’agent déplace la valeur dans une variable d’environnement, et la revue ajoute des recommandations pour configurer une solution de gestion des secrets.

Lorsqu’une remédiation couvre plusieurs constats, ceux-ci sont regroupés par fichier, à raison de quelques-uns par session IA, et les groupes s’exécutent l’un après l’autre. Les groupes terminés sont livrés même si un groupe suivant dépasse le délai imparti.

Suivre la progression

Le terminal en direct affiche chaque étape au fil de l’eau, du clonage du dépôt à « Generating fix… », puis une ligne par groupe de fichiers, jusqu’à « Fix captured » et un résultat final. Lorsque le correctif est prêt, la fenêtre de revue s’ouvre automatiquement. View AI Remediation permet de la rouvrir plus tard.

Si un correctif est toujours en cours après 15 minutes, Plexicus affiche « This remediation is taking longer than expected. » et propose Create Remediation Again. Si la génération échoue, vous voyez « Failed to create remediation » et un bouton Try Again. Une tentative échouée n’empêche jamais de réessayer.

Relire le correctif et ouvrir la pull request

La fenêtre de revue est l’endroit où votre jugement entre en jeu. Examinez-la comme vous le feriez pour la pull request d’un collègue, en gardant les preuves du constat sous les yeux.

Ce qu’affiche la fenêtre de revue

• Le titre du constat et un badge de vérification.
• Un résumé de la modification : lignes ajoutées, lignes supprimées et nombre de fichiers.
• Un diff unifié pour chaque fichier. Toute ligne générée qui semble corrompue est barrée et signalée par « Possibly corrupt generated line — review before applying. »
• Une section repliable, Why this fix — reasoning & verification, qui contient l’explication rédigée par l’IA.
• L’avertissement relatif à l’IA, ainsi que la branche source et la branche cible qu’utilisera la pull request.

L’explication est rédigée dans la langue définie par le paramètre Scan & Report Language de votre organisation, qu’un Admin configure dans Settings Platform .

Interpréter le badge de vérification

La vérification des correctifs est facultative. Votre organisation l’active avec l’option Fix verification dans Settings Platform , et sa disponibilité dépend de votre offre. Lorsqu’elle est activée, une seconde session IA s’exécute dans une copie isolée et jetable du dépôt. Elle écrit un test de sécurité ciblé pour le constat et l’exécute sur le code corrigé.

Badge	Signification
Fix verified	Le test isolé a été exécuté et a réussi sur le code corrigé
Fix not tested	Aucun test de vérification n’a été exécuté pour ce correctif
Fix unverified	Le correctif a été appliqué, mais le test a dépassé le délai imparti : il n’est donc pas prouvé
Verification failed	Le test a montré que la vulnérabilité reste exploitable
Verification error	Le test n’a pas pu s’exécuter

La vérification ne fait qu’annoter le correctif. Elle ne modifie jamais le diff que vous relisez.

Ce qu’il faut vérifier avant d’ouvrir la pull request

• La cause racine, pas le symptôme. Pour le gestionnaire de connexion, la requête paramétrée est le correctif. Échapper les guillemets dans le champ e-mail ne l’est pas.
• Le comportement. Pour l’IDOR des factures, vérifiez que le nouveau contrôle de propriété correspond à vos règles d’autorisation réelles.
• Les dépendances. Lisez le changelog de la nouvelle version et vérifiez si votre fichier de verrouillage (lockfile) doit être régénéré.
• Les secrets. Déplacer un secret dans une variable d’environnement met fin à la fuite dans le code, mais l’ancienne valeur reste compromise. Procédez à sa rotation.

Modifier, puis ouvrir la pull request

Avec les rôles par défaut, les utilisateurs Admin et Cyberoper peuvent modifier le code généré tant qu’aucune pull request n’existe. Utilisez Edit Pull Request, ou Edit puis Save sur chaque fichier d’un correctif portant sur plusieurs fichiers. Dès qu’une pull request ou une issue existe, l’édition est verrouillée avec le message « A pull request has already been created — editing is locked. » À partir de là, vous modifiez le code sur la branche, dans votre SCM.

Lorsque la modification est prête, un Admin ou un Developer clique sur Pull Request (Merge Request sur GitLab) en bas de la fenêtre. Plexicus clone la branche configurée et crée une nouvelle branche dont le nom commence par Plexicus-AI-Remediation-. Il applique le diff, pousse la branche et ouvre une pull request vers la branche de base. Son titre et sa description proviennent de la remédiation, et la description se termine par « Created by: » suivi de l’adresse e-mail de l’utilisateur qui l’a ouverte. Un bandeau confirme « Pull request created » avec un lien See PR, et le bouton du constat devient See Pull Request.

Les pull requests de remédiation fonctionnent sur GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Gitea et Forgejo. Azure TFVC n’a pas de pull requests. Si le push échoue, Plexicus en indique la raison : le dépôt est un miroir en lecture seule, le jeton nécessite un accès en écriture, ou le jeton n’est pas valide.

Pour les constats traités sous forme d’issue, la fenêtre propose Create Issue, ainsi que Send Webhook si un webhook d’issues est configuré. Si une intégration de ticketing est configurée pour suivre les pull requests, le ticket est également mis à jour (module 9).

Statut	Signification ici
Ready to Fix	Une remédiation a été générée et attend d’être relue
Fix Submitted	Une pull request ou une merge request a été ouverte
Issued	Une issue a été ouverte à la place d’une pull request
Fixed	Votre SCM a signalé la fusion de la pull request, ou la fermeture de l’issue liée

Remédiation groupée sur de nombreux constats

Corriger les constats un par un ne permet pas de suivre le rythme lorsqu’un scan signale 40 paquets vulnérables dans un service. La remédiation groupée applique le même flux à une sélection et suit l’ensemble de l’exécution en un seul endroit. Sa disponibilité dépend de votre offre.

Lancer une exécution groupée

Dans Findings , cochez au moins deux constats, ouvrez les actions groupées et choisissez Remediate. Une même requête accepte jusqu’à 100 constats. Les actions groupées proposées dépendent de votre rôle (module 4) ; avec les rôles intégrés, les utilisateurs ayant le rôle Developer ne peuvent utiliser Create Pull Request que sur les constats dont la remédiation a déjà été générée.

Plexicus regroupe la sélection par dépôt, puis par stratégie de correction, exactement comme pour un constat unique (leçon 2). Dans chaque dépôt, les commentaires de suppression, les montées de version de dépendance et les correctifs IA forment chacun leur propre remédiation, et seuls les correctifs IA passent par les groupes de fichiers de l’agent de correction IA. Les constats traités sous forme d’issue obtiennent chacun leur propre issue rédigée par l’IA. La fenêtre propose deux options :

• Automatically create pull requests. Activée par défaut. Lorsqu’elle est désactivée, les correctifs s’arrêtent à Ready to Fix et rien n’est poussé.
• Pull request mode s’applique aux correctifs IA. Dans les deux cas, chaque dépôt reçoit une seule pull request pour ces correctifs. Single PR enregistre chaque groupe de remédiation dans son propre commit, ce qui permet aux relecteurs de parcourir la modification fichier par fichier, et écarte les groupes qui ont échoué ou n’ont rien modifié. One PR per remediation, l’option par défaut, livre les mêmes correctifs en un seul commit. Les montées de version de dépendance et les commentaires de suppression ont toujours leur propre pull request.

Cliquez sur Remediate pour lancer l’exécution. Les constats qui ont déjà une remédiation sont ignorés. Les constats encore en attente de revue de faux positif, ou signalés comme faux positifs par la passe IA, sont bloqués, comme lorsqu’ils sont traités un par un.

Suivre l’exécution

Le bouton de la barre d’outils Findings Bulk remediation status ouvre le panneau Bulk Remediation Progress. Chaque exécution passe par quatre phases : Queued, Generating fixes, Creating pull request et Completed. Une exécution affiche l’état Running, Completed ou Incomplete.

Chaque groupe de remédiation, soit quelques constats d’un même fichier, affiche son propre statut. Voici ceux que vous rencontrerez le plus souvent :

Statut du groupe	Signification
Queued	En attente du moteur de remédiation
Processing (avec un pourcentage)	L’agent de correction IA travaille sur ce groupe
Succeeded	Le groupe a produit une modification
Failed	La session IA a rencontré une erreur ou a dépassé le délai imparti
Skipped (no changes)	Le groupe n’a produit aucune modification, et ses constats restent en l’état

Chaque groupe dispose de son propre terminal en direct, et View Pull Request vous amène au résultat. Le panneau est conservé après une actualisation de la page, et toute l’équipe peut le consulter. Un collègue peut suivre une exécution que vous avez lancée sans avoir à vous demander où elle en est. En mode Single PR, les constats d’un groupe qui a échoué ou n’a produit aucune modification conservent leur statut.

Concevoir un lot que vos relecteurs peuvent absorber

Une exécution groupée ne vaut que par les pull requests qu’elle produit. Constituez des lots cohérents par dépôt, par équipe propriétaire et par classe de problème. Par exemple, sélectionnez les 25 constats de dépendances vulnérables du service de paiement plutôt que 25 constats sans lien répartis sur six dépôts. Un lot ciblé donne à une équipe une pull request qu’elle reconnaît et qu’elle peut relire en une seule séance. Un lot hétéroclite produit des pull requests dont personne ne se sent responsable.

Configuration et utilisation de l’IA : quota, votre propre IA et ce qui n’est jamais automatique

Votre quota d’utilisation de l’IA

Les actions d’IA puisent dans un quota mensuel unique pour votre organisation. Cela inclut les correctifs IA, les montées de version de dépendance, les issues rédigées par l’IA et l’analyse des faux positifs par l’IA. Les scans de dépôts n’y puisent pas, mais l’analyse assistée par IA peut le faire : consultez donc le compteur avant un scan IA de grande ampleur. Le quota est réinitialisé le 1er de chaque mois civil (UTC), et non à votre date de facturation. Les sessions AI Pentest (module 6) et les conversions de filtres par IA disposent de leurs propres compteurs. La taille de votre quota dépend de votre offre.

Lorsque des données d’utilisation sont disponibles, le menu de votre profil affiche un compteur d’utilisation et un lien Manage billing & usage. Selon votre offre, Settings Billing , une page intitulée Billing & Usage, indique ce qui a été consommé ce mois-ci par rapport à votre limite et la date de réinitialisation du quota, ou Unlimited. Sur la page Billing, la barre devient ambre à 75 % et rouge à 90 %, et Plexicus vous avertit à chacun de ces seuils. Lorsque votre version l’inclut, une page Usage dans Settings détaille l’utilisation par action, avec l’historique complet.

Lorsque le quota est épuisé, Create AI Remediation est désactivé avec un message indiquant que la limite mensuelle est atteinte, l’action groupée Remediate est désactivée, et la page Findings affiche un bandeau avec Upgrade plan. Les actions d’IA reprennent à la réinitialisation du quota.

Apporter votre propre IA (BYO-AI)

Selon votre offre, vous pouvez exécuter l’IA de Plexicus sur vos propres points de terminaison de modèles plutôt que sur les modèles par défaut de Plexicus.

Emplacement	Usage	Ce que vous saisissez
Fast model	S’exécute sur chaque constat pour la validation et l’enrichissement : il traite donc un volume élevé	API key, Base URL, Model
Smart model	Génère les correctifs et l’analyse approfondie, avec un volume plus faible et des enjeux plus élevés	API key, Base URL, Model
Embeddings endpoint	Construit l’index de recherche de votre code avant chaque scan IA	API key et Base URL ; le modèle d’embeddings est fixe et affiché en lecture seule

Chaque emplacement accepte un point de terminaison standard de chat-completions ou d’embeddings de votre fournisseur d’IA, authentifié par une clé d’API, y compris une passerelle auto-hébergée. Il n’y a pas de sélecteur de fournisseur. Save BYOAI configuration teste et enregistre les trois blocs ensemble, et le point de terminaison d’embeddings est obligatoire, car une configuration partielle ferait échouer tous les scans IA. Les clés enregistrées ne sont plus jamais affichées ; laissez un champ de clé vide pour conserver la clé existante. Avant tout test de connexion, les Base URL sont contrôlées pour prévenir la falsification de requêtes côté serveur. Reset to Plexicus default efface les trois blocs. Avec BYO-AI, le compteur d’utilisation affiche Unlimited, car l’inférence s’exécute avec votre propre clé et votre propre compte auprès de votre fournisseur d’IA.

Où va votre code

Les fonctionnalités d’IA envoient le contexte de code pertinent au point de terminaison du modèle configuré : les modèles par défaut de Plexicus, ou votre propre point de terminaison avec BYO-AI. Chaque remédiation s’exécute dans une tâche isolée et éphémère. L’agent ne peut écrire que dans son espace de travail cloné et ne reçoit aucun des autres identifiants de la plateforme. La vérification s’exécute dans une copie jetable, supprimée ensuite. Le code des clients n’est pas utilisé pour entraîner des modèles d’IA, et les données SaaS restent dans l’UE par défaut.

Ce qui ne se produit jamais automatiquement

Points clés à retenir

• Une remédiation est une proposition : un diff, une explication, un badge de vérification et une pull request sur une nouvelle branche. Plexicus ne la fusionne jamais. C’est votre équipe qui le fait, dans votre SCM.
• Avant de lancer un correctif, Plexicus vérifie la connexion IA, le jeton SCM, l’accès au dépôt et le verdict de faux positif. Il choisit ensuite un commentaire de suppression, une montée de version de dépendance ou l’agent de correction IA.
• Relisez le diff et l’explication « Why this fix » comme n’importe quelle pull request. Un badge Fix verified prouve que le test ciblé a réussi, pas que rien d’autre n’est cassé.
• Modifiez le correctif tant que la remédiation n’est encore qu’une proposition. Dès que la pull request existe, l’édition est verrouillée, et Fix Submitted ne devient Fixed que lorsque votre SCM signale la fusion.
• La remédiation groupée traite jusqu’à 100 constats, organisés par dépôt et par stratégie de correction. Choisissez délibérément les pull requests automatiques et le mode de pull request, et suivez l’exécution dans le panneau Bulk Remediation Progress.
• Les actions d’IA puisent dans un quota mensuel d’utilisation de l’IA, affiché dans Settings Billing et dans le menu de votre profil. Avec BYO-AI, vous dirigez les emplacements Fast, Smart et Embeddings vers les points de terminaison de votre propre fournisseur d’IA.