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
- LoopBack 3 a atteint sa fin de vie communautaire en décembre 2020 et ne bénéficie plus de correctifs en amont.
- Si LoopBack est fourni avec IBM API Connect, vérifiez d'abord le cycle de vie de ce produit.
- LoopBack 4 étant une refonte complète, le plan de mise à jour habituel consistant à passer à la version suivante et à corriger les problèmes ne s'applique pas.
- Une grande partie du risque réside dans les dépendances transitives contraignantes qui
npm audit fixn'est pas accessible.
LoopBack 3 a permis d'accélérer le développement d'API sophistiquées en combinant des modèles, des connecteurs, des contrôles d'accès et des points de terminaison générés. Ce sont précisément ces abstractions qui font de la migration vers LoopBack 4 un projet architectural plutôt qu'une simple mise à jour des dépendances.
Le support communautaire a pris fin en décembre 2020. La seule exception répertoriée concernait les correctifs de bogues critiques et de sécurité fournis via IBM API Connect, mais cette voie a depuis été fermée, tout comme les versions du produit auxquelles elle s'appliquait. Par ailleurs, la plupart des éléments signalés par un scanner sur un projet LoopBack 3 se trouvent généralement dans l'arborescence des dépendances plutôt que dans le package du framework lui-même.
Cet article traite de la marche à suivre lorsque LoopBack 3 a atteint la fin de sa durée de vie, que la migration revient à une réécriture complète et que l'API est critique.
Le cadre API qui a défini le modèle métier
LoopBack 3 excellait dans un domaine qui s'est avéré crucial. Vous définissiez des modèles, reliez des connecteurs et configuriez des contrôles d’accès, et LoopBack générait à partir de là des points de terminaison REST fonctionnels. Rapidement. En l’espace de quelques années, ces définitions de modèles peuvent discrètement devenir la couche d’intégration de l’entreprise sans que personne ne le note. La difficulté lorsqu’on abandonne LoopBack 3 réside rarement dans le code du framework. Elle réside plutôt dans la logique métier qui s’est accumulée au sein des définitions de modèles, des hooks et des listes de contrôle d’accès (ACL).
Imaginez une entreprise de logistique disposant de 60 points de terminaison REST générés à partir de modèles LoopBack 3. Deux applications internes en dépendent. Une intégration avec un partenaire les interroge selon un calendrier défini par ce dernier. L'ensemble fonctionne sous Node.js 12 au sein d'une machine virtuelle que personne ne souhaite reconfigurer, car la dernière personne à avoir compris la séquence de démarrage a quitté l'entreprise il y a des années.
Pour un système de ce type, un simple changement de version ne constitue pas une stratégie de migration, ce qui a des répercussions sur toutes les décisions qui s'ensuivent. Si l'on fait comme si ce n'était pas le cas, on risque fort de se retrouver avec une migration au point mort et une API non mise à jour toujours en production.
Ce que signifie réellement la fin de vie de LoopBack 3
Sans le soutien de la communauté, LoopBack 3 ne bénéficie plus de nouvelles fonctionnalités ni de corrections de bogues par la communauté. Le fichier README du projet est sans équivoque sur le reste : plus de « pull requests » ni d’assistance pour les utilisateurs de la communauté. La politique de support à long terme est légèrement plus souple, laissant aux responsables de la maintenance la possibilité d’évaluer les correctifs soumis par la communauté pour les bogues critiques. Les deux documents mentionnent la même exception restreinte concernant les correctifs critiques via IBM API Connect, et tous deux ont été rédigés alors que ce produit bénéficiait encore d’un support.
Derrière tout cela se cache également une politique de support facile à négliger. La politique de support à long terme de LoopBack liait la version Maintenance LTS aux versions LTS de Node.js prises en charge au moment où une version entrait dans cette phase. Une fois que ces versions de Node.js atteignaient la fin de leur période de maintenance, la version correspondante de LoopBack arrivait elle aussi à la fin de sa période de maintenance. L'ajout de la prise en charge de nouvelles versions majeures de Node.js n'était explicitement pas autorisé dans le cadre de la maintenance LTS, ce qui revient à dire, pour le dire lentement, que la génération de Node.js prise en charge avait été fixée il y a des années.
| Article | État de LoopBack 3 |
|---|---|
| Fin de vie du produit pour la communauté | Décembre 2020 |
| Nouvelles fonctionnalités / corrections apportées par la communauté | Aucun |
| Correctifs de sécurité critiques | Exception historique via IBM API Connect, désormais levée |
| Périmètre de la maintenance LTS | Liées aux versions LTS de Node.js disponibles au moment de la publication |
| Développement en amont actif | LoopBack 4, y compris le @loopback/* paquets |
Conseil d'initié : si votre LoopBack était fourni avec IBM API Connect v5 ou v2018, vérifiez le cycle de vie du produit avant de supposer qu'il existe une solution de repli IBM. Le support de base pour la version v5 a pris fin le 30 avril 2022 et celui pour la version v2018 le 30 avril 2023 ; le support étendu pour ces deux versions a pris fin le 31 décembre 2023, et IBM indique désormais qu'aucune de ces versions ne bénéficie plus de correctifs de code ou de sécurité. Cette voie est désormais fermée, ce qui signifie que la date de fin de vie (EOL) de la version open source n'est pas le seul délai qui vous est déjà imparti.
Un indice apparaît clairement dans l'historique des versions publiques. La dernière version de LoopBack 3, [email protected], reste la version fournie par npm, tandis que les nouveaux développements en amont se concentrent sur les paquets LoopBack 4. C'est là que se porte désormais l'attention du projet.
Pourquoi LoopBack 4 n'est pas simplement une version 3 de LoopBack avec un nouveau numéro
LoopBack 4 est la branche actuelle, en développement actif. Il s’agit également d’une réécriture complète. Son cœur est écrit en TypeScript, articulé autour de l’injection de dépendances et d’un conteneur IoC, avec des contrôleurs et des référentiels qui remplacent l’approche « modèle et script de démarrage » qui caractérisait LoopBack 3. Le modèle d’extension est lui aussi différent. Il s’agit d’un nouveau modèle de programmation, et non d’une destination à laquelle on accède via un gestionnaire de paquets.
La majeure partie du travail porte donc sur les composants de l’application qui s’appuient sur les conventions propres à LoopBack 3. Cela concerne généralement les scripts de démarrage et la séquence dont ils dépendent, les méthodes distantes et les hooks d’opération qui leur sont associés, les définitions ACL codant votre modèle d’autorisations, les mixins et la configuration des connecteurs, tout ce qui repose sur les conventions JSON des modèles, ainsi que les SDK clients générés que les utilisateurs en aval intègrent déjà dans leurs applications.
Évaluez honnêtement l'ampleur du travail. Une mise à niveau classique d'un framework peut se mesurer en sprints. Une migration vers LoopBack 3 peut facilement s'étendre sur plusieurs trimestres, et l'estimation dépend davantage de la quantité de logique contenue dans les définitions de modèles que dans le code applicatif, que vous pouvez porter sans difficulté.
Retour à la réalité : c’est justement cette idée reçue selon laquelle « ce n’est qu’une mise à niveau » qui fait échouer ces projets. Douze points de terminaison dotés d’une logique simplifiée constituent un projet de portée limitée pour une petite équipe. Deux cents points de terminaison générés, avec des listes de contrôle d’accès (ACL) codant un modèle d’autorisations, constituent un programme d’architecture méritant sa propre ligne budgétaire — et il la mérite bien.
Si l'API alimente des intégrations sur lesquelles vous n'avez aucun contrôle, distinguez clairement le délai de sécurité du délai de refonte avant de définir le périmètre de toute autre tâche. Il s'agit de deux calendriers distincts, et les confondre vous obligera à réaliser une refonte précipitée dont vous devrez assumer les conséquences en raison des engagements pris auprès de vos partenaires.
D'où proviennent réellement ces conclusions ?
Lorsque l’on ouvre l’arborescence des dépendances d’un projet LoopBack 3, une tendance se dessine généralement très vite. Le code propre au framework ne représente qu’une partie de la surface de risque. Les noms qui reviennent sans cesse se trouvent plusieurs niveaux plus bas et, selon vos connecteurs et votre fichier de verrouillage, ils ont tendance à inclure qs, lodash, body-parser, nodemailer, strong-remoting, strong-globalize, la méthode obsolète shortid, glob, inflight, et underscore.string. Certaines sont des dépendances directes des paquets LoopBack. Beaucoup sont transitives, c'est-à-dire qu'elles sont introduites par les paquets qui leur sont associés.
Ce cadre a son propre parcours en matière de conseil, et ses deux extrémités sont riches d'enseignements. Le Avis de sécurité « LoopBack » du 30 novembre 2020 a abordé un problème de pollution lié à un prototype dans @loopback/rest, où les données JSON contenant constructor ont été acceptées. Répertoriée sous le numéro CVE-2020-4988, cette faille concernait la version 8.0.0 et les versions antérieures, et le correctif a été intégré à la version 9.0.0. Il s'agit du code de LoopBack 4, ce qui est d'ailleurs le but recherché, puisque les correctifs au niveau du framework y sont désormais intégrés. Le avis du 6 août 2022 C'est le document à consulter si vous utilisez PostgreSQL, car il traite d'une faille critique d'injection SQL via l'extension contains filtrer dans loopback-connector-postgresql 5.5.0 et versions antérieures. Cela pose problème lorsque ce filtre peut accéder au connecteur, y compris aux sources de données configurées avec allowExtendedProperties: true et le code appelant directement les méthodes du connecteur. La version 5.5.1 intègre une validation des données d'entrée, et l'avis propose des solutions de contournement pour les équipes qui ne peuvent pas encore effectuer la mise à jour.
| Dépendance | Fonction | Contrainte liée à la remise en état |
|---|---|---|
qs, body-parser |
Analyse d'une requête (transitive) | Souvent épinglés par des paquets parents |
lodash, underscore.string |
Utilités (transitif) | Parfois susceptible de se déformer au niveau de la lame |
strong-remoting, strong-globalize |
Fonctionnement interne de LoopBack | Fixé par le cadre |
shortid |
Génération d'identifiants, le cas échéant | Obsolète et épinglé par son élément parent |
loopback-connector-postgresql |
Connecteur PostgreSQL, dans les cas où il est utilisé | Corrigé dans la version 5.5.1 |
Ce que vous voyez exactement dépend de votre fichier de verrouillage, de votre version de Node.js et de vos propres dépendances directes. Ce qui reste identique d’un projet à l’autre, c’est sa structure. Certaines de ces versions sont limitées par les plages de versions de LoopBack ou par les paquets qui les précèdent, ce qui empêche la correction automatisée de choisir une version corrigée compatible.
Attention : Gâter npm audit fix --force comme une modification à haut risque dans un projet LoopBack 3. Simple npm audit fix n'installe que les mises à jour correspondant aux plages que vous avez définies. Lorsqu'une chaîne de métavulnérabilités atteint le projet racine, sa résolution peut nécessiter des modifications en dehors de ces plages. À ce stade, npm souhaite --force, ce qui selon sa propre documentation installe des modules en dehors de la plage de dépendances que vous avez définie, y compris les changements majeurs au sens de la norme SemVer. Avec une arborescence aussi ancienne, c’est ainsi qu’un après-midi tranquille peut se transformer en une application qui ne démarre plus. Exécutez npm audit fix --dry-run --json Commencez par lire ce qu’il propose.
Concrètement, il convient de tenir deux listes. L'une regroupe les problèmes que vous pouvez résoudre en supprimant une dépendance de niveau inférieur. L'autre regroupe les problèmes bloqués par des contraintes situées plus haut dans l'arborescence. Ces listes nécessitent des plans d'action totalement différents, et les mélanger revient à gaspiller un sprint. C'est également la raison pour laquelle la couverture transitive revêt ici plus d'importance que pour presque tout autre type de correctif : en effet, un plan de correction qui laisse en place une dépendance vulnérable concernée ne permet pas de résoudre ce problème.
Choisir la bonne voie
Il n'y a pas de solution unique, mais les options réalistes sont peu nombreuses. Reconstruisez des services plus petits et ayant fait leurs preuves sur LoopBack 4 lorsque la logique est suffisamment simple pour que le travail soit réellement réalisable. Migrer les API dont l'architecture ne répond plus aux besoins de l'entreprise, car transposer une mauvaise conception dans un nouveau framework ne fait que vous valoir le même problème en TypeScript.
Mettez en place Secure LoopBack 3 lorsqu'une migration précipitée entraînerait un risque opérationnel plus immédiat que les vulnérabilités qui affectent réellement votre déploiement. Cela vous permettra de gagner du temps sans pour autant écarter la possibilité d'une refonte.
Pour les API porteuses de charge, le modèle « strangler » en est l’illustration concrète. Il s’agit de placer une façade de compatibilité devant l’API LoopBack 3 afin que les contrats externes restent stables, puis de déplacer les fonctionnalités derrière celle-ci, une par une. Les partenaires continuent ainsi d’accéder à la même URL pendant que vous reconstruisez ce qui se trouve derrière.
Cette faille doit encore être corrigée, et les solutions disponibles dépendent de la version que vous utilisez. Soutien au cycle de vie sans fin de TuxCare (ELS) documente actuellement les versions 1.10.0 et 2.42.0 de LoopBack, fournies en tant que remplacements directs via un registre npm géré par TuxCare. La liste des remplacements fournie avec ces versions est particulièrement intéressante pour quiconque consulte un rapport d'analyse, car elle va jusqu'à qs, body-parser, underscore.string et le reste de l'arborescence, plutôt que de s'arrêter au package de niveau supérieur. Si la façade donne accès à un service LoopBack 2, c'est ce dernier qui gère la sécurité pendant l'exécution de la reconstruction. Pour la version 3.x, renseignez-vous sur la prise en charge de votre version précise avant de l'intégrer au plan.
En résumé, voici comment cela se présente. Une logique simple et un nombre réduit de points de terminaison impliquent une refonte sous LoopBack 4 et la fixation d'une date butoir. Les autorisations basées sur les modèles et les intégrations avec les partenaires nécessitent une réécriture progressive derrière une façade, l'ancienne interface devant rester sécurisée tant que sa version est prise en charge. Et si LoopBack a été déployé via IBM API Connect, il faut régler la question du support produit avant toute autre chose.
Comment TuxCare gère la fonction « LoopBack »
TuxCare analyse le framework et son arbre de dépendances, puis détermine si chaque avis de sécurité s'applique réellement à la version concernée avant d'appliquer le moindre correctif. L'applicabilité d'abord, le bruit ensuite : c'est d'autant plus important que la plupart des éléments que vous examinez sont transitifs.
Les correctifs sont réintégrés dans les versions prises en charge plutôt que d’être fournis sous forme de mise à jour du framework, et les paquets sont publiés comme des remplacements directs des versions d’origine arrivées en fin de vie. Cette distinction est importante, car les points de terminaison générés constituent un contrat sur lequel d’autres équipes s’appuient, et un « correctif » qui modifie la structure de la réponse représente une régression pour tous les acteurs en aval.
Le modèle de support est documenté et non improvisé. Les délais publiés sont de 14 jours à compter de la divulgation publique pour les vulnérabilités « élevées » et « critiques » selon le CVSS 7.0 et au-delà, de 60 jours pour les vulnérabilités « moyennes » et de 90 jours pour les vulnérabilités « faibles », avec une réponse initiale à un problème signalé dans un délai de trois jours ; tout cela s’inscrit dans le cadre d’efforts commercialement raisonnables plutôt que d’une garantie contractuelle. Chaque paquet compilé par TuxCare est livré avec une SBOM, et les documents CycloneDX VEX sont diffusés avec chaque version du paquet et mis à jour à chaque nouvelle version, de sorte que la piste d’audit enregistre quelles vulnérabilités CVE connues affectent une version donnée d’un artefact et lesquelles ne l’affectent pas. Cette traçabilité est particulièrement utile dans les environnements réglementés qui exigent une trace écrite, et la procédure d’escalade écrite via des tickets permet d’en disposer. TuxCare n’est pas le projet en amont et ne prétend pas l’être. Le travail consiste en un backporting rigoureux pour les systèmes de production, maintenant que l’attention en amont s’est tournée vers LoopBack 4.
Pour connaître en temps réel le statut des CVE concernant les paquets pris en charge, rendez-vous sur le suivi CVE de TuxCare.
La place de LoopBack dans l'écosystème OpenJS
LoopBack est un projet « At-Large » de la Fondation OpenJS. StrongLoop, une société du groupe IBM, l’a apporté à la Fondation en juin 2021, et il est passé du statut d’incubation à celui d’« At-Large » l’année suivante. Le programme « Ecosystem Sustainability Program » ( ESP) de la Fondation a pour objectif de permettre aux versions en fin de vie et aux anciennes versions de bénéficier d’une couverture commerciale, une partie des revenus des partenaires servant à soutenir les mainteneurs participants et le travail de la Fondation. TuxCare a rejoint le programme en tant que membre Gold et partenaire ESP. Ce programme étant non exclusif, la couverture commerciale n’empêche pas les mainteneurs de continuer à assurer publiquement le support de n’importe quelle version, y compris celles couvertes par un partenaire.
LoopBack 4 pourrait bien être la bonne solution. Mais considérer cette démarche comme une simple mise à jour du package, c'est ainsi que les bonnes équipes aboutissent à de mauvais plans.
