Évaluer un correctif proposé

Les familles de correctifs

Une fois une CVE confirmée comme réellement exposée, plusieurs stratégies sont possibles :

• Mise à jour de version — la plus simple, quand une version corrigée existe et reste compatible.
• Override ciblé (forcer une sous-dépendance à une version patchée, sans toucher au paquet parent) — utile quand la dépendance directe n'a pas encore publié de correctif.
• Contournement — désactiver ou remplacer la fonctionnalité vulnérable si elle n'est pas indispensable.

Ce qu'il faut vérifier avant d'accepter

Un correctif "qui compile" n'est pas forcément un bon correctif — encore faut-il se poser trois questions :

1. Breaking changes : la mise à jour change-t-elle une API utilisée ailleurs dans le projet ?
2. Portée réelle du fix : le correctif corrige-t-il vraiment le chemin de code identifié comme vulnérable, ou seulement une partie du problème ?
3. Risque relatif : le risque introduit par le changement (régression, incompatibilité) est-il plus faible que le risque de laisser la vulnérabilité telle quelle ?

Dans la grande majorité des cas, la réponse la plus simple — une mise à jour de version mineure ou de patch — suffit et ne casse rien. Mais ça reste une vérification à faire, pas une hypothèse par défaut : une mise à jour majeure peut très bien exiger une revue de code plus large avant d'être acceptée.

Le rôle du correctif dans la mission

Le correctif proposé par l'agent n'est qu'une proposition, jamais une exécution. La décision de l'appliquer — et la responsabilité de cette décision — reste humaine. Le module suivant détaille les garde-fous qui encadrent tout ça.