Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Dans les films d'horreur, les menaces les plus effrayantes ne sont pas celles qui enfoncent la porte d'entrée : ce sont celles qui se trouvent déjà à l'intérieur, les fantômes cachés dans les murs que personne n'a remarqués.
Les chaînes d'approvisionnement logicielles modernes fonctionnent de la même manière.Lorsque nous développons et déployons des applications aujourd'hui, nous avons tendance à faire confiance à notre équipe et aux bibliothèques que nous installons délibérément.
BMais sous la surface de votre package.json se cache un immense iceberg de code invisible.C'est le monde des dépendances transitives, et c'est précisément là que commencent de nombreuses attaques modernes visant la chaîne d'approvisionnement.
L'illusion du contrôle : vos dépendances directes
Lorsque vous exécutez npm install, vous ajoutez peut-être cinq ou dix bibliothèques que vous connaissez et en lesquelles vous avez confiance. Ce sont vos dépendances directes. Vous avez consulté leur nombre d'étoiles sur GitHub, vous avez vérifié leur fréquence de mise à jour, et vous leur faites confiance.
Cependant, chacune de ces cinq bibliothèques peut dépendre d'une dizaine d'autres. Et ces dix-là en dépendent à leur tour d'une dizaine d'autres. Avant même de vous en rendre compte, une « simple » application web peut facilement compter plus de 1 000 paquets dans votre node_modules . Ce sont vos dépendances transitives, les « paquets de vos paquets », et elles représentent la grande majorité du code que vous déployez réellement en production.
Si vous souhaitez vérifier quelles dépendances directes vous avez installées sans avoir à ouvrir votre package.json, vous pouvez exécuter npm ls. Cette commande affichera dans le terminal la liste des dépendances directes que vous avez installées.
Pourquoi les dépendances transitives sont le « fantôme » idéal
Le danger des dépendances transitives réside dans le fait qu’elles sont largement invisibles dans le flux de travail habituel d’un développeur. Nous vérifions rarement les troisième ou quatrième niveaux de notre arborescence de dépendances. Les pirates en sont conscients et ont adapté leurs tactiques pour exploiter trois « failles » spécifiques.
« Typo-squatting » :
Enregistrement d'un nom de paquet presque identique à un nom populaire (par exemple, lodash vs lodas_h). Une simple faute de frappe dans une dépendance de niveau profond suffit pour qu'un script malveillant s'exécute dans votre pipeline de build.
Imaginons que vous souhaitiez installer Express afin de pouvoir développer une API ou un service backend. La mémoire musculaire prend le dessus et, lorsque vous vous rendez dans votre terminal pour installer `express`, au lieu de taper `npm install express`, vous tapez `npm install expres`. La différence, c'est que vous avez oublié le deuxième « s » du mot. Il y a de fortes chances que vous ne vérifiiez pas votre dossier node_modules : vous allez simplement partir du principe que le paquet s'est installé correctement. C'est là que les problèmes peuvent commencer.
Soyez toujours conscient des paquets que vous installez. Dans la mesure du possible, privilégiez les paquets à portée limitée. Les paquets à portée limitée proviennent souvent de des registres privés ou contrôlés par l'organisation, ce qui ajoute un niveau de confiance supplémentaire.
Confusion des dépendances
Amener un système de compilation à récupérer une version « publique » malveillante d'un paquet au lieu de votre version interne « privée ». Les paquets avec portée permettent de limiter les attaques par confusion des dépendances. Un paquet avec portée se présente comme suit : `@scope/your-awesome-package`.
Lorsqu'une organisation utilise à la fois des registres privés (internes) et publics (npm), un pirate publie un paquet public portant le même nom qu'un paquet privé, mais avec un numéro de version supérieur. Selon Spectral, «Près de 49 % des organisations sont exposées au risque d’une attaque par confusion de dépendances.»
La mise à jour « Maudite »
Un pirate informatique parvient à accéder à une petite bibliothèque d'utilitaires légitime utilisée comme dépendance par un framework majeur. Le paquet `@ctrl/tinycolor` constitue un exemple de petit utilitaire. Un exemple récent est l' attaque de la chaîne d'approvisionnement Shai-Hulid, au cours de laquelle une bibliothèque d'utilitaires compromise a été utilisée pour diffuser du code malveillant. Ils diffusent un « correctif » contenant une porte dérobée. Du jour au lendemain, des milliers d'applications se retrouvent « infectées » sans qu'un seul développeur n'ait modifié son propre fichier package.json.
Une porte dérobée (initialement appelée « trapdoor ») est une méthode cachée permettant de contourner les procédures d'authentification habituelles et d'obtenir un accès privilégié à un système. Malwarebytes propose un excellent article sur les portes dérobées, et cette citation le résume très bien.
« Une porte dérobée désigne toute méthode permettant à des utilisateurs autorisés ou non autorisés de contourner les mesures de sécurité habituelles et d'obtenir un accès utilisateur de haut niveau (ou accès root) à un système informatique, un réseau ou une application logicielle. »
Histoire des portes dérobées
Les portes dérobées, ou « trapdoors », ont fait leur apparition dans les années 1960-1970. À l'origine, elles étaient destinées à permettre aux développeurs de logiciels légitimes d'accéder aux fonctions de maintenance et de dépannage, ainsi que de contourner les procédures d'authentification pendant le développement et la correction des systèmes.
Les portes dérobées ont commencé à se développer dans les années 1980. Elles ont alors commencé à être utilisées à des fins malveillantes. L'un des incidents les plus célèbres des années 1980 fut le ver Morris de 1988, qui infecta de nombreux systèmes sur les débuts d'Internet. Robert Morris créa le ver Morris en 1988. Ce ver infecta de nombreux systèmes sur Internet, notamment ceux de la NASA, de Harvard et de Stanford. Morris enfreignit la loi de 1986 sur l'abus et la fraude informatiques (Computer and Fraud Abuse Act), mais bien qu'il ait été condamné, il n'a pas purgé de peine de prison.
Les années 1990 ont vu les pouvoirs publics recourir de manière plus intensive aux portes dérobées. Le Le Clipper Chip fut une tentative ratée d'intercepter les communications. Un seul téléphone fut commercialisé et, en 1996, le projet fut abandonné.
Depuis la fin des années 2000 jusqu’aux années 2020, les pirates informatiques exploitent des portes dérobées pour mener des attaques à grande échelle sur le Web. Ils ont même commencé à infiltrer les services cloud et les appareils connectés.
Conséquences des attaques par porte dérobée
Les portes dérobées sont dangereuses parce qu'elles sont dissimulées. La culture populaire y fait référence depuis longtemps : le film WarGames, sorti en 1983, comporte même une scène expliquant le fonctionnement de ces mécanismes d'accès cachés. Elles peuvent parfois être si bien dissimulées qu'il faut des mois, voire des années, pour les détecter.
Au-delà de npm audit
Bien que des outils tels que npm audit constituent une bonne première étape, ils ne détectent souvent que les fantômes qui ont déjà causé des dégâts. Pour sécuriser véritablement votre chaîne d'approvisionnement, nous devons passer d'une approche une approche réactive à proactifs .
Intégrité du fichier de verrouillage
Modifiez votre package-lock.json ou yarn.lock comme un document protégé. N'ignorez jamais les modifications qui y sont apportées et assurez-vous que votre pipeline CI/CD applique strictement ces versions. Une chose à garder à l'esprit est de toujours valider vos fichiers de verrouillage. Lorsque vous validez votre fichier de verrouillage, vous « verrouillez » les versions des paquets qui ont été installés afin que tous les membres de l'équipe utilisent exactement les mêmes.
Cependant, l'intégrité ne se limite pas à la simple correspondance des numéros de version. Le fichier de verrouillage contient un URL et une hachage (généralement SHA-512). Ce hachage constitue votre principale défense contre « empoisonnement du registre ». Si un registre est compromis et qu'un attaquant remplace un paquet légitime par un paquet malveillant de la même version, le hachage changera. En utilisant npm clean-install (ou npm ci) dans vos pipelines de build, l'installation échouera si le hachage du paquet téléchargé ne correspond pas à celui du fichier de verrouillage. Cela équivaut à une « empreinte digitale » pour votre code ; si l'empreinte ne correspond pas, vous savez que le fantôme a altéré le fichier.
De plus, vous devez vous méfier des attaques de type « injection de fichier de verrouillage ». Dans ce cas, un contributeur malveillant soumet une Pull Request qui ressemble à une simple mise à jour de dépendances, mais qui inclut un fichier de verrouillage modifié renvoyant vers une URL malveillante pour une dépendance transitive. Soumettez toujours vos modifications du fichier de verrouillage à une révision par les pairs avec autant de rigueur que pour votre code source. Si une PR ajoute 5 000 lignes à un fichier lockfile pour un « correctif mineur », il est temps de commencer à se poser des questions.
SBOM (liste des composants logiciels)
Si vous ne savez pas ce que contient votre « galaxie de dépendances », vous ne pouvez pas la protéger. La génération d'une SBOM vous fournit un inventaire clair de tous les composants de votre chaîne d'approvisionnement logicielle. Considérez la SBOM comme la « liste des ingrédients » au dos d’une pizza surgelée. Si vous découvrez par la suite que le « colorant rouge n° 40 » est toxique, vous pouvez vérifier votre garde-manger et savoir immédiatement quels produits jeter. En matière de logiciels, lorsqu’un nouveau CVE (Common Vulnerabilities and Exposures) est annoncé pour une dépendance transitive profonde, une SBOM vous permet de passer au crible l’ensemble de votre écosystème en quelques secondes plutôt que d’auditer manuellement chaque projet.
Il existe deux normes industrielles principales pour les SBOM : SPDX (Software Package Data Exchange) et CycloneDX. Alors que le SPDX est une norme ISO souvent privilégiée pour les questions de licence et de conformité, CycloneDX est un format léger axé sur la sécurité, spécialement conçu pour la sécurité des applications et l'analyse de la chaîne d'approvisionnement.
Une stratégie de sécurité véritablement aboutie ne se contente pas de générer une SBOM ; elle l'utilise en association avec VEX (Vulnerability Exploitability eXchange). VEX est un document complémentaire qui vous indique si une vulnérabilité détectée dans votre SBOM est réellement « accessible » ou « exploitable ». Cela évite la « fatigue des vulnérabilités », ce sentiment accablant que l'on ressent lorsqu'on voit 400 alertes « élevées » sans savoir laquelle corriger en premier. En combinant une SBOM avec VEX, vous pouvez prouver à vos utilisateurs que même si un « fantôme » se cache peut-être dans une bibliothèque que vous utilisez, il est enfermé dans une pièce d'où il ne peut nuire à personne.
Minimalisme
Le code le plus sûr est celui que l'on n'installe jamais. Avant d'ajouter une nouvelle dépendance, posez-vous la question suivante : « Puis-je écrire cet utilitaire moi-même ? » ou « Cette bibliothèque entraîne-t-elle 500 dépendances transitives simplement pour mettre une date en forme ? »
Conclusion : mettez fin au cauchemar avant même qu'il ne commence
La plupart des attaques visant la chaîne d'approvisionnement auxquelles nous assistons aujourd'hui ne viennent pas par la grande porte, mais proviennent des dépendances transitives que nous avons intégrées sans y réfléchir à deux fois.
En tant que développeurs, nous sommes les gardiens. Nous devons faire preuve de la même rigueur vis-à-vis du code que nous empruntons que pour celui que nous écrivons. Il est temps de faire la lumière sur les recoins obscurs de node_modules et de s’assurer qu’aucun fantôme ne se cache dans la machine.
