Remédiation des vulnérabilités par l'IA : ce que peuvent faire les pull requests de correctif

Ce qu'est la remédiation par l'IA

La remédiation des vulnérabilités par l'IA s'appuie sur un modèle de langage pour produire le correctif d'une vulnérabilité connue. Elle prend trois formes :

• Suggestions de correctifs de code. Un modèle propose un patch à côté d'une alerte d'analyse statique. GitHub Copilot Autofix, par exemple, « génère automatiquement des suggestions de modification de code pour les alertes CodeQL détectées dans les pull requests et sur la branche par défaut ».
• Mises à niveau de dépendances qui adaptent le code. Changer de version est facile. Le plus difficile, ce sont la fonction renommée ou la valeur par défaut modifiée qu'apporte la nouvelle version. Un modèle peut effectuer ces modifications dans la même pull request.
• Remédiation agentique. Un agent mène le correctif à bien en plusieurs étapes, de manière autonome : modifier le code, lancer le build et les tests, lire les échecs, réessayer, et n'ouvrir une pull request que lorsque les vérifications passent.

Là où les correctifs de l'IA font leurs preuves

Les bots de mise à jour fondés sur des règles ouvrent déjà des pull requests qui font passer un paquet vulnérable à une version corrigée. Ils restent bloqués dès que la mise à niveau casse quelque chose, car adapter le code appelant ne se résume pas à une règle. C'est là que le backlog s'accumule : la mise à jour de sécurité qui reste ouverte pendant des mois parce que personne n'a le temps de gérer le changement de version majeure.

Lire un changelog, retrouver les points d'appel et les réécrire, c'est exactement le genre de travail que les modèles de langage font bien. Un correctif IA qui arrive avec la mise à niveau et les modifications de code, construit et testé, transforme une semaine d'attention en une simple relecture.

Là où les correctifs de l'IA se trompent

Les descriptions les plus claires de leurs limites viennent des éditeurs eux-mêmes. À propos de Copilot Autofix, GitHub écrit :

• Il « utilise un modèle génératif non déterministe. Même avec la même alerte et le même code, il peut ne pas produire de suggestion viable, ou la suggestion peut varier d'une tentative à l'autre ».
• « Le système ne sait pas quelles versions de dépendances sont prises en charge ou sûres, et peut suggérer des dépendances inventées publiées sous des noms statistiquement probables. »

Le second point n'a rien d'hypothétique. Des travaux de recherche sur les modèles qui génèrent du code ont mesuré la fréquence à laquelle ils recommandent des paquets qui n'existent pas, des noms qu'un attaquant peut enregistrer et remplir de malware. Un correctif qui installe un paquet halluciné remplace une vulnérabilité par une autre, pire encore.

Trois garde-fous couvrent l'essentiel du risque :

1. Construire et tester chaque correctif avant qu'une personne ne le relise, afin que le temps de relecture aille aux correctifs qui fonctionnent.
2. Vérifier chaque paquet ajouté ou modifié par rapport au registre et à la version attendue.
3. Garder une personne au moment du merge. Un correctif IA est la pull request d'un contributeur, pas une décision.

Données douteuses en entrée, pull requests en sortie

Un outil de remédiation par l'IA corrige les vulnérabilités qu'on lui transmet. Si cette liste est reconstituée à partir de lockfiles ou d'une image scannée, elle hérite de toutes les lacunes de la reconstitution : outils téléchargés par le build qu'aucun manifeste ne déclare, versions différentes de celles résolues par le build, paquets restaurés depuis des caches. L'outil ouvre alors avec assurance des pull requests pour certaines vulnérabilités et n'entend jamais parler des autres.

Certaines équipes vont plus loin et demandent à un modèle de déterminer lui-même les dépendances. L'inventaire devient alors lui aussi non déterministe, alors que c'est la seule partie du processus dont le résultat devrait être identique à chaque fois. SBOM générées par l'IA explique pourquoi un inventaire deviné n'est pas une preuve.

L'approche qui fonctionne combine des données déterministes à la base et le jugement de l'IA par-dessus : une liste enregistrée de ce que contient réellement chaque build, rapprochée des avis de sécurité par simple consultation, et l'IA qui écrit le correctif.

La place de CRACI

CRACI est la couche déterministe. Il exécute vos jobs GitHub Actions sur ses propres runners et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives et les paquets restaurés depuis les caches, avec un état de complétude pour chaque job. Il réévalue en continu les SBOM surveillées, de sorte qu'un nouvel avis de sécurité apparaît sur les builds qu'il concerne, et les équipes sécurité trient chaque résultat et le transmettent à l'équipe chargée du correctif.

C'est de cette liste qu'un correctif IA devrait partir, et une fois le correctif mergé, la SBOM du build suivant montre si la version corrigée est bien celle que le build a réellement utilisée. Consultez le suivi des vulnérabilités pour la fonctionnalité complète, et IA ou sécurité déterministe pour savoir où chaque approche a sa place.

Remédiation des vulnérabilités par l'IA : questions fréquentes

Qu'est-ce que la remédiation des vulnérabilités par l'IA ?

La remédiation des vulnérabilités par l'IA s'appuie sur un modèle de langage pour produire le correctif d'une vulnérabilité : une modification de code pour un résultat d'analyse statique, ou une mise à niveau de dépendance accompagnée des modifications de code qu'elle exige. Le résultat prend généralement la forme d'une suggestion ou d'une pull request qu'une personne doit relire.

Qu'est-ce que la remédiation agentique ?

La remédiation agentique donne à un agent IA les outils pour mener un correctif à bien en plusieurs étapes, de manière autonome : lire le résultat, modifier le code, lancer le build et les tests, recommencer jusqu'à ce qu'ils passent, puis ouvrir une pull request. La différence avec une suggestion ponctuelle, c'est que l'agent vérifie son propre travail avant qu'une personne ne le voie.

Peut-on merger sans risque les correctifs de sécurité générés par l'IA ?

Traitez-les comme la pull request de n'importe quel autre contributeur. GitHub décrit Copilot Autofix comme non déterministe et avertit qu'il peut suggérer des dépendances inventées : relisez la modification, lancez les tests et vérifiez que chaque paquet ajouté existe bel et bien et correspond à celui que vous attendez.

L'IA peut-elle trouver des vulnérabilités dans les dépendances ?

Ce n'est pas le bon outil pour cette partie. Savoir si une version de paquet est concernée par un avis de sécurité connu relève d'une simple consultation, dont le résultat doit être identique à chaque fois. Laissez un outillage déterministe produire la liste des paquets vulnérables à partir d'une SBOM enregistrée, et réservez l'IA aux tâches où le jugement est utile : écrire et adapter le correctif.

De quoi un outil de remédiation par l'IA a-t-il besoin pour bien fonctionner ?

D'une liste exacte de ce qui est réellement vulnérable, d'un build et d'une suite de tests sur lesquels éprouver le correctif, et d'une personne au moment du merge. La première est celle qui manque le plus souvent : une pull request de correctif pour un paquet que le produit ne livre pas n'est que du bruit, et un paquet vulnérable oublié par l'inventaire n'en reçoit jamais.