Le conseil est toujours le même lorsqu'un outil de détection des vulnérabilités signale un CVE : effectuez une mise à jour. Passez à la version corrigée afin de pouvoir clore le ticket et passer à autre chose. C'est devenu un tel réflexe que personne ne prend le temps de se demander si cela fonctionnera réellement.
La solution proposée présente trois problèmes spécifiques. Soit il n'existe aucune version vers laquelle effectuer la mise à jour et il n'y en aura jamais, soit la version corrigée n'a pas encore été publiée, soit la solution est publiée mais rend votre application inutilisable.
En résumé, les bonnes pratiques et toutes les normes, de SOC2 à ISO 27001, recommandent de maintenir vos dépendances à jour. Mais la mise à jour n'équivaut pas à une correction, et pourtant c'est la seule solution proposée par de nombreux outils.
Ce n'était pas toujours un mauvais réflexe. Les responsables de maintenance (heureusement) corrigeaient les vulnérabilités dans la dernière version, et pendant des années, cela a suffi.
Des CVE sont signalées > les responsables de maintenance les corrigent > vous effectuez la mise à jour > vous bénéficiez du correctif.
Mais les responsables de maintenance ne reviennent généralement pas en arrière pour corriger les anciennes versions. Les équipes ont donc pris l'habitude de toujours passer à la version la plus récente dès qu'elles le pouvaient, et les pirates ont remarqué ce schéma et ont appris à l'exploiter. Désormais, lorsque vous effectuez une mise à jour pour corriger une vulnérabilité CVE, il existe un risque que la mise à jour contienne un logiciel malveillant ; par conséquent, le fait de télécharger la dernière version n’est plus automatiquement sans danger.
Au début de l'année, des pirates ont compromis le compte d'un responsable de maintenance chargé de certains des paquets les plus téléchargés sur npm : « chalk » et « debug », qui totalisent à eux deux plus de deux milliards de téléchargements par semaine. Ils ont publié des versions malveillantes via le canal officiel, et tous les pipelines configurés pour la mise à jour automatique les ont immédiatement intégrées. Des équipes qui suivaient les bonnes pratiques se sont ainsi retrouvées à diffuser des logiciels malveillants en l'espace de quelques minutes.
C'est une situation perdant-perdant. Soit vous restez à jour et vous prenez le risque d'introduire des logiciels malveillants, soit vous restez figé et vous accumulez un retard en matière de sécurité. C'est ce que nous appelons le « piège de la mise à jour ». La version que vous utilisez et les correctifs de sécurité qui lui sont appliqués ne doivent pas nécessairement relever du même choix.
Les trois raisons pour lesquelles une mise à niveau peut échouer
Bien sûr, la « mise à niveau » fonctionne la plupart du temps et reste importante. Mais il existe trois situations où elle ne fonctionne pas.
Le premier cas se présente lorsqu'il n'existe pas de version définitive vers laquelle migrer (et qu'il n'y en aura jamais). Prenons demande, l’un des clients HTTP les plus utilisés dans Node, qui est obsolète depuis 2020. Et pourtant, on le retrouve encore partout, généralement introduit par un paquet parent que personne n’a touché depuis une éternité. Lorsque vous lancez un SCA sur request, celui-ci signale un CVE lié au contournement des mesures de protection contre la falsification de requêtes côté serveur (SSRF). Devinez quelle est la solution proposée par SCA ? Eh oui, effectuer une mise à jour.
Mais le plus grave, c'est qu'il n'y a rien vers quoi évoluer, et qu'il n'y aura jamais rien. request n'a pas été mis à jour depuis des années. L'avis le dit d'ailleurs clairement, en précisant que la faille ne concerne que les versions que le responsable de la maintenance ne prend plus en charge (c'est-à-dire toutes les versions). Dans ce cas précis, « mettre à jour » revient donc en réalité à désinstaller request abandonner cela pour passer à quelque chose comme axios ou node-fetch. Il s'agit à la fois d'une réécriture et d'une migration, ce qui signifie que tant que personne n'aura le temps de s'en occuper, le CVE restera en suspens.
Le deuxième type de mise à jour concerne les cas où le correctif n'existe pas pourtant même si le module est actif. La bibliothèque très répandue lodash L'année dernière, le logiciel a fonctionné pendant un certain temps avec deux failles de sécurité connues qui affectaient toutes les versions publiées jusqu'à la version 4.17.23 incluse. Comme il s'agissait de la dernière version disponible, il n'y avait pas de mise à jour possible. npm audit a signalé les CVE et indiqué qu'aucun correctif n'était disponible. Ainsi, même si la recommandation de mise à jour était pertinente, elle n'était en réalité pas applicable, car la version corrigée n'avait pas encore été publiée.
Le troisième cas de figure, c'est lorsque le correctif est déployé et qu'il provoque un dysfonctionnement de votre application. CVE-2026-48937 dans Node en est un exemple récent. Le correctif de cette vulnérabilité était inclus dans une SEMVER-MAJOR mise à jour de la nghttp2 la dépendance et la suppression de la prise en charge de la signalisation de priorité HTTP/2. Le comportement vulnérable et la fonctionnalité supprimée faisaient partie du même code sous-jacent ; il était donc impossible d'appliquer le correctif de sécurité sans intégrer en même temps cette modification rompant la compatibilité. Les utilisateurs devaient rechercher à l'aide de la commande « grep » définir la priorité et .priority() et les éliminer avant même qu'ils aient pu se renforcer.
C'est le risque inhérent à toute mise à jour. Une nouvelle version peut modifier le comportement d'un paquet au point de perturber le fonctionnement d'un élément qui marchait auparavant, obliger d'autres dépendances à être mises à jour en même temps, ou s'agir d'une version majeure nécessitant une migration avant même de pouvoir être installée.
Et pour aller encore plus loin, si vous mettez à jour un paquet, vous devrez peut-être en mettre cinq autres à jour. L’un d’entre eux pourrait causer une défaillance d’un élément dont dépend votre système. L’équipe d’ingénierie se retrouve alors face à un choix : privilégier un projet de la feuille de route qui génère des revenus ou procéder à la mise à jour. Devinez lequel l’emporte 😬. Vous vous retrouvez alors avec une dette technique et une accumulation de CVE.
Comment l'IA a changé la donne
La plupart des entreprises ont un arriéré de CVE trop important pour pouvoir le traiter, et elles s’inquiètent car les derniers modèles d’intelligence artificielle sont capables de détecter les vulnérabilités plus rapidement. Mais ce qui constitue une menace encore plus grande, c’est qu’elles peuvent enchaîner des CVE de gravité moyenne de manière à en faire un schéma d’exploitation critique. Le modèle actuel, qui consiste à analyser, trier et tenter de répartir ce travail entre les ingénieurs, ne s’adapte pas assez rapidement pour gérer ce problème. L’IA ne fait qu’aggraver un problème existant et rend sa résolution encore plus urgente pour les organisations.
Comment le secteur réagit-il face à cette situation ?
Pendant longtemps, la mise à jour a été la seule solution réaliste. Les retards dans le traitement des CVE et les builds défaillants qui en ont découlé étaient une conséquence prévisible de ce choix limité. Il existe globalement trois approches pour résoudre ce problème. Deux d'entre elles consistent à remplacer un problème par un autre. La troisième permet quant à elle de résoudre le CVE sans risquer d'en créer un nouveau.
La première consiste à effectuer un filtrage au point de consommation. Avant qu’un paquet n’atteigne votre environnement de production, il est vérifié : cette dépendance peut-elle être installée en toute sécurité ? Il s’agit d’une couche de sécurité indispensable, en particulier après des attaques telles que « chalk » et « debug ». Cependant, cette approche ne s’applique pas aux paquets vulnérables déjà en production. Il s’agit davantage d’un filtre que d’une solution de correction, et en dehors de ce cadre, la seule solution reste la mise à jour.
La deuxième consiste à faire migrer les équipes vers une pile de remplacement sécurisée. Au lieu de corriger ce que les équipes utilisent déjà, on les contraint à adopter l’écosystème propriétaire d’un tiers. Cela peut fonctionner pour les applications développées à partir de zéro, mais pour les systèmes de production liés à des bibliothèques et des images de base spécifiques, cela transforme la correction en un projet de migration. Une fois que l’on s’y est engagé, en sortir devient un projet à part entière.
La troisième solution consiste à rétroporter le correctif vers la version déjà en service. La plupart des organisations n’ont ni les capacités, ni l’expertise, ni l’envie de le faire. Lorsqu’un CVE est corrigé en amont, la partie de code la plus restreinte permettant de le corriger est isolée de la nouvelle version et appliquée proprement à l’ancienne version que vous utilisez déjà. Vérifier qu’aucun autre élément n’a été modifié nécessite une véritable expertise et une maintenance continue. Les distributions Linux pratiquent cette approche depuis des années. Mais l’appliquer à l’ensemble des bibliothèques d’applications, de manière automatique et au rythme où les CVE apparaissent, est un tout autre problème. Cette approche vous permet de conserver la version à laquelle votre application fait déjà confiance, d’appliquer uniquement le correctif, et ainsi d’éviter d’accumuler des CVE sur une version figée ou de devoir récupérer la dernière version avec tout ce qu’elle implique.
Considérez votre pile logicielle comme une maison dans laquelle vous vivez depuis des années. La plupart des outils se contentent soit de filtrer ce qui passe la porte, soit de vous remettre une liste de réparations en vous laissant le soin de vous en occuper, soit de vous demander d’emménager dans une nouvelle maison, plus petite, qu’ils ont construite. Ce que la plupart des équipes souhaitent réellement, c’est rénover la maison dans laquelle elles vivent déjà.
Il existe désormais une option qui permet justement cela : corriger les failles de sécurité dans les bibliothèques open source dont dépend votre application sans avoir à effectuer de mise à jour, grâce à Aikido .
