Remédiation
Correctifs de code par l’IA et remédiation automatisée, approuvés par une personne
Les correctifs de code par l’IA sont des modifications qu’un modèle d’IA propose pour supprimer une vulnérabilité, le plus souvent une mise à niveau de dépendance ou une petite modification du code. Ils peuvent raccourcir le délai de remédiation, mais une personne devrait approuver chacun d’eux, car un correctif peut casser un comportement, introduire de nouveaux paquets transitifs, changer une licence ou tout simplement ne pas corriger le problème.
Offre Free, sans carte bancaire.
Que sont les correctifs de code par l’IA et la remédiation automatisée des vulnérabilités ?
La remédiation automatisée des vulnérabilités désigne tout outil qui transforme un constat en proposition de modification. Pour une dépendance vulnérable, il s’agit généralement d’une nouvelle version dans le manifeste et d’un lockfile régénéré. Pour un constat issu de l’analyse du code source, c’est une modification du code, par exemple le remplacement d’une requête construite par concaténation de chaînes par une requête paramétrée. Pour une erreur de configuration, c’est un paramètre modifié dans un Dockerfile ou un fichier Terraform. Les modèles d’IA servent désormais à la fois à écrire ces modifications et à les expliquer.
Les approches diffèrent surtout par ce qu’une personne voit avant qu’une modification soit intégrée. À un extrême, un outil suggère un correctif à côté d’un constat et un développeur l’applique à la main. Entre les deux, un outil prépare une modification que quelqu’un relit. À l’autre extrême, les modifications sont fusionnées automatiquement quand les tests passent. Plus un processus se rapproche de la fusion automatique, plus il dépend de tests capables de détecter un correctif cassé ou incomplet.
Pourquoi une personne devrait approuver chaque correctif
Un correctif proposé est une modification du code de production, écrite par quelque chose qui ne peut pas faire tourner votre produit dans les environnements de vos clients. Le modèle peut se tromper avec aplomb, et un diff propre peut masquer un changement de comportement. Approuver ne signifie pas refaire le travail : cela signifie qu’une personne nommément désignée a vérifié les points ci-dessous et accepte la modification. Cette trace sert aussi de preuve plus tard, lorsqu’il faut montrer comment une vulnérabilité a été traitée.
- Changements incompatibles : une mise à niveau de version majeure peut supprimer ou modifier les API qu’appelle votre code.
- Mises à niveau transitives : une nouvelle version peut embarquer de nouveaux paquets, chacun avec ses propres vulnérabilités et ses propres mainteneurs.
- Changements de licence : une nouvelle version peut passer à une licence que votre organisation n’accepte pas.
- Risque de régression : un comportement que vos tests ne couvrent pas peut changer sans bruit.
- Correctifs incomplets : la modification peut oublier un chemin de code affecté ou viser la mauvaise plage de versions.
- Détails inventés : une version ou un paquet proposé qui n’existe pas.
Comment évaluer une proposition de mise à niveau de dépendance
Partez de l’avis de sécurité, pas de la proposition. Au format OSV, les plages affectées d’un avis indiquent où une vulnérabilité a été introduite et dans quelle version elle a été corrigée. Le changement sûr le plus petit est généralement la première version corrigée sur la branche de versions que vous utilisez déjà, car c’est celle qui change le moins de choses. Passer directement à la dernière version majeure peut corriger davantage, mais c’est une mise à niveau fonctionnelle autant qu’un correctif de sécurité, et elle mérite sa propre revue.
Si le paquet vulnérable ne fait pas partie de ceux que vous déclarez, il arrive par une dépendance directe. Mettre à niveau le paquet transitif seul peut entrer en conflit avec ce qu’attend son parent ; le correctif le plus propre consiste donc généralement à mettre à niveau le parent vers une version qui résout le paquet vulnérable vers une version corrigée. Les surcharges du gestionnaire de paquets (overrides) sont une solution de repli lorsqu’une telle version n’existe pas encore ; consignez-les pour les retirer dès que le parent aura rattrapé son retard.
| Vérification | Ce qu’il faut constater |
|---|---|
| Version corrigée | L’avis de sécurité indique comme corrigée la version proposée, ou une version antérieure de la même branche. |
| Directe ou transitive | Pour un paquet transitif, la dépendance directe à faire évoluer est identifiée. |
| Diff du lockfile | Seuls les paquets attendus changent, et aucun nouveau paquet inattendu n’apparaît. |
| Notes de version | Aucun changement incompatible, aucune fonctionnalité supprimée ni aucun changement de licence. |
| Tests | La suite de tests passe et couvre le code qui utilise le paquet. |
| Origine | La version a été publiée sur le registre officiel par les mainteneurs habituels du paquet. |
Ce que le règlement sur la cyberrésilience prévoit pour la remédiation
L’annexe I, partie II, du règlement sur la cyberrésilience (Cyber Resilience Act, CRA), règlement (UE) 2024/2847, fixe les exigences de gestion des vulnérabilités applicables aux fabricants. Son point 2) leur impose, au regard des risques que présente le produit, de gérer et de corriger sans retard les vulnérabilités, y compris par des mises à jour de sécurité, et, lorsque c’est techniquement possible, de fournir les nouvelles mises à jour de sécurité séparément des mises à jour de fonctionnalité. Ce point compte lorsqu’un correctif arrive avec un saut de version important.
Le point 8) exige que, lorsque des mises à jour de sécurité sont disponibles pour remédier à des problèmes de sécurité constatés, elles soient diffusées sans retard et, sauf accord contraire avec un utilisateur professionnel pour un produit sur mesure, gratuitement, accompagnées de messages consultatifs qui indiquent aux utilisateurs ce qu’ils doivent savoir, y compris les éventuelles mesures à prendre. Le CRA ne prescrit pas la manière dont un correctif est écrit, par une personne ou avec l’IA. Ces exigences s’appliquent à partir du 11 décembre 2027.
Quand ne pas corriger : consigner qu’une vulnérabilité ne vous affecte pas
Tous les constats n’appellent pas une modification du code. Une fonction vulnérable peut n’être jamais appelée, ou la fonctionnalité concernée peut être désactivée dans votre build. Dans ce cas, une décision documentée vaut mieux qu’une mise à niveau qui introduit ses propres risques. Un document VEX (Vulnerability Exploitability eXchange) consigne, pour chaque vulnérabilité, si un produit est affecté et pourquoi, sous une forme lisible par machine que les clients et les autorités peuvent exploiter. Conservez les éléments qui étayent chaque déclaration « non affecté » et réexaminez-la quand le code change.
Disponible aujourd’hui dans KROMSE
KROMSE vous dit quoi changer et pourquoi ; une personne de votre équipe décide et effectue la modification.
- Des recommandations de mise à niveau tirées des données des avis de sécurité : la version corrigée du paquet vulnérable et, pour un paquet transitif, la dépendance directe qui l’introduit lorsque le lockfile le prouve. Aucune version n’est inventée pour ce parent.
- Un verdict IA par constat dans la limite du quota de votre offre, à côté d’une explication en langage clair.
- Des actions de réponse proposées par l’assistant IA, qu’une personne approuve ou rejette une à une.
- Les paquets malveillants signalés comme critiques, avec leur suppression pour seul remède.
- Pour les projets Go, une analyse des appels qui peut montrer si votre code appelle la fonction vulnérable.
- Export VEX aux formats CycloneDX 1.6 VEX et OpenVEX 0.2.0, et dossiers de réponse CRA avec échéances et décisions humaines consignées.
- Rien ne modifie le code : l’application GitHub fonctionne en lecture seule et KROMSE ne peut pas ouvrir de pull requests.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T4 2026 (novembre)Correctifs proposés par l’IA, approuvés par une personne. KROMSE proposera des correctifs pour les constats, rédigés avec l’IA et appliqués uniquement après l’approbation d’une personne de votre équipe.
- À venir · T4 2026 (novembre)Plug-in pour agents de codage. Un plug-in pour les agents de codage IA vérifiera chaque paquet proposé par l’agent avant son intégration, y compris les paquets qui n’existent pas ou qui n’ont été publiés que quelques jours plus tôt.
- À venir · T4 2026 (décembre)Surveillance selon votre calendrier, avec des agents IA. Les nouvelles analyses s’exécuteront selon un calendrier que vous définirez, avec des agents IA qui surveilleront les nouveaux avis de sécurité, trieront ceux qui s’appliquent, proposeront des correctifs et prépareront le rapport pour votre revue.
Questions fréquentes
Peut-on fusionner automatiquement les correctifs de code proposés par l’IA ?
Seulement là où les tests et la revue détecteraient un correctif cassé, et même dans ce cas avec prudence. Une modification proposée par l’IA peut casser une API, introduire de nouveaux paquets transitifs, changer une licence ou ne traiter qu’une partie de la vulnérabilité. L’approbation de chaque correctif par une personne nommément désignée, avec sous les yeux le diff du lockfile et les notes de version, reste le choix par défaut le plus sûr pour du code de production.
Quelle est la version sûre minimale pour une mise à niveau de dépendance ?
C’est généralement la première version que l’avis de sécurité indique comme corrigée sur la branche de versions que vous utilisez déjà. Elle supprime la vulnérabilité avec le plus petit changement de comportement. Un saut plus important, surtout d’une version majeure à l’autre, peut valoir la peine, mais c’est aussi une mise à niveau fonctionnelle qui demande sa propre revue et ses propres tests.
Comment corriger une vulnérabilité dans une dépendance transitive ?
Identifiez la dépendance directe qui introduit le paquet vulnérable, et mettez-la à niveau vers une version qui résout ce paquet vers une version corrigée. Si aucune version de ce type n’existe, une surcharge (override) du gestionnaire de paquets peut forcer la version corrigée ; consignez-la et retirez-la dès que le parent a rattrapé son retard, car une surcharge peut casser le paquet parent.
Le Cyber Resilience Act impose-t-il une remédiation automatisée ?
Non. L’annexe I, partie II, impose aux fabricants de gérer et de corriger sans retard les vulnérabilités au regard des risques, y compris par des mises à jour de sécurité, et de diffuser sans retard les mises à jour de sécurité disponibles, en règle générale gratuitement. Elle ne dit pas comment les correctifs sont produits. L’automatisation peut aider à aller vite ; les décisions documentées aident à apporter des preuves.
KROMSE applique-t-il des correctifs à mon code ?
Non. KROMSE explique chaque constat, fournit des recommandations de mise à niveau tirées des données des avis de sécurité et peut proposer des actions de réponse qu’une personne approuve ou rejette. Il ne modifie pas le code et n’ouvre pas de pull requests. Des propositions de correctifs par l’IA, appliquées uniquement après l’approbation d’une personne, figurent dans la feuille de route.