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
- Lodash n'a aucune dépendance directe, mais il est utilisé par plus de 195 000 paquets npm, ce qui en fait un point de défaillance critique dans d'innombrables arborescences de dépendances.
- Les solutions expérimentales visant à remédier aux problèmes de pollution et les modifications incompatibles entre les versions de Lodash peuvent introduire des bogues subtils qui n'apparaissent qu'en conditions de charge réelle, entraînant inévitablement des dépassements de budget.
- Les options de support étendu, telles que TuxCare ELS, assurent une couverture de sécurité continue pour les versions en fin de vie, tout en vous permettant de planifier vos mises à niveau de manière stratégique.
Si vous développez des applications JavaScript, il y a de fortes chances que Lodash figure dans votre arborescence de dépendances. Peut-être l’utilisez-vous directement pour ces fonctions utilitaires qui rendent le développement JavaScript bien plus agréable. Peut-être est-il enfoui trois niveaux plus bas parce qu'un paquet que vous avez installé en dépend. Quoi qu'il en soit, vous avez probablement vu ces avertissements de fin de vie de Lodash apparaître lors d'analyses de sécurité et vous vous êtes dit : « Oui, je sais… mais dois-je vraiment m'en occuper tout de suite ? »
Tu as raison d'hésiter. Et tu n'es certainement pas le seul.
Depuis 2012, Lodash figure parmi les bibliothèques JavaScript les plus utilisées et se classe régulièrement comme le paquet le plus utilisé dans l'écosystème npm. On le retrouve partout, des prototypes rapides aux applications d'entreprise gérant des millions d'utilisateurs. Lorsque les versions de Lodash arrivent en fin de vie, il ne s'agit pas simplement de mettre à jour un seul paquet ; il faut naviguer dans un réseau complexe de dépendances qui peut facilement perturber les fonctionnalités existantes.
Voyons comment garantir la sécurité et la conformité de vos applications basées sur Lodash, même lorsque la version de Lodash en fin de vie a officiellement cessé d'être prise en charge.
Comment fonctionne le cycle de publication de Lodash
Avant d'aborder ce qui se passe lorsque le support prend fin, mettons-nous d'accord sur le fonctionnement réel du cycle de vie de Lodash. Car, honnêtement, si vous ne le suivez pas de près, vous risquez fort de vous rendre compte un beau jour que votre version de Lodash en fin de vie se trouve dans votre base de code depuis des années sans avoir été mise à jour.
Contrairement à certains frameworks, Lodash ne suit pas un calendrier de publication strict basé sur des délais. Il publie plutôt de nouvelles versions en fonction de l'achèvement des fonctionnalités, des corrections de bogues et des correctifs de sécurité. Les versions majeures (comme le passage de la version 3.x à la version 4.x) peuvent rester en vigueur pendant des années, tandis que des mises à jour mineures corrigent les problèmes de sécurité et les bogues au fur et à mesure qu'ils sont détectés.
Voici à quoi cela ressemble concrètement :
Lodash 3.x a été lancé en 2015 et a introduit des méthodes de chaînes de caractères, des utilitaires de programmation fonctionnelle et la prise en charge d'ES6. Il a été utilisé pendant environ un an avant l'arrivée de la version 4.
Lodash 4.x dropped in 2016 with major changes; it removed old IE < 9 support, introduced a 4KB core build, and modernized the entire codebase. This version has been the primary release line for nearly a decade, with 4.17.23 being the latest stable release from January 2026, which includes a security fix for CVE-2025-13465.
Et que se passe-t-il après avoir utilisé la même version pendant des années ? C'est là que les choses se compliquent. Lodash ne publie pas d'annonces officielles et programmées concernant la fin de vie de ses versions, contrairement à Node.js ou Bootstrap. Cependant, il publie une page de politique de support qui répertorie les versions activement prises en charge et celles en fin de vie. Les anciennes versions cessent tout simplement de recevoir des correctifs, la communauté passe à des versions plus récentes, et si une vulnérabilité apparaît dans une version non prise en charge, aucun correctif officiel ne sera publié.
Ce que la fin de ligne (EOL) de Lodash implique réellement pour votre environnement de production
Bon, le support officiel prend fin. Et alors, n'est-ce pas ? Votre code fonctionne toujours très bien, tout va bien, alors pourquoi s'inquiéter ?
Eh bien, voici la vérité qui dérange : ce n’est pas parce que les correctifs ne sont plus publiés que les failles de sécurité cessent d’apparaître. En réalité, les pirates recherchent spécifiquement les entreprises qui utilisent encore des versions de Lodash qui ne sont plus prises en charge, car ils savent que ces failles ne seront pas corrigées.
Vous voulez des exemples concrets ? Lodash a un passé bien connu en matière de problèmes de sécurité, notamment en ce qui concerne la pollution des prototypes. Voyons un peu son bilan :
CVE-2021-23337 (CVSS 7.2) : Vulnérabilité d'injection de commande dans le fonction . Celle-ci est grave ; des attaquants authentifiés à distance peuvent exécuter des commandes arbitraires en envoyant des requêtes spécialement conçues. Affecte toutes les versions antérieures à la 4.17.21.
CVE-2020-8203 (CVSS 7,5) : pollution de prototype dans merge, mergeWithet defaultsDeep . Les attaquants peuvent injecter des propriétés dans Object, ce qui peut entraîner un déni de service, voire l'exécution de code arbitraire. Concerné : versions antérieures à la 4.17.19.
CVE-2020-28500 (CVSS 5.3) : Déni de service par expression régulière (ReDoS) dans toNumber, trimet trimEnd . En envoyant des chaînes de caractères trop longues, les attaquants peuvent provoquer le blocage indéfini de l'application.
CVE-2019-10744 (CVSS 9.1) : Une autre faille de pollution de prototype, utilisant cette fois des charges utiles de constructeur pour injecter des propriétés dans Object. Affecte les versions antérieures à la 4.17.12.
CVE-2019-1010266 (CVSS 4.0) : Déni de service causé par une consommation incontrôlée de ressources dans le gestionnaire Date. Affecte les versions antérieures à la version 4.17.11.
CVE-2018-16487 (CVSS 6,5) : Encore une autre vulnérabilité de pollution de prototype dans defaultsDeep, mergeet mergeWith. Celle-ci permet de modifier les propriétés existantes qui s'appliqueront à tous les objets.
CVE-2018-3721 (CVSS 5.3) : Pollution de prototype via __proto__ , permettant aux attaquants d'ajouter ou de modifier des propriétés sur tous les objets.
Vous voyez le schéma ? Des vulnérabilités liées à la « pollution des prototypes » ne cessent d'apparaître dans Lodash, ciblant précisément les fonctions utilitaires qui rendent son utilisation si pratique. Il ne s'agit pas là de problèmes théoriques ou purement académiques. Ce sont de véritables problèmes de sécurité qui peuvent transformer une situation du type « oui, on devrait probablement mettre ça à jour » en un véritable cauchemar en matière de conformité, voire pire : une véritable faille de sécurité. Lorsque vous utilisez des versions de Lodash en fin de vie, vous êtes exposé à toutes ces vulnérabilités sans qu'aucun correctif officiel ne soit prévu.
Ce qui rend ces attaques liées à la fin de vie de Lodash dangereuses, ce n'est pas seulement leur fréquence, mais ce qu'elles permettent de faire. La pollution des prototypes peut entraîner des dénis de service, l'injection de propriétés qui perturbent la logique de l'application et, dans certains cas, l'exécution de code à distance. Pour les applications traitant des données sensibles ou des transactions financières, l'utilisation de versions de Lodash en fin de vie signifie que ces risques ne sont pas seulement théoriques. Il s'agit là de violations de conformité qui ne demandent qu'à se produire.
Mais voici ce qui rend la sécurité de Lodash particulièrement intéressante par rapport à d'autres bibliothèques…
Le risque caché : votre arborescence de dépendances
Quand on évoque la sécurité de Lodash, la plupart des gens se demandent s’ils l’importent directement dans leur code. Mais ce n’est là qu’une vision très superficielle. Le véritable risque lié à la fin de vie de Lodash ne réside pas seulement dans vos dépendances directes, il se cache dans l’ensemble de votre arborescence de dépendances.
Voici ce qu'il faut savoir à propos de Lodash : il n'a aucune dépendance directe. Aucune. C'est une bibliothèque d'utilitaires autonome qui n'en appelle aucune autre. Ça a l'air génial, non ?
Mais si l'on inverse la perspective, on comprend alors le véritable problème : Lodash est systématiquement le paquet le plus utilisé dans tout l'écosystème npm. Avant même de vous en rendre compte, même si vous n’avez jamais explicitement installé Lodash, vous l’avez quelque part dans votre node_modules.
Ces dépendances transitives (les paquets que vous n’avez pas installés directement) créent une véritable jungle dans laquelle Lodash peut apparaître plusieurs fois, avec des versions différentes. J’ai vu des projets où l’équipe n’avait jamais explicitement ajouté Lodash à son fichier package.json, mais lorsque vous exécutez npm list lodash, on constate qu’il y a 15 paquets différents qui en dépendent, certains en version 4.17.15, d’autres en 4.17.19, et quelques retardataires encore en 3.x.
Chaque instance de Lodash représente une faille de sécurité potentielle. Et comme il s'agit de dépendances imbriquées que vous n'avez pas installées directement, elles passent très facilement inaperçues lors des audits de sécurité.
Mais voici le hic : lorsque Lodash arrivera en fin de vie, vous n’aurez pas seulement affaire à une bibliothèque qui ne sera plus prise en charge. Vous devrez gérer tout un écosystème de paquets qui dépendent de cette version de Lodash en fin de vie. Des outils comme npm audit peuvent certes vous aider à repérer les vulnérabilités connues. Mais ils ne peuvent pas, comme par magie, corriger les versions en fin de vie à votre place.
Et c'est là que les choses se compliquent vraiment. Même si vous vouliez mettre à jour Lodash dès demain, votre arborescence de dépendances pourrait bien en décider autrement. Le paquet A nécessite Lodash 3.x pour des raisons de compatibilité. Le paquet B ne fonctionne pas avec une version plus récente que la 4.17.15. Le paquet C dépend de manière transitive du paquet D, qui n'a pas été mis à jour depuis trois ans et qui ne fonctionne plus avec les versions récentes de Lodash.
Ce qui semblait être une simple tâche consistant à « mettre à jour le paquet » se transforme soudainement en un projet de grande envergure visant à « démêler tout ce fouillis de dépendances ». Quelle joie !
Vos options à l'approche de la fin de vie de Lodash
Bon, votre version de Lodash arrive bientôt en fin de vie, ou peut-être l'a-t-elle déjà dépassée. Quelles sont vos options concrètes dans ce cas ?
En gros, trois options s'offrent à vous. Examinons chacune d'elles avec réalisme.
Option 1 : Passer à la prochaine version majeure
C'est la réponse « officielle » que tout le monde donne. Il suffit de passer à la dernière version de Lodash ! Problème résolu ! Vos soucis s'envolent !
Et puis, pour beaucoup d'équipes, c'est vraiment la bonne décision. Les versions récentes de Lodash sont indéniablement meilleures : elles ont corrigé des failles de sécurité, amélioré les performances et ajouté des fonctionnalités utiles.
Mais soyons réalistes un instant : que signifie réellement « simplement mettre à jour » lorsqu’il s’agit d’une migration vers une version majeure ?
Tout d'abord, vous devez passer au crible l'ensemble de votre base de code à la recherche de modifications incompatibles. Lodash a connu plusieurs changements d'API d'une version à l'autre : des renoms, des comportements qui ont subtilement évolué et des fonctions qui ont été dépréciées. Ensuite, vous devez mettre à jour toutes vos dépendances et espérer qu’elles prennent bien en charge la nouvelle version de Lodash. Vient ensuite la refactorisation du code qui repose sur d’anciens comportements. Il faut coordonner les déploiements sur ce qui peut représenter des dizaines de microservices. Et mettre en place des plans de retour en arrière au cas où quelque chose tournerait mal en production.
Pour une petite application avec des dépendances modernes et une couverture de test solide ? Vous pourriez peut-être vous en sortir en quelques semaines. Pour une application d'entreprise tentaculaire comportant des centaines de paquets qui dépendent transitivement de Lodash ? Il vous faudra compter plusieurs mois de travail de migration. Des cycles d'assurance qualité approfondis. Et le risque très réel d'introduire des bugs subtils qui n'apparaîtront qu'en conditions de charge de production.
Le passage de Lodash 3 à 4 a été particulièrement difficile. Les noms des méthodes ont changé. Le comportement du chaînage a changé. Certaines méthodes ont été purement et simplement supprimées. Même les versions correctives 4.17.x ont introduit des changements incompatibles pour certains cas particuliers.
Rien de tout cela n'est impossible. Cela demande simplement de l'organisation, des ressources et du temps – trois éléments qui font généralement défaut lorsque votre équipe de sécurité vous met la pression à propos des avertissements de fin de vie (EOL) de Lodash dans le dernier rapport d'analyse de vulnérabilités.
Option 2 : Migration vers d'autres technologies
Certaines équipes, face à la fin de vie de Lodash, se disent : « Tu sais quoi ? C'est peut-être l'occasion de repenser tout ça. »
Le passage aux méthodes natives d'ES6+, l'utilisation de Ramda pour la programmation fonctionnelle et le recours à des bibliothèques plus spécialisées constituent autant de raisons convaincantes d'envisager des alternatives. Le JavaScript moderne dispose de méthodes intégrées telles que Array.map(), Object.assign()et Promise.all() qui peuvent remplacer de nombreux utilitaires Lodash.
Mais ne nous leurrons pas sur ce que cela implique. Il ne s'agit plus simplement d'une mise à niveau de bibliothèque. Il s'agit d'une refonte complète. Et les refontes ont cette drôle de tendance à s'avérer bien plus compliquées que ce à quoi on s'attend.
Ce qui commence par « on va simplement remplacer Lodash par des méthodes natives » se transforme rapidement en « attends, il faut ajouter des polyfills pour les navigateurs plus anciens, réécrire toutes nos fonctions utilitaires, mettre à jour nos normes de codage, former à nouveau l'équipe aux modèles de programmation fonctionnelle, et, au fait, il faut continuer à assurer la maintenance de l'ancien système pendant qu'on développe le nouveau. »
Cette flexibilité est vraiment séduisante. Quant au calendrier et au coût ? En général, ça donne à réfléchir une fois qu'on a tout mis sur papier.
Option 3 : Assistance étendue par TuxCare
Voici la solution qui change tout : une assistance prolongée proposée par des entreprises spécialisées dans la sécurisation des logiciels en fin de vie.
Le service « Endless Lifecycle Support » (ELS) de TuxCare pour Lodash a été spécialement conçu pour répondre précisément à ce type de situation. Au lieu de vous précipiter dans une mise à niveau pour laquelle vous n’êtes pas prêt, ou de refactoriser l’intégralité de votre application, vous continuez à utiliser votre version actuelle de Lodash tout en bénéficiant du même niveau de sécurité que les versions activement prises en charge.
Voici comment cela fonctionne : TuxCare surveille les nouvelles vulnérabilités (CVE) affectant les versions obsolètes de Lodash, adapte les correctifs de sécurité à ces versions, effectue des tests approfondis et fournit des correctifs qui s'intègrent parfaitement à votre infrastructure existante. Vous ne fuyez pas la modernisation, vous la menez de manière stratégique, selon votre propre calendrier, sans vous exposer à des risques de sécurité.
Il ne s'agit pas simplement de gagner du temps. Il s'agit de prendre le contrôle de votre feuille de route de mise à niveau tout en garantissant une sécurité et une conformité de niveau entreprise.
Le coût réel d'une mise à niveau précipitée vers la version de fin de vie de Lodash
Voyons ce qui se passe réellement lorsque des équipes tentent de forcer une mise à niveau de Lodash parce qu'elles paniquent à la vue des avertissements de fin de vie (EOL) de Lodash sur leurs tableaux de bord de sécurité.
Lorsque les équipes tentent de mener à bien une mise à niveau majeure de leur bibliothèque dans des délais irréalistes, sous la pression des exigences de conformité ou de sécurité, des problèmes prévisibles surviennent :
Augmentation de la charge de travail du support: Tous ces bugs qui n'ont pas été détectés lors des tests ? Ils commencent à apparaître en production. Votre équipe d'assistance est submergée de tickets signalant des comportements étranges, et la moitié d'entre eux sont dus à de subtiles différences dans le fonctionnement des méthodes Lodash.
Instabilité du système: Il se peut qu'une dépendance transitive ait présenté un bug marginal avec la nouvelle version de Lodash, qui ne se manifeste que sous la charge de production. Il se peut qu'un correctif de pollution des prototypes ait modifié la façon dont merge , perturbant ainsi le traitement de vos données. Lorsque vous précipitez une mise à jour, ce sont ces problèmes qui déclenchent des alertes à 3 heures du matin et rendent les ingénieurs très grincheux.
L'accumulation de la dette technique: Dans leur précipitation à se mettre en conformité, les équipes commencent à prendre des raccourcis. La refactorisation adéquate est négligée. Les solutions de contournement s’accumulent. « On s’en occupera correctement plus tard » devient une situation permanente, et six mois plus tard, vous vous retrouvez face à un désordre encore plus grand qu’au départ.
Dépassements budgétaires: Les dépassements budgétaires sont pratiquement inévitables lorsque vous devez gérer des problèmes de mise à niveau en urgence. Les heures supplémentaires des sous-traitants, les retards dans la mise en place des nouvelles fonctionnalités, le coût d'opportunité lié au fait que vos meilleurs ingénieurs doivent déboguer la compatibilité avec Lodash au lieu de développer de nouvelles fonctionnalités : tout cela s'accumule rapidement.
Je ne dis pas que les mises à niveau sont une mauvaise chose. Je dis simplement que les mises à niveau précipitées coûtent cher et comportent des risques. La différence entre une mise à niveau bien planifiée et une mise à niveau effectuée dans la précipitation n'est pas minime. Elle est énorme.
La solution simple : TuxCare ELS pour Lodash EOL
C'est là que le support à vie proposé par TuxCare pour Lodash change véritablement la donne.
TuxCare s'y consacre depuis plus de dix ans maintenant. L'entreprise a fourni des correctifs de sécurité pour des systèmes d'exploitation, des environnements d'exécution, des bibliothèques et des applications en fin de vie ; on parle ici de plus de 120 000 correctifs. Quand ils affirment posséder une expertise dans la gestion des cycles de vie des logiciels libres, ce ne sont pas que des promesses en l'air. Ils l'ont véritablement fait à grande échelle.
En quoi l'approche de TuxCare est-elle différente ?
Couverture complète de l'arborescence des dépendances: C'est énorme. Bien que Lodash n'ait lui-même aucune dépendance, TuxCare ne se contente pas de corriger les versions en fin de vie ; ils comprennent comment il s'intègre dans l'ensemble de votre écosystème de dépendances. Ils surveillent les vulnérabilités dans tous les paquets qui dépendent de Lodash et fournissent des conseils complets pour sécuriser l'ensemble de votre pile. Vous ne protégez pas seulement une bibliothèque ; vous sécurisez la couche utilitaire critique sur laquelle s'appuient des centaines d'autres paquets.
Un processus de correction optimisé et automatisé: Le processus de TuxCare combine une automatisation poussée et une validation par des experts. L'équipe surveille le NVD, les avis de sécurité des fournisseurs, les flux de sécurité GitHub, bref, tous les endroits où les vulnérabilités sont divulguées. Lorsqu'un CVE est publié, elle utilise une combinaison d'outils algorithmiques et d'automatisation assistée par l'IA pour rétroporter les correctifs vers les versions non prises en charge, puis de véritables experts en sécurité valident le tout. Chaque correctif est soumis à des tests approfondis portant sur l'intégrité, la fonctionnalité et les problèmes de régression avant d'être intégré à vos dépôts.
Si vous souhaitez comprendre exactement comment cela fonctionne en coulisses, consultez le livre blanc technique de TuxCare sur leur processus de correction open source. Il est étonnamment accessible pour un document technique.
Intégration transparente: Les correctifs de TuxCare s'intègrent directement à votre flux de travail actuel. Que vous utilisiez npm, Yarn, pnpm ou tout autre gestionnaire de paquets, les paquets ELS fonctionnent tout simplement. Vous n'avez pas besoin de remanier vos processus ni vos outils. Vous continuez simplement à utiliser ce que vous avez déjà mis en place.
Réponse rapide garantie par un SLA: Lorsque de nouvelles vulnérabilités sont révélées, TuxCare fournit des correctifs couverts par de véritables accords de niveau de service. Vous n'avez plus à croiser les doigts en espérant que quelqu'un finira par proposer un correctif rétrocompatible. Vous bénéficiez de mises à jour de sécurité prêtes à l'emploi selon un calendrier prévisible, avec une assistance garantie en cas de problème.
Rentabilité: Voici ce qui surprend les gens à propos du support prolongé : il est généralement bien moins coûteux que les autres solutions. Lorsque l’on additionne le temps d’ingénierie (au tarif horaire réel de votre équipe), les cycles de test, les honoraires des sous-traitants, les temps d’arrêt potentiels, les fonctionnalités retardées et le coût d’opportunité, l’ELS revient généralement à une fraction de ce prix. De plus, vous n’épuisez pas votre équipe dans un projet de migration soumis à une forte pression.
Conformité et transparence: Chaque version de TuxCare offre une visibilité complète sur les correctifs apportés. Vous disposez d'une documentation détaillée indiquant les vulnérabilités (CVE) qui ont été corrigées, les composants qui ont été modifiés et la manière de vérifier l'ensemble de votre nomenclature logicielle (SBOM). Cela est essentiel pour les audits de conformité et les rapports de sécurité.
Comment démarrer
Si vous utilisez des versions en fin de vie et que vous souhaitez connaître les versions actuellement disponibles, TuxCare met à jour un suivi CVE en temps réel où vous pouvez rechercher votre version spécifique et voir quelles vulnérabilités ont été corrigées. C'est un moyen très simple de comprendre quelle couverture de sécurité vous obtiendriez.
Vous souhaitez en savoir plus ? Consultez la page « Assistance à vie pour Lodash » de TuxCare pour obtenir des informations sur les versions prises en charge, les tarifs et le fonctionnement concret de la mise en œuvre.
Ne laissez pas la fin de vie de Lodash mettre vos systèmes en danger
Le passage de Lodash de la version 3 à la version 4 a apporté de réelles améliorations, de meilleures performances, des pratiques JavaScript modernes, un code plus épuré et d'importantes corrections de sécurité. Ce sont là de réels avantages, et si vous partez de zéro, Lodash 4.17.21 ou une version ultérieure vaut vraiment la peine d'être utilisée.
Mais que faire si vous assurez la maintenance d'applications existantes qui, compte tenu du calendrier de publication imprévisible de Lodash, ne peuvent pas être mises à niveau sans entraîner de perturbations majeures ? La fin de vie de Lodash ne doit pas nécessairement être synonyme de « panique » ou de « cauchemar en matière de sécurité ».
Vous avez le choix. Un véritable choix. Vous pouvez planifier une mise à niveau mûrement réfléchie lorsque cela s'avère réellement judicieux pour votre entreprise. Vous pouvez explorer d'autres approches s'il existe une raison technique véritablement convaincante. Ou vous pouvez recourir à l'assistance prolongée pour garantir la sécurité et la conformité tout en prenant ces décisions selon votre propre calendrier, plutôt que d'y être contraint par la divulgation d'une vulnérabilité.
Les équipes qui gèrent efficacement les enjeux de sécurité liés à la fin de vie de Lodash ne sont pas nécessairement celles qui disposent des budgets les plus importants ou des bases de code les plus modernes. Ce sont celles qui identifient les risques, comprennent les options qui s'offrent à elles et font des choix réfléchis quant à la marche à suivre.
Si la fin de vie de Lodash vous préoccupe actuellement, cela vaut la peine de découvrir ce que propose TuxCare. Vous vous rendrez peut-être compte que la meilleure chose à faire n’est pas de vous précipiter dans une mise à niveau pour laquelle vous n’êtes pas prêt, mais plutôt de sécuriser ce que vous avez déjà tout en planifiant la mise à niveau que vous souhaitez réellement effectuer.
Visitez le support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment une assistance prolongée peut protéger l'ensemble de votre pile open source aussi longtemps que vous en avez besoin.
