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.
npm a purement et simplement abandonné cette version et a conseillé aux utilisateurs de revenir à lodash 4.17.21 Au contraire. Ce changement entraînant une incompatibilité n'avait rien à voir avec la faille elle-même ; il s'agissait d'une erreur de packaging qui s'était glissée dans le correctif de sécurité. Le correctif proprement dit a été intégré à la version 4.18.1.
Aucune des options envisagées n'était réellement sûre. La mise à niveau vers la version 4.18.0 a immédiatement entraîné des erreurs de compilation. Rester sur la version 4.17.21 laissait la vulnérabilité ouverte, tandis que toutes les versions antérieures à la 4.18.0 restaient exploitables. Certaines équipes sont revenues à la version 4.17.x dans le but précis d’ escape r la compilation défaillante, troquant ainsi une compilation fonctionnelle contre une faille d’injection de code active, sans nécessairement se rendre compte du compromis qu’elles avaient fait.
Dans ce cas précis, les équipes les mieux placées étaient celles qui savaient si leur propre application appelait ou non la fonction _ concernée.template un chemin comportant des données d’entrée non fiables, et pourraient mettre en balance ce risque réel et l’alternative défaillante, plutôt que d’opter par défaut pour l’une ou l’autre de ces solutions sans en connaître le coût réel.
Corriger la faille de sécurité sans tout remplacer autour d'elle
Le « backport » change la donne. Il consiste à prendre le correctif spécifique à une vulnérabilité donnée et à l’appliquer à la version déjà en cours d’exécution, plutôt que d’intégrer toutes les autres modifications fournies en amont avec celle-ci. En l’appliquant à une image de conteneur, la vulnérabilité CVE est corrigée sans imposer une nouvelle image de base. En l’appliquant à un paquet, le même correctif est appliqué sans imposer le passage à la dernière version, ce qui est précisément ce qui a causé des problèmes dans des projets réels en cours d’exécution. lodash 4.18.0. Vous pouvez résoudre le problème de sécurité sans avoir à tout modifier autour.
Une « SBOM » doit mériter sa place, et pas simplement exister.
Un SBOM, comme tant d’autres documents liés à la conformité, est souvent consulté une seule fois puis classé. Il vous indique ce qui se trouvait dans le système le jour où quelqu’un a généré le rapport. Mais ce SBOM peut apporter bien plus à votre posture de sécurité que cela. Il peut servir de référence logicielle fiable et vous aider à gérer cette référence en continu. Pour ce faire, vous devez vous assurer qu’il est tenu à jour et que son contenu est vérifié à la lumière des nouvelles vulnérabilités au fur et à mesure de leur publication. C’est pour moi le signe le plus évident qu’une organisation continue de suivre de près les logiciels qu’elle utilise, plutôt que de se contenter de ce qui existe déjà.
Nous souhaitons que l’ SBOM e ne soit pas simplement un inventaire ou un élément de conformité. Il doit s’agir d’une interface régie et activement mise à jour.
Alors, que faut-il changer ?
Ce sont toutes des décisions qu’il faut prendre. Certaines concernent un composant logiciel spécifique à un moment donné, comme l’évaluation d’une demande, le gel d’une version ou le portage vers une version antérieure plutôt que d’imposer une mise à niveau. D’autres, comme le choix de maintenir ou non une SBOM à jour, portent sur les processus que vous avez mis en place. Chacune de ces décisions revient en réalité à choisir en quoi faire confiance.
Le plus simple serait de laisser les choses telles quelles, car « ça marche ». Mais « ça marche » n'est pas vraiment vrai, n'est-ce pas ? Ce n'est pas parce qu'une chose fonctionne qu'elle 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 faire.
De notre point de vue, l’approche la plus proactive et la plus soucieuse de la sécurité consisterait à contrôler les changements dès leur point d’entrée : évaluer les paquets avant qu’un développeur, un agent ou un système de compilation ne les utilise. À partir de là, vous devriez avoir la liberté de décider de manière proactive ce qui entre dans votre système, de verrouiller ce en quoi vous avez confiance, de le maintenir et de ne le modifier que lorsque cela est justifié.
Rester sur une version ne devrait pas signifier rester exposé. Aikido Les bibliothèques réintègre le correctif dans la version que vous utilisez déjà, sans mise à jour forcée ni migration forcée. Commencez à appliquer les correctifs ici.
