Ne nourrissez pas le ver : aider les éditeurs à réduire leur exposition aux risques de la chaîne d'approvisionnement

Shai‑Hulud : de la fiction à la cybersécurité

Les fans de la série de science-fiction Dune de Frank Herbert reconnaîtront Shai-Hulud comme le nom de l'espèce de vers des sables géants qui rôdent sur la planète désertique d'Arrakis, représentant une menace constante d'anéantissement pour les personnages du livre. À partir de septembre 2025, « Shai-Hulud » désigne également un ver informatique : un virus auto-réplicatif qui a réussi à s'introduire dans plusieurs centaines de paquets JavaScript populaires et à voler des informations d'identification sensibles telles que les jetons d'accès personnels GitHub et les clés API des principales plateformes cloud.

Ce type de défaillance dans la chaîne logistique logicielle (l'ensemble des bibliothèques/utilitaires tiers utilisés par les développeurs pour créer leurs propres produits) n'est pas nouveau dans le monde du développement web. L'Open Web Application Security Project (OWASP) a commencé à dresser une liste des 10 principaux risques critiques pour la sécurité web en 2003. Les « défaillances de la chaîne logistique logicielle » sont apparues pour la première fois dans cette liste en 2013 et n'ont cessé de progresser depuis, occupant la troisième place en 2025.

La sécurité des données n'est pas un concept nouveau pour les éditeurs et les associations. Ces organisations traitent régulièrement de grandes quantités de données personnelles sensibles, dépendent de revenus ininterrompus (que les violations de données peuvent gravement perturber) et font face à des attentes croissantes de la part des régulateurs en matière de confidentialité et de protection des données des clients. 

Une dépendance accrue aux chaînes logistiques logicielles

Si les éditeurs se prémunissent déjà contre les menaces bien connues telles que les attaques par hameçonnage, les mots de passe faibles, les piratages de comptes et l'ingénierie sociale, les menaces pesant sur la chaîne logistique des logiciels risquent de rester un angle mort. Il est facile de comprendre pourquoi : les entreprises modernes s'appuient sur des dizaines, voire des centaines d'applications logicielles pour leurs opérations quotidiennes. Il est tout simplement impossible de surveiller tous les vecteurs d'attaque potentiels introduits par ces programmes.  

JavaScript amplifie particulièrement ce défi. En tant que lingua franca du Web, son écosystème de paquets n'a cessé de devenir de plus en plus interdépendant au fil des ans. Il suffit de regarder l'état actuel du registre npm (une base de données publique de bibliothèques/utilitaires JavaScript tiers) pour comprendre pourquoi la chaîne d'approvisionnement est une cible si attrayante pour les attaquants.  

Tout comme la majorité de l'activité Internet se concentre sur quelques grands sites Web, la majorité des téléchargements du registre npm se concentrent sur quelques paquets populaires. Cela crée un effet de levier dangereux, car la compromission d'une seule dépendance populaire peut avoir des effets en cascade sur l'ensemble de l'écosystème de développement Web. Le paquet A peut être utilisé dans l'utilitaire B, qui est une dépendance du projet C, lequel est à son tour utilisé par les applications D, E et F. Une chaîne de dominos est mise en place de telle sorte qu'un seul paquet peut affecter indirectement le fonctionnement de centaines (voire de milliers) de dépendances. 

L'exemple classique de dépendances devenues incontrôlables est le tristement célèbre incident de 2016 impliquant le paquet « left-pad ». Ce paquet était utilisé indirectement par des milliers de projets, y compris le célèbre framework front-end React. Lorsque l'auteur de left-pad l'a supprimé sans avertissement, tous les paquets qui en dépendaient ont commencé à échouer en cascade, provoquant une perturbation massive des applications sur Internet, y compris des sites majeurs tels que Facebook, Netflix, PayPal et Spotify.

Des recommandations difficiles à appliquer dans les projets modernes

La principale recommandation de l'OWASP pour se prémunir contre les défaillances de la chaîne logistique est que les développeurs suivent et surveillent de près la liste des dépendances de leur projet. Une telle tâche, bien que judicieuse en théorie, tend à être irréaliste compte tenu de la taille et de la complexité des projets web modernes.  

Les sites Web modernes doivent offrir un haut degré d'interactivité et utilisent généralement un « framework front-end » pour organiser les montagnes de code JavaScript qui doivent s'exécuter en arrière-plan. Si ces frameworks ont rendu le processus de codage des sites Web plus facile que jamais, ils ont pour effet secondaire d'introduire un nombre considérable de dépendances dans un projet. 

Prenons l'exemple du framework front-end le plus populaire, React. Même un simple projet « Hello World » utilisant ce framework peut nécessiter des centaines, voire des milliers de paquets npm via des dépendances transitives. Une arborescence de dépendances aussi importante, dès le début du projet, rend le suivi de la chaîne logistique logicielle pratiquement impossible. 

Blazor et NuGet : réduction des risques, mais jamais zéro

Heureusement, il existe des solutions alternatives. Découvrez Blazor, le framework front-end sur lequel repose Advantage. En permettant aux développeurs de créer des interfaces utilisateur web interactives avec C# et la plateforme .NET, Blazor contribue à réduire la dépendance à l'écosystème JavaScript et, par conséquent, le risque d'attaques de la chaîne d'approvisionnement npm. 

La version particulière de Blazor utilisée par Advantage, Blazor Server, va encore plus loin en transférant l'exécution de la plupart des logiques d'interface utilisateur du navigateur du client vers un serveur géré de manière centralisée. Cela signifie que le navigateur n'a plus qu'à se charger du rendu des mises à jour de l'interface utilisateur envoyées par le serveur, ce qui élimine le besoin d'expédier et d'exécuter de grandes quantités de JavaScript tiers sur le client. 

Il est toutefois important de noter que Blazor n'est pas une solution miracle. Les applications Blazor s'appuient sur leur propre réseau de paquets tiers appelé NuGet. Et bien que les paquets NuGet aient tendance à être plus centralisés et créés par des organisations établies que les paquets npm, ils ne sont pas à l'abri des attaques de la chaîne d'approvisionnement. De plus, Blazor fournit un service d'interopérabilité qui permet aux développeurs d'utiliser des paquets npm dans les projets Blazor, une fonctionnalité qu'Advantage utilise. Cela signifie que les équipes peuvent réintroduire la plupart, voire la totalité, des risques liés à la chaîne d'approvisionnement npm dans un projet si elles utilisent librement la fonctionnalité d'interopérabilité.

Aucun cadre ne peut éliminer entièrement les risques liés à la chaîne d'approvisionnement ; ces risques existeront toujours tant que nous utiliserons des bibliothèques et des outils tiers pour développer des logiciels. Cela dit, notre équipe a constaté que Blazor offre un moyen pratique de réduire le nombre de dépendances JavaScript tierces que nous finissons par livrer avec Advantage. 

L’engagement continu d’AdvantageCS

Ce n'est là qu'un exemple parmi d'autres de la manière dont l'équipe d'ingénieurs d'AdvantageCS contribue à la sécurité des données de nos clients. En choisissant des outils et des cadres qui facilitent la minimisation des dépendances, nous veillons à ce que la prochaine fois que vous rencontrerez le nom « Shai-Hulud », ce soit en toute sécurité dans les pages de Dune.