Remédiation automatisée des vulnérabilités, du résultat à la correction

Ce que signifie la remédiation automatisée des vulnérabilités

La remédiation des vulnérabilités consiste à retirer une vulnérabilité connue de votre logiciel : mettre à niveau le paquet touché, appliquer un correctif ou remplacer le composant. La remédiation automatisée confie la partie mécanique de ce travail à un logiciel. Il lit un résultat, détermine quelle version le corrige, modifie le manifeste, le lockfile ou le code, et propose la modification, le plus souvent sous forme de pull request.

Pour les dépendances tierces, où se trouve l'essentiel des vulnérabilités connues d'une base de code moderne, la boucle est la même dans tous les outils :

1. Inventorier. Savoir quels paquets, dans quelles versions, se trouvent dans chaque élément que vous livrez.
2. Rapprocher. Comparer cet inventaire aux avis, et continuer à mesure que de nouveaux avis sont publiés.
3. Prioriser. Décider quoi corriger d'abord, selon la gravité, l'exploitation et l'exposition.
4. Corriger. Choisir la version corrigée, la mettre à jour et adapter le code si la mise à niveau casse quelque chose.
5. Vérifier. Construire et tester la modification, puis confirmer que la version corrigée est bien celle qui a été livrée.
6. Consigner. Garder une trace de ce qui était touché, de la date de correction et de la release concernée.

L'automatisation est la plus efficace aux étapes 2, 4 et 6, où le travail est répétitif. Elle est la plus faible lorsque les données d'entrée sont fausses, et la donnée d'entrée de tout le reste, c'est l'étape 1.

Quatre types de remédiation automatisée

Approche	Ce qu'elle fait	Exemples	Ses limites
Bots de mise à jour des dépendances	Ouvrent des pull requests qui font passer une dépendance vulnérable à une version corrigée	Dependabot security updates, Renovate	Partent des manifestes et lockfiles du dépôt ; une mise à niveau incompatible exige toujours qu'une personne adapte le code
Pull requests de correction SCA	Ouvrent des pull requests de mise à niveau pour les résultats remontés par un outil SCA commercial	Snyk, Black Duck, Aikido, Endor Labs	La couverture varie : certains outils ne corrigent que les dépendances directes, d'autres ajoutent des correctifs ou des backports
Corrections de code par IA	Génèrent une modification de code pour un résultat, souvent une alerte d'analyse statique	GitHub Copilot Autofix	Suggestions non déterministes à relire ; voir la remédiation par l'IA
Remédiation automatique de l'infrastructure	Annule une erreur de configuration ou corrige un hôte lorsqu'une règle se déclenche	Outils de posture de sécurité cloud et de protection des terminaux	Couvre l'infrastructure en fonctionnement, pas les dépendances du logiciel que vous livrez

Les trois premières corrigent le code que vous livrez, et elles partagent une même hypothèse : que la liste de paquets vulnérables qu'elles corrigent est la bonne.

Toute correction dépend de l'inventaire

Un outil de remédiation ne peut corriger que les vulnérabilités qu'il connaît, et il connaît celles que contient son inventaire. La plupart des inventaires sont reconstitués à partir de fichiers : manifestes, lockfiles, paquets installés ou image de conteneur finalisée. Cette reconstitution laisse passer des éléments de façon prévisible.

• Les paquets que les fichiers ne déclarent pas. Les outils téléchargés par le build, les images de base, les plugins et tout ce qui est installé par un script n'apparaissent jamais dans un lockfile : aucune pull request de correction n'est donc jamais ouverte pour eux.
• Les versions différentes du lockfile. Le build peut résoudre une autre version que celle lue par un scanner, surtout sans lockfile commité. Une correction fondée sur la mauvaise version est une mauvaise réponse donnée avec assurance.
• Les paquets restaurés depuis les caches. Une dépendance en cache ne repasse jamais par le registre : ce que le build a utilisé peut donc être en retard sur ce qu'indique le dépôt.

La solution est de partir de ce que le build a réellement utilisé. Une SBOM au build est enregistrée pendant l'exécution du build : elle liste les paquets récupérés par le job, transitifs compris, plutôt que ce dont un manifeste dit avoir besoin. Une remédiation qui part de là corrige ce qui est livré.

Ce qu'il faut automatiser et ce qu'il faut garder

La plupart des équipes pour qui la remédiation fonctionne la répartissent ainsi :

