Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Les logiciels en fin de vie continuent généralement de fonctionner normalement, mais dès lors que les correctifs de sécurité en amont cessent d'être fournis, les vulnérabilités nouvellement découvertes risquent de ne plus faire l'objet d'un correctif en amont.
- La mise à niveau d'une dépendance en fin de vie (EOL) se résume rarement à un simple changement de version, car les API incompatibles, les dépendances transitives et les tests de régression peuvent en faire un projet d'ingénierie s'étalant sur plusieurs semaines.
- Les fichiers de verrouillage, la surveillance des dépendances et la prise en charge étendue du cycle de vie ne suppriment pas la nécessité de migrer, mais ils vous permettent de le faire selon votre propre calendrier, plutôt que lors d'un incident.
Dans le développement moderne, chaque npm install est un acte de confiance. Vous intégrez du code que vous n’avez pas écrit, maintenu par des personnes que vous n’avez jamais rencontrées, selon un calendrier de support que personne ne vous a jamais promis. Cette confiance se heurte à un mur lorsqu’une bibliothèque principale, un framework, un runtime ou toute autre dépendance arrive en fin de vie (EOL).
Pour un développeur débutant, un logiciel en fin de vie peut n'apparaître que comme un simple avertissement agaçant dans un rapport de dépendances. L'application continue de se compiler. L'environnement de production fonctionne toujours. Rien ne semble ne pas fonctionner, et c'est précisément pour cette raison qu'il est si facile de sous-estimer la fin de vie d'un logiciel.
Une fois que le support en amont prend fin, les correctifs de sécurité pour cette version cessent également d'être fournis. Le logiciel peut continuer à fonctionner pendant des années. Mais la prochaine vulnérabilité qui le touchera pourrait ne pas faire l'objet d'un correctif en amont, et le conseil que l'on vous donnera – « il suffit de le mettre à jour » – est suffisamment souvent erroné pour s'avérer dangereux.
La réalité du drapeau rouge
Pour démystifier la fin de vie d'un logiciel, il faut en comprendre les enjeux avant que cela ne devienne une urgence. La fin de vie n'est pas nécessairement synonyme de défaillance technique, et elle n'est pas imputable au développeur qui a installé le logiciel. Les logiciels ont un cycle de vie, et les responsables de leur maintenance doivent, à un moment donné, consacrer leur temps et leurs ressources à d'autres projets.
La distinction qui importe est la suivante : un logiciel qui fonctionne n'est pas la même chose qu'un logiciel bénéficiant d'un support technique.
Lorsqu’une version atteint sa fin de vie (EOL), le fournisseur ou la communauté en amont cesse généralement de publier des correctifs de sécurité pour celle-ci. Cela ne signifie pas pour autant que le code devient vulnérable du jour au lendemain. Cela signifie simplement que si une vulnérabilité affectant cette version est découverte ultérieurement, il se peut qu’aucun correctif en amont ne soit plus disponible. Je compare cela à une serrure dont plus personne ne détient la clé. La porte est encore verrouillée aujourd’hui, mais si quelqu’un trouve demain le moyen de la forcer, personne en amont ne reviendra pour la remplacer.
Vous pouvez également consulter notre guide complet sur la différence entre « fin de vie » et « fin de support » afin de mieux comprendre en quoi les définitions des éditeurs concernant le cycle de vie des produits influent sur votre niveau de sécurité.
Détecter la fin de vie avant qu'elle ne vous rattrape
Presque rien ne le laisse deviner. Un paquet n'affiche pas d'avertissement lors de l'installation indiquant que le responsable a trouvé un emploi ailleurs en 2022 et a cessé de répondre aux tickets. Il faut chercher soi-même, et les indices laissant penser qu'une dépendance est peut-être en fin de vie, obsolète ou, dans les faits, plus maintenue se trouvent généralement à la vue de tous :
- Une note d'obsolescence dans la fiche du registre, indiquant parfois un paquet de remplacement, parfois rien du tout
- Une date de dernière publication bien postérieure au rythme habituel de publication du projet
- Un seul responsable, ou une liste de responsables dont tous les comptes sont désormais inactifs
- Rapports de sécurité ouverts dans le système de suivi des problèmes et restés sans réponse
- Un tableau de prise en charge publié qui s'arrête discrètement à une version que vous avez dépassée il y a deux versions
- CI configuré pour effectuer des tests uniquement sur des versions d'exécution qui sont elles-mêmes en fin de vie (EOL)
Il est utile de suivre les dates de fin de vie publiées, mais ce ne sont pas des promesses. Node.js 16 est l’exemple sur lequel je reviens sans cesse : sa fin de vie était initialement prévue pour avril 2024, puis a été avancée de sept mois au 11 septembre 2023, afin de coïncider avec la fin du support de la bibliothèque OpenSSL 1.1.1 intégrée à Node.js. Les équipes qui s'étaient fixées Node 16 comme référence et avaient prévu une migration pour mi-2024 ont perdu près d'un an de marge de manœuvre à cause d'une décision prise en amont.
Si un paquet est officiellement obsolète et qu’un successeur a été désigné, commencez dès maintenant à définir le périmètre de la migration, tant que la situation n’est pas encore critique. S’il est simplement dépassé mais toujours fonctionnel, verrouillez-le, ajoutez-le à une liste de suivi et inscrivez son remplacement dans le backlog en désignant un responsable.
API défaillantes et tests de régression
Au fil des ans, j'ai entendu d'innombrables fois ce vieil adage : « Il suffit de le mettre à jour ». Nous sommes tous passés par là : on commence par se familiariser avec les complexités de la production, puis, à mesure qu'on accède à des postes à responsabilités, notre vision s'approfondit. Les développeurs expérimentés savent que l'abandon d'une bibliothèque en fin de vie (EOL) se résume rarement à un simple changement de numéro de version.
Une mise à jour majeure peut entraîner des modifications radicales de l'API, la dépréciation de certaines fonctions, l'incompatibilité de certains plugins et une évolution des exigences d'exécution. Même de légères modifications des dépendances peuvent nécessiter des tests de régression sur tous les éléments qui en dépendent ; or, sur une application réelle, ces tests peuvent prendre plusieurs jours, voire plusieurs semaines.
Imaginez une équipe SaaS de 40 personnes qui utilise encore cette version de base de Node 16 en fin de vie. La mise à niveau du runtime peut à elle seule entraîner la recompilation de modules natifs, l’utilisation d’un exécuteur de tests qui n’accepte plus l’ancien format de configuration, ainsi que la mise à jour d’une poignée de paquets dont les nouvelles versions majeures ont modifié le comportement par défaut plutôt que les signatures de fonction – le genre de rupture qui passe les tests d’intégration continue (CI) mais échoue en production. Dans un environnement plus complexe, il faut ajouter la recompilation des intégrations, la validation des dépendances en aval et la coordination des versions entre les équipes.
Vous pouvez également en savoir plus sur la gestion de la fin de vie d'un framework obsolète dans notre guide consacré à la prise en charge de la fin de vie de Knockout.js.
C’est pourquoi les développeurs débutants ne devraient pas être laissés seuls face à ces complexités, ni se laisser induire en erreur par des conseils trop simplistes du type « il suffit de mettre à jour ». La mise à jour peut tout à fait être la bonne solution à long terme. Mais effectuer une mise à jour en toute sécurité relève d’un projet d’ingénierie, et non d’un simple clic.
Définissez un délai pour une analyse rapide avant que quiconque ne s'engage sur une estimation de sprint, et travaillez en binôme. Une mise à jour dont le périmètre n'a pas été défini n'est pas un ticket, c'est une supposition.
Dérive des dépendances transitives
Les projets logiciels modernes sont extrêmement complexes. Ce que vous déclarez directement dans le fichier package.json, pom.xmlou requirements.txt ne représentent qu'une partie de ce qui se retrouve finalement dans l'application. Sous ces dépendances directes se trouvent plusieurs couches de dépendances transitives.
Un projet peut dépendre du paquet A, qui dépend lui-même du paquet B, lequel inclut le paquet C. Vous n’avez jamais choisi le paquet C. Son code se retrouve néanmoins dans votre arborescence de dépendances, et il est fréquent que quelques dizaines de dépendances directes se traduisent par des centaines, voire des milliers de paquets installés.
Cela crée une surface de sécurité bien plus vaste que ne le laisse supposer la liste des dépendances de premier niveau. Une vulnérabilité enfouie à plusieurs niveaux de profondeur peut tout de même avoir des conséquences, même lorsque le framework que vous avez installé intentionnellement semble parfaitement sain sur tous vos tableaux de bord. Les outils modernes permettent d’identifier bon nombre de ces dépendances indirectes — le graphe de dépendances de GitHub et Dependabot, par exemple, mettent en évidence les dépendances transitives vulnérables lorsqu’elles peuvent être résolues à partir d’un manifeste ou d’un fichier de verrouillage — mais les développeurs ont toujours besoin d’une visibilité sur ce qui est réellement déployé.
Lorsque des composants en fin de vie (EOL) s'intègrent dans cette arborescence, il devient plus difficile d'y remédier. Il peut arriver que vous sachiez qu'une vulnérabilité existe, puis que vous découvriez que la version dont vous dépendez ne dispose d'aucune mise à jour de sécurité.
Votre risque réel lié aux dépendances ne se limite pas à la liste des dépendances directes figurant dans votre manifeste. Il s'agit de l'arborescence complète des dépendances résolues, et c'est précisément sur celle-ci que vos outils de sécurité doivent pouvoir exercer une visibilité.
Le coût caché de la « fin »
La définition de ce qu'est « terminé » peut sembler intimidante, mais c'est une discussion qui doit avoir lieu dès le début de chaque projet et être ancrée dans la politique de l'équipe. La maintenance n'est pas une tâche ponctuelle. C'est une discipline permanente.
La dette technique existera toujours – j’en ai eu ma part dans mes expériences professionnelles précédentes –, mais les dépendances liées à la fin de vie d’un produit transforment une partie de cette dette technique en dette de sécurité.
Cette dette se traduit par des milliers de lignes de code qui finiront par devoir être refactorisées, des mises à jour ayant échoué qu’il faut annuler, des dépendances figées parce que les nouvelles versions rompent la compatibilité, ou encore des applications héritées dont personne ne veut s’occuper car trop d’autres systèmes en dépendent. Ignorer le problème ne fait pas disparaître la dépendance.
À un moment donné, une vulnérabilité critique est détectée, un scanner commence à signaler des problèmes, un auditeur demande pourquoi un logiciel dont le support a pris fin est toujours utilisé en production, ou un autre projet nécessite soudainement une version plus récente. Alors, une migration qui aurait pu être planifiée devient une urgence, et les équipes se retrouvent plongées dans la panique.
La meilleure approche consiste à identifier dès que possible les logiciels en fin de vie (EOL), à déterminer quels systèmes en dépendent, puis à décider de manière réfléchie s'il faut les mettre à niveau, les remplacer, les isoler ou continuer à les sécuriser en attendant qu'une migration soit planifiée. Un logiciel en fin de vie sans responsable et sans date cible ne constitue pas une dette technique. Il s'agit d'un incident en suspens dont le début est reporté.
La défense et le dôme d'armure
Pour remédier au problème lié à la fin de vie des logiciels, il ne suffit pas de réagir aux CVE au cas par cas. Vous devez avoir une bonne visibilité sur les logiciels que vous utilisez, contrôler ce qui entre dans votre environnement et disposer d'un plan d'action pour faire face à la disparition du support en amont.
Considérez cela comme la mise en place d’un « bouclier de protection » autour du cycle de vie de vos logiciels : réduisez les risques liés à la chaîne d’approvisionnement tant que les paquets font l’objet d’une maintenance active, surveillez les dépendances déjà en production et mettez en place une stratégie de sécurité pour les composants qui restent en service après leur fin de vie (EOL).
Épinglez-les et verrouillez-les !
Un environnement de compilation déterministe constitue l'une des premières lignes de défense. Pour les projets npm, validez votre fichier de verrouillage – package-lock.json – dans le système de contrôle de version et utilisez npm ci dans les workflows CI/CD lorsque cela est approprié. Cela permet d’installer les versions exactes des dépendances enregistrées dans le fichier de verrouillage, plutôt que de résoudre silencieusement une arborescence différente à chaque build, et le processus échoue de manière visible si le fichier de verrouillage et le fichier package.json ne sont plus synchronisés.
Les plages de versions telles que le signe de caret (^) et le tilde (~) ont toujours des utilisations légitimes ; l’objectif n’est donc pas de les supprimer partout. L’objectif est de comprendre comment votre politique de version et votre fichier de verrouillage interagissent, afin que les mises à jour des dépendances soient intentionnelles plutôt qu’accidentelles. La commande `npm update, par exemple, respecte les contraintes de version sémantique déclarées par votre paquet et ses dépendances, ce qui signifie qu’une plage de versions peut autoriser des mises à jour compatibles que vous n’avez jamais approuvées individuellement.
Un détail qui échappe souvent aux utilisateurs : l'indication des versions exactes dans le fichier package.json ne contrôle que votre dépendances directes . Lors d’une nouvelle résolution ou d’une mise à jour des dépendances, les dépendances transitives sont toujours sélectionnées en fonction des plages déclarées par leurs paquets parents. Un fichier de verrouillage validé enregistre alors l’arborescence résolue, et npm ci installe cet arbre verrouillé de manière reproductible. Si vous devez forcer une version transitive particulière, l’option champ « overrides » de npm permet de le faire (résolutions dans Yarn).
Si votre projet est une bibliothèque, privilégiez les plages de versions afin que les utilisateurs puissent éliminer les doublons. S'il s'agit d'une application déployée, privilégiez les versions exactes et des cycles de mise à jour bien définis.
Tout est une question de reproductibilité. Les environnements de développement, d’intégration continue, de préproduction et de production doivent être construits à partir d’un état de dépendances que votre équipe est capable d’identifier, de reproduire et de vérifier – ce qui permet d’éliminer l’une des phrases les plus redoutées dans le domaine du développement : « Eh bien, ça marche sur ma machine. »
SCA Tooling à la rescousse
L'analyse de la composition logicielle (SCA) et les outils de sécurité des dépendances vous permettent de suivre les vulnérabilités à un niveau de détail inaccessible à une analyse humaine. Vous devez non seulement savoir quels paquets vous avez installés délibérément, mais aussi ce que ces paquets ont entraîné dans leur sillage.
Le graphe de dépendances de GitHub et Dependabot permettent d’identifier les dépendances vulnérables, qu’elles soient directes ou transitives, au sein des écosystèmes pris en charge, et aident les équipes à déterminer les priorités. De la même manière, Snyk construit des arborescences de dépendances et peut recommander des parcours de mise à jour pour les dépendances indirectes vulnérables.
La détection des vulnérabilités CVE connues ne résout pas non plus à elle seule tous les problèmes liés à la chaîne d'approvisionnement. Un paquet malveillant ou compromis peut présenter un danger bien avant qu'un numéro CVE ne lui soit attribué. Des outils tels que Socket abordent la question sous un autre angle, en surveillant les modifications apportées aux dépendances et en analysant le comportement des paquets afin de détecter des risques tels que des accès inattendus au réseau, au système de fichiers ou au shell.
Si vous ne devez faire qu'une seule chose, passez en revue les dépendances corrigées que votre application intègre réellement et définissez une politique indiquant quels problèmes doivent bloquer les fusions. Si vous pouvez aller plus loin, ajoutez une analyse comportementale des dépendances nouvelles ou mises à jour, car un historique CVE vierge ne dit rien sur un paquet récemment compromis.
Une mise en garde : un scanner qui génère des résultats sans que personne ne les examine peut donner une fausse impression de couverture. Transmettez les résultats nécessitant une action à un responsable et définissez la manière dont ils doivent être traités.
La leçon à retenir pour un développeur débutant est simple : sachez ce qui entre dans votre application, sachez pourquoi cela s'y trouve, et sachez comment vous allez vous rendre compte qu'un changement est survenu.
Harnais ELS
Dans un monde idéal, toutes les dépendances en fin de vie pourraient être mises à jour immédiatement. Mais les environnements de production réels ne fonctionnent pas ainsi. La migration vers un nouveau framework peut nécessiter la réécriture d’une partie de l’application. Une mise à jour du runtime risque de perturber une dépendance essentielle à l’activité. Une bibliothèque obsolète peut se trouver au cœur d’un système que personne ne peut modifier avant la fin d’un autre projet, prévue dans six mois.
Rien de tout cela ne justifie que l'on ignore le problème de sécurité. Cela signifie que les équipes ont parfois besoin d'une alternative entre « mettre à jour immédiatement » et « utiliser un logiciel non pris en charge, sans correctifs de sécurité ».
C'est là que Endless Lifecycle Support (ELS) entre en jeu. Le service ELS de TuxCare assure la mise à jour continue des correctifs de sécurité pour les systèmes d’exploitation, les environnements d’exécution, les bibliothèques et les applications pris en charge en fin de vie, afin que les équipes puissent sécuriser les versions dont elles dépendent réellement tout en planifiant une migration éventuelle.
Pour les paquets open source se trouvant à un stade précoce de leur cycle de vie, SecureChain ajoute une couche supplémentaire. SecureChain fait office de substitut contrôlé aux registres publics (npm, PyPI, Maven, Go modules, crates.io et PHP) en proposant des paquets recompilés à partir de sources vérifiées, surveillés en permanence et corrigés, avec une compatibilité immédiate pour les gestionnaires de référentiels tels qu’Artifactory, Nexus et GitHub Packages. Lorsque la maintenance en amont prend fin, ELS peut continuer à fournir des correctifs pour les paquets pris en charge. Ensemble, ces éléments vous garantissent une continuité, depuis l’open source activement maintenu jusqu’à l’utilisation après la fin de vie (EOL).
Mais surtout, cela donne une marge de manœuvre aux équipes de développement. Au lieu de précipiter une migration parce qu’une vulnérabilité est apparue après la fin du support en amont, vous pouvez planifier, tester et mettre en œuvre les mises à niveau selon un calendrier adapté à l’application.
Cela n'élimine pas la nécessité de se moderniser. Cela élimine l'idée selon laquelle la modernisation doit nécessairement se faire dans des conditions d'urgence.
Réflexions finales
La sécurité n'a pas de date d'expiration, même si le support logiciel, lui, en a une. Trop souvent, les équipes ne s'en soucient pas tant que tout va bien, puis tout le monde se précipite quand les problèmes éclatent. Nous devons changer cette mentalité.
Pas besoin d’être un expert en sécurité pour faire la différence en tant que développeur. Il faut toutefois comprendre que les dépendances ont un cycle de vie, que le code transitif a son importance, que « ça fonctionne encore » ne signifie pas « toujours pris en charge », et que cliquer aveuglément sur « mettre à jour » ne constitue pas non plus une stratégie de sécurité.
Identifiez les dépendances de votre application. Enregistrez vos fichiers de verrouillage. Surveillez votre arborescence de dépendances. Sachez à quel moment les composants importants arrivent en fin de vie (EOL) et mettez en place une stratégie de mise à niveau avant d'en avoir désespérément besoin. Lorsqu'une migration immédiate n'est pas envisageable, assurez-vous que les logiciels non pris en charge ne restent pas en production sans bénéficier de correctifs de sécurité.
Commencez par un petit geste cette semaine : ouvrez votre fichier « lockfile », repérez le paquet le plus ancien qu'il contient et vérifiez la date de sa dernière publication. Que vous soyez développeur junior ou architecte principal, cette habitude contribuera grandement à protéger votre pile technologique – et à éviter que, un jour, une dépendance oubliée ne devienne le plus gros problème de tout le monde.
