Le conseil est toujours le même lorsqu'un outil de vulnérabilité signale une CVE : mettez à niveau. Passez à la version corrigée pour pouvoir clôturer le ticket et passer à autre chose. C'est devenu un tel réflexe que personne ne s'arrête pour se demander si cela fonctionnera réellement.
Le correctif proposé échoue de trois manières spécifiques. Il n'y a pas de version vers laquelle mettre à niveau et il n'y en aura jamais, la version corrigée n'a pas encore été livrée, ou le correctif est livré et casse votre application.
En bref, les meilleures pratiques et chaque framework, de SOC2 à ISO27001, vous disent de maintenir vos dépendances à jour. Mais la mise à niveau n'équivaut pas à une correction, et pourtant, c'est la seule réponse que de nombreux outils proposent.
Ce n'était pas toujours le mauvais instinct. Les mainteneurs (heureusement) corrigeaient les vulnérabilités dans la dernière version, et pendant des années, cela a suffi.
Les CVE sont signalées > les mainteneurs les corrigent > vous mettez à niveau > vous obtenez le correctif.
Mais les mainteneurs ne reviennent généralement pas en arrière pour corriger les anciennes versions. Les équipes se sont donc habituées à toujours mettre à niveau vers la dernière version quand elles le pouvaient, et les attaquants ont remarqué ce schéma et ont appris à l'exploiter. Maintenant, vous mettez à niveau pour corriger la CVE, il y a une chance qu'un malware se trouve quelque part dans la mise à jour, donc récupérer la dernière version n'est plus automatiquement sûr.
Plus tôt cette année, des attaquants ont compromis un compte de mainteneur responsable de certains des paquets les plus téléchargés sur npm. chalk et debug, représentant à eux deux plus de deux milliards de téléchargements par semaine. Ils ont publié des versions malveillantes via le canal officiel, et chaque pipeline configuré pour la mise à jour automatique les a directement intégrées. Les équipes suivant les meilleures pratiques livraient des malwares en quelques minutes.
C'est une situation perdant-perdant. Vous restez à jour et risquez d'introduire des malwares, ou vous vous figez et accumulez de la dette de sécurité. C'est ce que nous appelons le piège de la mise à niveau. La version que vous utilisez et les correctifs de sécurité qui lui sont appliqués ne sont pas nécessairement liés.
Les trois scénarios d'échec de la mise à niveau
Bien sûr, la « mise à niveau » fonctionne la plupart du temps et reste importante. Mais il existe trois situations où elle échoue.
Le premier cas est lorsqu'il n'y a pas de version corrigée vers laquelle migrer (et il n'y en aura jamais). Prenez request, l'un des clients HTTP les plus utilisés dans Node, qui est déprécié depuis 2020. Et pourtant, il apparaît toujours partout, généralement importé par un package parent que personne n'a touché depuis des lustres. Lorsque vous exécutez un outil SCA sur `request`, l'outil détecte une CVE pour un contournement d'atténuation de la falsification de requêtes côté serveur (SSRF). Devinez quelle est la solution ici selon l'outil SCA ? Oui, la mise à niveau.
Mais le problème est qu'il n'y a rien vers quoi mettre à niveau, et il n'y en aura jamais. request n'a pas été maintenu depuis des années. L'avis de sécurité le dit clairement, notant que la faille n'affecte que les versions que le mainteneur ne prend plus en charge (c'est-à-dire toutes les versions). Dans ce cas, « mettre à niveau » signifie en fait retirer request et passer à quelque chose comme axios ou node-fetch. C'est une réécriture et une migration, ce qui signifie que tant que personne n'aura le temps de s'en occuper, la CVE restera en suspens.
Cela suppose que le correctif doit provenir du mainteneur. Pour les packages en fin de vie (EOL), quelqu'un doit encore comprendre la vulnérabilité et écrire un correctif pour la version déjà utilisée. Les distributions font cela pour les packages au niveau du système d'exploitation depuis des années. La même approche existe désormais pour les bibliothèques d'applications, ce qui est le point de blocage pour la plupart des équipes.
Le deuxième type de mise à niveau est lorsque le correctif n'existe pas encore même si le package est actif. La bibliothèque populaire lodash a passé une période l'année dernière avec deux vulnérabilités divulguées affectant toutes les versions publiées jusqu'à la version 4.17.23 incluse. Comme c'était la dernière version, il n'y avait rien vers quoi mettre à niveau. npm audit a signalé les CVEs et a indiqué qu'aucun correctif n'était disponible. Ainsi, même si le conseil de mise à niveau était judicieux, il n'était pas réellement réalisable car la version patchée n'avait pas été publiée.
Le troisième cas est lorsque le correctif est publié et casse votre application. CVE-2026-48937 dans Node est un exemple récent. Le correctif de la vulnérabilité était fourni avec une SEMVER-MAJOR mise à jour de la nghttp2 dépendance et la suppression du support 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 n'y avait donc aucun moyen d'appliquer le correctif de sécurité sans introduire le changement cassant en même temps. Les utilisateurs devaient rechercher (avec grep) setPriority et .priority() et les supprimer avant de pouvoir effectuer une mise à niveau.
C'est le risque inhérent à toute mise à jour. Une nouvelle version peut modifier le comportement d'un package au point de casser quelque chose qui fonctionnait, forcer d'autres dépendances à être mises à jour en même temps, ou arriver sous forme de version majeure nécessitant une migration avant même son installation.
Et pour aller plus loin, si vous mettez à jour un package, vous pourriez devoir en mettre à jour cinq autres. L'un d'eux pourrait casser quelque chose dont votre système dépend. L'équipe d'ingénierie doit alors choisir entre un élément de la feuille de route qui génère des revenus et la mise à jour. Devinez lequel l'emporte 😬. Vous vous retrouvez alors avec de la dette technique et une accumulation de CVE.
Comment l'IA a rebattu les cartes
La plupart des entreprises ont un backlog de CVE trop important pour être traité, et elles sont nerveuses car les derniers modèles de pointe peuvent trouver des vulnérabilités plus rapidement. Mais ce qui est plus menaçant, c'est qu'ils peuvent enchaîner des CVE de gravité moyenne de manière à les transformer en un schéma d'exploitation critique. Le modèle actuel de scan, de tri et de répartition de ce travail aux ingénieurs ne s'adapte pas assez rapidement pour gérer ce problème. L'IA aggrave en fait un problème existant et rend sa résolution plus urgente pour les organisations.
Les solutions de l'industrie
La mise à niveau a longtemps été la seule réponse réaliste. Les arriérés de CVE et les builds cassés qui en ont résulté étaient une conséquence prévisible de l'ensemble limité de choix. Il existe globalement trois approches à ce problème. Deux d'entre elles échangent un problème contre un autre. La troisième se rapproche le plus de la fermeture effective de la CVE sans en créer une nouvelle.
La première est le filtrage au point de consommation. Avant qu'un package n'atteigne votre build, il est vérifié : cette dépendance est-elle sûre à installer ? C'est une couche nécessaire, surtout après des attaques comme chalk et debug. Mais cela ne convient pas aux packages vulnérables déjà en production. C'est une barrière plutôt qu'un correctif et, en dehors de ce périmètre, la réponse reste la mise à niveau.
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 pousse vers un écosystème propriétaire qu’elles ne contrôlent pas. 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 entreprises n’ont ni les moyens, ni l’expertise, ni l’envie de le faire. Lorsqu’une vulnérabilité CVE est corrigée en amont, le fragment de code le plus restreint permettant de la corriger est isolé de la nouvelle version et appliqué 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 pratiquent cette approche depuis des années. Le faire à l’échelle des bibliothèques d’applications, de manière automatique, au rythme où les vulnérabilités CVE apparaissent, est un tout autre problème. Pour les paquets en fin de vie (EOL) pour lesquels aucun correctif en amont n’est prévu, quelqu’un doit tout de même comprendre la vulnérabilité et rédiger un correctif pour la version déjà en usage. Ce même travail existe désormais sous forme d’option évolutive pour les bibliothèques d’applications, ce qui représente le principal obstacle pour la plupart des équipes. Le seul cas où cela ne s’applique pas est celui où aucun correctif en amont n’existe encore. Si le responsable de maintenance n’a pas rédigé le correctif, il n’y a rien à isoler ni à appliquer. Le CVE reste en suspens jusqu’à ce que quelqu’un s’en charge.
Vous conservez la version à laquelle votre application fait déjà confiance, appliquez uniquement le correctif, et vous n'accumulez pas de CVEs contre une version figée ni ne tirez la dernière version avec tout ce qui l'accompagne.
Considérez votre stack logicielle comme une maison dans laquelle vous vivez depuis des années. La plupart des outils soit filtrent ce qui entre par la porte, vous donnent une liste de réparations et vous disent de vous en occuper, soit vous demandent de déménager dans une nouvelle maison plus petite qu'ils ont construite. Réparer la maison dans laquelle vous vivez déjà est ce que la plupart des équipes veulent réellement.
Il existe maintenant une option qui fait exactement cela : corriger les vulnérabilités dans les packages open source dont votre application dépend sans les mettre à jour avec Aikido Libraries.