• Automatisez la détection et le rapprochement. De nouveaux avis sont publiés chaque jour. Revérifier à la main chaque build livré ne passe pas à l'échelle, et c'est exactement le type de travail que les logiciels font bien.
• Automatisez la proposition. Choisir la version corrigée et ouvrir la modification est mécanique. Regroupez les mises à jour liées pour que les relecteurs voient une seule pull request au lieu de vingt.
• Conditionnez la fusion aux tests. Fusionnez automatiquement les mises à jour de sécurité de niveau patch couvertes par la suite de tests. Gardez pour une personne les mises à niveau incompatibles et tout ce qui n'est pas couvert par les tests.
• Laissez les arbitrages aux humains. Savoir si une vulnérabilité touche réellement votre produit, et si une mise à niveau risquée vaut la peine cette semaine, ce sont des décisions. Consignez-les, par exemple sous forme de déclaration VEX, pour que la même question ne soit pas posée deux fois.

Comment évaluer un outil de remédiation

Avant de laisser un outil ouvrir des pull requests sur vos dépôts, posez ces questions :

1. D'où vient sa liste de vulnérabilités : des fichiers du dépôt, d'une image analysée ou du build lui-même ?
2. Corrige-t-il les dépendances transitives, ou seulement les dépendances directes que vous déclarez ?
3. Comment choisit-il la version corrigée : la version minimale corrigée, la plus récente ou une version que vous épinglez ?
4. La correction est-elle construite et testée avant que vous ne la voyiez, ou la pull request est-elle sa première exécution ?
5. Peut-il regrouper et planifier les mises à jour pour ne pas submerger les relecteurs ?
6. Consigne-t-il quelles releases étaient touchées et quand chaque correction a été livrée ?

La place de CRACI aujourd'hui

CRACI exécute vos jobs GitHub Actions sur ses propres runners et enregistre les paquets réellement récupérés par chaque job, y compris les dépendances transitives et les paquets restaurés depuis les caches, avec un état de complétude pour chaque job. Cet enregistrement est l'inventaire dont un workflow de remédiation devrait partir.

CRACI réévalue en continu les SBOM surveillées : lorsqu'un nouvel avis est publié, vous voyez quels builds livrés il touche dans l'ensemble de vos dépôts. Les équipes de sécurité trient chaque résultat et le transmettent à l'équipe responsable de la correction, et CRACI prend en charge VEX pour consigner la façon dont une vulnérabilité touche votre produit. La SBOM du build suivant montre ensuite si la version corrigée est bien celle que le build a utilisée. La page suivi des vulnérabilités présente toutes les capacités.

En vertu du Cyber Resilience Act de l'UE, les fabricants doivent traiter et corriger les vulnérabilités sans délai, notamment par des mises à jour de sécurité. Une trace de ce que contenait chaque build et de la date de livraison de chaque correction constitue la preuve dont ce processus a besoin.

Remédiation automatisée des vulnérabilités : questions fréquentes

Qu'est-ce que la remédiation automatisée des vulnérabilités ?

La remédiation automatisée des vulnérabilités désigne un logiciel qui transforme un résultat de vulnérabilité en correction sans qu'une personne fasse le travail de fond : il détermine la version corrigée, modifie le manifeste, le lockfile ou le code, et propose la modification, généralement sous forme de pull request. Une personne, ou une politique à laquelle l'équipe fait confiance, décide toujours de ce qui est fusionné.

Quelle est la différence entre remédiation et atténuation des vulnérabilités ?

La remédiation retire la vulnérabilité, par exemple en passant à une version corrigée ou en appliquant un correctif. L'atténuation réduit le risque tant que la vulnérabilité est présente, par exemple en désactivant la fonctionnalité touchée ou en bloquant le chemin d'attaque. L'atténuation fait gagner du temps ; la remédiation clôt le résultat.

La remédiation des vulnérabilités peut-elle être entièrement automatisée ?

En partie. Trouver les builds touchés, rapprocher les avis et proposer une montée de version sont des tâches mécaniques qui s'automatisent bien. Décider si une mise à niveau incompatible est sûre, ou si une vulnérabilité touche réellement votre produit, exige encore du jugement. La plupart des équipes automatisent la proposition et gardent une personne, appuyée par les tests, pour la fusion.

Dependabot fait-il de la remédiation automatisée des vulnérabilités ?

Les Dependabot security updates ouvrent des pull requests qui font passer une dépendance vulnérable à la version minimale corrigée, pour les alertes que GitHub remonte sur le graphe de dépendances de votre dépôt. C'est de la remédiation automatisée pour ce que déclarent les manifestes et les lockfiles. CRACI face à Dependabot montre où ce qui est déclaré et ce qui est livré diffèrent.

Que rechercher dans un outil de remédiation des vulnérabilités ?

L'origine de sa liste de vulnérabilités, sa prise en charge des dépendances transitives, sa façon de choisir la version corrigée, le fait que la correction soit construite et testée avant que vous ne la voyiez, et la trace de ce qui a été corrigé et quand. Ce dernier point compte pour les audits et pour le CRA, qui demande aux fabricants de corriger les vulnérabilités sans délai.