Un pont reste en service pendant cinquante ans selon un calendrier d'inspection fixe ; il est soumis à des essais de charge et entretenu tout au long de cette période. Un réacteur d'avion de la même conception vole pendant des décennies sous une surveillance réglementaire constante. Dans la plupart des disciplines d'ingénierie, l'objectif est d'associer une conception stable et éprouvée à une maintenance active. Les nouvelles conceptions font l'objet d'un examen bien plus minutieux, car elles n'ont jamais été véritablement testées.
Mais pour une raison quelconque, dans le domaine du génie logiciel, c’est l’inverse qui se vérifie. La version la plus récente est considérée comme la plus sûre. Et cette tendance s’est déjà lourdement retournée contre nous par le passé. Une porte dérobée se trouvait dans deux versions spécifiques de xz-utils, versions 5.6.0 et 5.6.1, implantées par un infiltré qui avait passé deux à trois ans à manigancer pour obtenir les droits de publication. Les utilisateurs qui utilisaient encore l’ancienne version 5.4 x n’ont jamais été exposés, mais ceux qui avaient téléchargé la dernière version — ce que les équipes de sécurité sont généralement invitées à faire — utilisaient une connexion SSH comportant une porte dérobée. Les recommandations émises par la CISA par la suite consistaient à revenir à une version antérieure plutôt qu’à effectuer une mise à jour.
Nous l'avons déjà expliqué dans ce que nous appelons «le piège de la mise à niveau», selon laquelle appliquer un correctif dès l'apparition d'une vulnérabilité CVE revient à faire de fausses économies ; vous devez choisir entre geler le système et accepter les changements qu'entraîne le correctif. xz-utils nous montre l'envers de la même médaille. Rester sur place était le choix le plus prudent, tandis que cette dernière sortie s'est avérée être un piège.
Une façon de vérifier cela consiste à demander à une équipe de sécurité le nombre de CVE ouverts : elle devrait pouvoir vous répondre sans hésiter. Mais si vous demandez pourquoi un paquet ou une image de conteneur spécifique utilise la version qu’il utilise, vous obtiendrez très probablement un « je ne sais pas ». C'est comme ça, n'est-ce pas? En général, cela dépend de ce qui était disponible au lancement du projet, et la mise à jour semblait demander plus d'efforts que cela n'en valait la peine. Pour aller plus loin, si vous demandez à voir une trace écrite de cette décision, vous obtiendrez probablement une réponse plus sèche du genre «pourquoi devrions-nous même faire ça? ».
Alors, où est-ce que ça coince ?
On laisse souvent croire aux ingénieurs qu'une image de conteneur ou un paquet présente davantage de risques lorsque son numéro de version est obsolète. Mais le xz-utils Cet exemple prouve que ce n'est pas vrai ; l'ancienne version était sûre car aucun code malveillant ne l'avait encore atteinte, et les équipes qui l'utilisaient ne s'étaient pas précipitées pour adopter la toute dernière version dès sa sortie. Il est bien sûr possible que de nombreuses équipes n'aient tout simplement pas eu le temps de la mettre à jour, alors qu'elles en avaient l'intention. C'est tout de même mieux que de ne pas savoir quelle version on utilise, ni pourquoi, ce qui constitue en réalité l'échec dans cette affaire.
Les équipes doivent plutôt garder à l’esprit que si elles disposent d’une version d’une bibliothèque qui a été testée, comprise et qui inspire confiance, il est réellement utile de la maintenir stable. La surveillance commence dès qu’un développeur, un agent ou un pipeline de compilation demande une image de base de conteneur ou un paquet open source, en l’évaluant avant qu’il n’entre dans l’environnement. C’est la première décision d’une chaîne de décisions qui s’ensuit.
Une mise à niveau, c'est aussi un choix
À un moment donné, une nouvelle version sortira, mais corriger une vulnérabilité CVE implique d’accepter également tout le reste de ce qui a été livré dans cette version. Cela inclut notamment les dépendances transitives, les paramètres par défaut modifiés et les chemins de code que personne au sein de l’équipe n’a lus. La plupart du temps, ce risque est invisible et tout se passe bien. Mais, et c’est un gros « mais », cela peut mal tourner. lodash a connu en 2026 une période marquée par une vulnérabilité d'injection de code arbitraire, qui touchait toutes les versions publiées. Lorsque le correctif a finalement été déployé sous la forme de la version 4.18.0, il a immédiatement cessé de fonctionner, car le correctif remplaçait une fonction interne par une autre qui n'avait jamais été importée, ce qui a entraîné l'échec de projets réels en l'espace d'une journée.
La version a été immédiatement dépréciée, avec une note renvoyant les utilisateurs vers lodash 4.17.21 à la place. Ce changement cassant n'avait rien à voir avec la vulnérabilité elle-même ; il s'agissait d'une erreur de packaging incluse par mégarde avec le correctif de sécurité. Le véritable correctif est arrivé avec la version 4.18.1.
Aucune des options disponibles n'était réellement sûre. La mise à niveau vers la version 4.18.0 cassait les builds immédiatement. Rester sur la version 4.17.21 maintenait la vulnérabilité ouverte, tandis que toutes les versions antérieures à la version 4.18.0 restaient exploitables. Certaines équipes sont redescendues à la version 4.17.x précisément pour Escape le build cassé, sacrifiant ainsi un build fonctionnel au profit d'une voie d'injection de code active, sans forcément réaliser que c'était le compromis qu'elles venaient de faire.
Dans ce cas, les équipes les mieux armées étaient celles qui savaient si leur propre application faisait appel au _.template path concerné avec des entrées non fiables, et qui pouvaient peser le pour et le contre de cette exposition réelle face à l'alternative cassée, plutôt que de choisir une option par défaut sans savoir ce qu'elle leur coûtait réellement.
Corriger la vulnérabilité sans tout remplacer autour
Le rétroportage change la donne. Il prend le correctif spécifique d'une vulnérabilité donnée et l'applique à la version en cours d'exécution, plutôt que d'embarquer tout le reste qui a été publié en amont. Appliquez-le à une image de conteneur, et la CVE est résolue sans imposer une nouvelle image de base. Appliquez-le à un paquet, et le même correctif est appliqué sans forcer le saut vers la dernière version — ce fameux saut qui a cassé de vrais projets exécutant lodash 4.18.0. Vous pouvez résoudre le problème de sécurité sans modifier tout ce qui l'entoure.
Un SBOM doit mériter sa place et ne pas se contenter d'exister
Un SBOM, à l'image de tant de documents liés à la conformité, est souvent généré une fois puis archivé. Il indique ce qui se trouvait dans le système le jour où le rapport a été exécuté. Mais un SBOM peut faire bien plus pour votre posture de sécurité. Il peut servir de référence logicielle de confiance et vous aider à gérer cette référence en continu. Pour cela, vous devez veiller à ce qu'il soit tenu à jour et confronté aux nouvelles divulgations dès leur apparition. C'est pour moi le signe le plus évident qu'une organisation continue de suivre les logiciels qu'elle exécute au lieu de se contenter de ce qui est déjà en place.
Nous voulons que le SBOM devienne bien plus qu'un simple inventaire ou un artefact de conformité. Il doit constituer une surface régie et activement maintenue.
Alors, qu'est-ce qui doit changer ?
Toutes ces décisions doivent être prises. Certaines concernent un composant logiciel spécifique à un moment donné, comme l'évaluation d'une requête, le verrouillage d'une version et le rétroportage au lieu de forcer une mise à niveau. D'autres, comme le fait de maintenir un SBOM à jour, relèvent des processus mis en place. Chacune de ces décisions revient finalement à choisir ce en quoi l'on peut avoir confiance.
Le plus simple est de laisser les choses en l'état, parce que « ça marche ». Mais « ça marche » n'est pas vraiment vrai, n'est-ce pas ? Ce n'est pas parce qu'un système fonctionne qu'il fonctionnera toujours, ni que c'est la manière la plus sûre de procéder, ni que c'est la meilleure façon de fonctionner.
De notre point de vue, l'approche la plus proactive et la plus consciente de la sécurité consiste à contrôler le changement dès le point d'entrée : évaluer les paquets avant qu'un développeur, un agent ou un système de build ne les consomme. À partir de là, vous devez avoir la liberté de décider proactivement de ce qui entre, de verrouiller ce en quoi vous avez confiance, de le maintenir et de ne le modifier qu'en cas de nécessité.
Rester sur une version ne doit pas signifier rester exposé. Aikido Libraries rétroporte le correctif sur la version que vous utilisez déjà, sans mise à niveau forcée ni migration forcée. Commencez à corriger ici.
