Protégez les services Fastify non pris en charge sans précipiter la mise à niveau du framework

Utilisez une version de remplacement maintenue correspondant à celle attendue par votre service. Ajoutez trois lignes de registre au fichier .npmrc de votre projet, configurez la dépendance Fastify pour qu'elle pointe vers le paquet TuxCare, puis réinstallez. Les vulnérabilités CVE sont corrigées sans qu'il soit nécessaire de procéder simultanément à une migration du framework, et les routes, les hooks, les décorateurs ainsi que l'enregistrement des plugins restent inchangés.

ELS couvre Fastify 3.29.5 et 4.29.1, qui constituent les versions finales de chaque branche. Fastify 3 a quitté le statut LTS en amont en juin 2023 et Fastify 4 en juin 2025 ; par conséquent, les nouveaux problèmes de sécurité affectant l'une ou l'autre de ces versions ne bénéficient plus d'une garantie de correctif en amont. Si votre service utilise une version différente, veuillez contacter TuxCare pour discuter de la couverture.

Lorsqu'une vulnérabilité CVE publiée affecte une version prise en charge, TuxCare l'évalue et applique le correctif nécessaire, dans la mesure du possible. L'historique de Fastify comprend déjà des cas de déni de service via des en-têtes « Content-Type » spécialement conçus et un contournement de la vérification préalable CORS, le genre de failles qui apparaissent lors d'un scan bien après que le service a cessé d'évoluer.

Oui. ELS inclut des correctifs de sécurité pour les dépendances directes et transitives couvertes ; la correction ne se limite donc pas au paquet Fastify de niveau supérieur. TuxCare documente une entrée de remplacement dans le fichier package.json pour les copies imbriquées ; le Patcher la génère pour vous, et le service d'assistance peut vous confirmer la méthode appropriée si votre projet repose sur une version plus ancienne de npm.

Non. L'adoption du paquet géré par TuxCare correspond à une modification de la résolution des dépendances effectuée via le registre npm de TuxCare. Vos définitions de routes, vos hooks de cycle de vie, vos schémas et votre arborescence de plugins fonctionnent exactement comme auparavant.

Oui. Les paquets ELS sont résolus via npm à partir du registre TuxCare ; ils s'intègrent donc aux builds Docker, aux pipelines CI/CD et aux workflows de déploiement existants. Le changement concerne la résolution des dépendances et non la logique de votre application.

ELS est conçu pour répondre aux exigences en matière de correction des vulnérabilités dans le cadre de référentiels tels que SOC 2, PCI DSS, HIPAA, NIS2, DORA et la CRA. Un accord de niveau de service (SLA) contractuel relatif à l'application des correctifs fournit aux auditeurs une feuille de route documentée pour la correction des vulnérabilités dans le cadre d'un référentiel qui, sans cela, ne serait pas pris en charge.

Procédez à la mise à niveau lorsque cela se justifie d'un point de vue technique. ELS continue d'appliquer les correctifs aux versions prises en charge pendant que vous testez les plugins, les exigences d'exécution, les schémas et le comportement des applications sur la nouvelle version majeure ; ainsi, la migration suit votre feuille de route plutôt que la prochaine vulnérabilité CVE.