La première tâche à accomplir avant la prochaine mise à jour de sécurité de Node.js consiste à trouver chaque application qui en aura besoin.
Le projet Node.js prévoit de publier des mises à jour de sécurité pour ses branches 22.x, 24.x et 26.x le mercredi 11 novembre ou peu après. Son avis préliminaire, publié le 3 novembre, classe chaque branche au niveau de gravité le plus élevé : gravité élevée.
Pour les équipes de sécurité, cette fenêtre de préparation permet d’identifier les environnements d’exécution déployés, de désigner les responsables des mises à jour et d’organiser les tests avant que les détails des vulnérabilités ne soient rendus publics. Le plan de correction doit préciser comment l’environnement d’exécution Node.js de chaque application est installé et mis à jour.
Trois branches sont concernées
L’avis de sécurité officiel recense les versions 22.x, 24.x et 26.x pour des mises à jour le 11 novembre ou peu après, avec le niveau élevé comme niveau de gravité maximal pour chaque branche.
L’avis ne fournit pas encore d’identifiants CVE, de descriptions techniques, de nombre de vulnérabilités ni de numéros de version corrigée. Il n’affirme pas non plus que ces failles font actuellement l’objet d’une exploitation active.
Cela limite ce que les défenseurs peuvent conclure sur l’exposition des applications. Le niveau de gravité élevée ne permet pas à lui seul de déterminer si un problème autorise l’exécution de code à distance, nécessite une authentification ou touche une configuration donnée. Ces questions nécessitent l’avis complet.
La récente vulnérabilité Node2Shell illustre l’importance de ces conditions : l’exposition dépendait d’applications traitant des données compressées au format Brotli contrôlées par un attaquant. L’avis préliminaire de novembre n’établit aucun lien avec cette faille antérieure.
Trouvez l’environnement d’exécution qui sert réellement l’application
Commencez par dresser un inventaire reliant chaque déploiement Node.js à sa version, à son responsable applicatif, à son exposition et à sa méthode de mise à jour. Incluez les services de production, les images de conteneurs, les systèmes de développement et d’intégration continue, ainsi que les applications gérées par des prestataires externes.
Cette démarche suit les étapes d’évaluation et de priorisation du cycle de gestion des vulnérabilités : identifiez les actifs et leur contexte métier avant de décider de l’ordre des mesures correctives.
Avant l’arrivée des mises à jour, les équipes doivent :
- Consignez les versions déployées. Vérifiez-les dans l’environnement de l’application ou du conteneur concerné ; la version locale d’un développeur ne permet pas de déterminer celle utilisée en production.
- Identifiez le responsable de la mise à jour. Déterminez si l’environnement d’exécution provient d’un paquet du système d’exploitation, d’une image de conteneur, d’une installation directe ou d’un produit géré par un fournisseur.
- Préparez une procédure de déploiement. Organisez les tests en préproduction, la reconstruction des conteneurs le cas échéant, les redémarrages de services et les vérifications visant à détecter d’éventuelles défaillances applicatives.
- Confirmez les responsabilités du fournisseur. Pour les services gérés, demandez qui applique les correctifs de l’environnement d’exécution, quand ils deviennent disponibles et ce que les clients doivent redéployer.
Si l’organisation utilise des services de gestion des correctifs, vérifiez qu’ils couvrent bien ces déploiements. La présence d’une plateforme centralisée de correctifs ne garantit pas que l’environnement d’exécution intégré à chaque application est couvert.
Les versions obsolètes nécessitent une décision de migration
Node.js avertit explicitement que les versions arrivées en fin de vie restent concernées lorsque des mises à jour de sécurité sont publiées. Leur absence de la liste de la prochaine publication ne doit pas être considérée comme la preuve qu’elles sont sûres.
Le calendrier des versions du projet indique que Node.js 20 est arrivé en fin de vie et recommande les versions Active LTS ou Maintenance LTS pour les applications de production.
Les équipes qui découvrent des installations non prises en charge doivent définir une trajectoire de mise à niveau vers une version prise en charge et tester la compatibilité des applications. Lorsqu’un contrat de support commercial existe, confirmez auprès du fournisseur la couverture des correctifs de sécurité et le calendrier de leur livraison.
Rendez l’achèvement des correctifs mesurable
Une fois les versions publiées, comparez les conditions des vulnérabilités communiquées avec l’inventaire. Appuyez-vous sur les vecteurs d’attaque, l’exposition et l’impact métier indiqués pour prioriser le déploiement, puis installez la version corrigée applicable au moyen du processus de mise à jour pris en charge par l’application.
Pour chaque service, conservez la preuve de la version exécutée après le déploiement, des contrôles d’intégrité réussis et des éventuelles exceptions restantes. La mise à jour d’une définition de build ne représente qu’une partie du travail ; vérifiez que le remplacement a bien atteint les instances qui traitent les charges de travail réelles.
Toute mise à jour retardée doit avoir un responsable désigné, une échéance et des mesures de contrôle liées à la vulnérabilité réelle. Tant que les détails techniques ne sont pas publiés, rien ne permet de supposer qu’une règle de pare-feu ou une modification de configuration donnée résoudra ces problèmes.
Avant le 11 novembre, le résultat utile consiste à disposer d’un inventaire avec des responsables identifiés et d’un processus de déploiement testé. Après la publication, il faut pouvoir démontrer que les services concernés exécutent des versions corrigées et que les déploiements non résolus font l’objet d’un suivi jusqu’à leur achèvement.
À lire aussi : le deuxième correctif RCE critique de GitLab en octobre montre pourquoi les systèmes récemment corrigés doivent tout de même être vérifiés au regard de chaque nouvel avis de sécurité.