Maintenir à jour les API LoopBack existantes sans avoir à réécrire le framework

LoopBack 4 est la version actuellement en cours de développement, mais elle se situe bien au-delà des versions héritées abordées ici. LoopBack 2 a atteint sa fin de vie en avril 2019 et LoopBack 3 a suivi en décembre 2020 ; c'est sur ces versions que repose encore une grande partie du code LoopBack en production. Le service ELS de TuxCare permet aux versions de LoopBack couvertes de continuer à bénéficier de correctifs de sécurité.

Remplacez le package LoopBack couvert et les dépendances concernées par leurs équivalents gérés par TuxCare, au lieu de procéder à une nouvelle compilation sur un framework plus récent. La configuration se résume à trois lignes dans le fichier .npmrc, à une modification du fichier package.json pour pointer votre dépendance vers la version ELS, puis à la commande « npm install ». Les modèles, les méthodes distantes, les scripts de démarrage et les listes de contrôle d'accès (ACL) restent inchangés.

ELS couvre actuellement les versions 1.10.0 et 2.42.0 de LoopBack. Il s'agit dans les deux cas de versions obsolètes qui ne bénéficient plus d'une maintenance régulière de la part de l'éditeur. Si votre application utilise une autre version, y compris toute version de la série 3.x, veuillez contacter TuxCare pour discuter de la couverture.

Oui. Une application LoopBack existante hérite des risques liés au framework et à tous les éléments qui le sous-tendent. ELS peut rediriger les dépendances couvertes vers des paquets gérés par TuxCare via des remplacements npm ; la correction ne se limite donc pas au paquet LoopBack de niveau supérieur.

Oui. ELS est conçu pour les applications qui ne peuvent pas passer sans heurts à un framework plus récent. Les paquets pris en charge sont fournis via npm, ce qui permet aux équipes d’apporter des correctifs au graphe de dépendances existant tout en conservant l’architecture qu’elles utilisent déjà.

Aucune modification du code de l'application n'est nécessaire. Il vous suffit de configurer le dépôt TuxCare compatible avec npm, de remplacer les références aux paquets pris en charge, d'actualiser les dépendances, puis de tester comme d'habitude. L'objectif est de conserver le comportement LoopBack auquel votre API est déjà habituée.

Oui. Les paquets ELS sont installés via npm à partir du référentiel TuxCare compatible avec npm ; ainsi, la même configuration de registre fonctionne aussi bien dans les builds de conteneurs que dans tout workflow CI/CD qui installe déjà les dépendances avec npm. Le jeton est lu à partir du fichier .npmrc de votre projet.

ELS est conçu pour répondre aux exigences en matière de correction des vulnérabilités dans le cadre de normes telles que SOC 2, PCI DSS, HIPAA, NIS2, DORA et la CRA. Un processus contractuel de correction permet aux équipes de sécurité et d'audit de disposer d'une procédure de correction documentée pour les logiciels qui, autrement, ne seraient pas pris en charge.

La migration reste un objectif raisonnable à long terme, car le passage d'une génération de LoopBack à une autre implique de réelles modifications de l'application. ELS offre aux équipes la possibilité d'apporter des correctifs dès maintenant et de procéder à la migration lorsque l'API, le modèle de données, les intégrations et la couverture des tests seront prêts.