Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Chaque npm install C'est un acte de confiance. Vous est-il déjà arrivé de fixer du regard votre node_modules dossier et je me suis demandé : qu'est-ce qu'il y a vraiment là-dedans ?? Dans le développement logiciel moderne, nous évoluons dans un univers étrange où nous sommes responsables d’un iceberg invisible de code que nous n’avons pas écrit. Une grande partie de ce code nous parvient sous forme de dépendances transitives, c’est-à-dire des bibliothèques que personne au sein de l’équipe n’a choisies directement. Lorsque ce code est déployé en production, cette responsabilité se transforme en anxiété. SecureChain offre un rempart permettant de gérer une partie de cette pression exercée par des tiers.
L'iceberg des dépendances transitives
Avant d’installer un paquet qui apparaît comme une dépendance directe, vous pouvez vérifier le nombre d’étoiles sur GitHub, le profil du responsable du projet et ceux des contributeurs. Une bibliothèque est rarement seule. Un paquet transitif est installé en même temps parce qu’une dépendance directe l’exige. Considérez-les comme des « paquets de vos paquets », voire des « paquets de paquets de vos paquets ». Ils peuvent s’étendre sur plusieurs niveaux de profondeur sans que vous ayez à y toucher.
Cet iceberg est bien plus profond qu'il n'y paraît, et le jeu de mots est tout à fait intentionnel. Une application web « basique » peut facilement dépasser le cap des 1 000 paquets stockés dans votre node_modules. C'est dans les dépendances transitives enfouies en profondeur que se cachent souvent les attaques visant la chaîne d'approvisionnement. Elles élargissent considérablement l'étendue du code tiers dont vous héritez, et les audits manuels parviennent rarement à atteindre ce niveau de profondeur.
Le problème n'est pas que les dépendances transitives soient néfastes ; le développement moderne en dépend. Le problème, c'est que le code dont vous héritez se développe plus vite que celui que vous examinez.
Quand ce qui semble malveillant paraît légitime
Cette inquiétude provient de ces paquets qui semblent légitimes, mais qui sont en réalité malveillants. En tant que développeurs, nous nous appuyons beaucoup sur la mémoire musculaire pour accomplir notre travail. Or, avec l’IA, ce processus ne nécessite même plus cela. Les assistants de programmation suggèrent parfois des noms de paquets qui n’existent pas. Cela ouvre la voie à une nouvelle pratique appelée « slopsquatting » : enregistrer le nom qu’un modèle ne cesse d’imaginer, puis attendre.
Vous trouverez ci-dessous une liste de certains des plus courants.
Typosquatting
Les attaques de « typosquatting » reposent sur l’enregistrement par les attaquants de paquets dont les noms sont pratiquement impossibles à distinguer de ceux de bibliothèques légitimes et populaires, en pariant que quelqu’un fera une faute de frappe, lira en diagonale ou fera confiance à une suggestion. Ces paquets imitent souvent les fonctionnalités de la cible, de sorte que rien ne semble immédiatement anormal. Parmi les tactiques courantes, on peut citer :
- Remplacement de caractères : Permuter des lettres, comme dans
lodashetlodahs, un véritable paquet malveillant qui visait les portefeuilles de cryptomonnaies. Les nouveaux noms npm doivent être en minuscules et compatibles avec les URL ; les faux noms s'appuient donc sur des astuces qui contournent ces règles, comme un1à la place d'unl. - Imitation d'espace de noms ou de portée : enregistrement de paquets à portée limitée dont les noms imitent étroitement ceux des bibliothèques officielles, ce qui diffère de l'attaque par résolution du registre décrite ci-dessous.
- Variantes de format : En utilisant des astuces de césure (par exemple,
crossenvcontrecross-env) ou en modifiant la forme plurielle.
Comme ces paquets peuvent exécuter du code arbitraire lors de leur installation, ils sont capables de voler des clés API, des variables d'environnement ou des identifiants AWS avant même que quiconque n'ait pu examiner le code source.
Confusion des dépendances
Les attaques de type « Dependency Confusion » ciblent les organisations qui utilisent à la fois des registres publics et privés. Un attaquant peut exploiter cette configuration en publiant un paquet malveillant portant le même nom qu’un paquet interne, en lui attribuant généralement un numéro de version supérieur. Si votre configuration de compilation n’est pas strictement isolée, le système peut associer le nom du paquet à la version publique de l’attaquant plutôt qu’à votre version interne, ce qui entraîne l’exécution automatique du code malveillant lors de l’installation.
Tout cela n'a rien de théorique. Alex Birsan l'a prouvé en 2021, en publiant des paquets portant le nom de bibliothèques internes et en constatant qu'ils étaient pris en charge au sein des systèmes d'Apple, de Microsoft et de dizaines d'autres organisations.
Pour ceux qui ne sont pas familiers avec ce concept, les paquets avec portée (par exemple, @my-org/cool-package) utilisez un @ symbole aux dépendances d'espace de noms. La vulnérabilité de votre organisation dépend souvent de la manière dont vous configurez votre registre, votre périmètre, vos proxys et vos fichiers de verrouillage. Les systèmes qui n'ont jamais fait l'objet d'un audit concernant ces comportements de routage sont les plus exposés. Pour sécuriser votre pipeline, assurez-vous que la résolution de vos paquets est déterministe. Associez les périmètres privés à votre registre interne dans .npmrc de manière explicite, afin que votre gestionnaire de paquets ne résolve pas de manière inattendue cette portée via le registre public :
@my-org:registry=https://registry.internal.example.com/Le fait de revendiquer des espaces de noms correspondants sur npmjs.com empêche également les attaquants de publier sous une identité dont vous êtes déjà propriétaire. Gardez à l’esprit que la délimitation des espaces de noms relève avant tout d’une convention de nommage, et non d’un contrôle de sécurité. Si un même nom de dépendance peut être résolu à partir de deux emplacements différents, c’est quelqu’un d’autre qui prendra cette décision à votre place.
Scripts de cycle de vie
Package.json les hooks de cycle de vie tels que preinstall, install,et postinstall s'exécutent automatiquement lors de l'installation des dépendances, bien avant qu'un membre de l'équipe de développement n'ait eu l'occasion d'examiner leur contenu.
Ces charges utiles ciblent les cibles les plus importantes : infrastructures bancaires, serveurs de compilation, etc. Elles extraient des informations confidentielles cruciales, notamment .env les fichiers, les jetons AWS et les clés SSH : exactement ce qu’on nous répète sans cesse de ne jamais ajouter au système de contrôle de version.
Certains scripts commencent par analyser l'environnement, à la recherche de « sandboxes » ou de systèmes étroitement surveillés, et attendent avant de se déclencher jusqu'à ce qu'ils se retrouvent dans un environnement moins protégé.
Shai-Hulud a montré l'ampleur que cela peut prendre. La vague de septembre 2025 a utilisé postinstall pour récupérer des jetons npm et des identifiants de connexion au cloud dans des centaines de paquets, puis s'est republié en intégrant les informations volées. La vague de novembre a avancé le moment de l'exécution, pour le faire intervenir plus tôt, dans preinstall, de sorte que la charge utile s'est exécutée avant la fin de l'installation. Des variantes ultérieures se sont dissimulées dans des dépendances facultatives, exécutant la charge utile avant de provoquer un échec de manière à ce que npm le tolère.
Cela dit, le comportement par défaut a enfin changé. pnpm À partir de la version 10, l'exécution automatique des scripts du cycle de vie des dépendances a été désactivée ; désormais, tout élément devant faire l'objet d'une compilation doit être répertorié dans onlyBuiltDependencies. La version 12 de npm, publiée le 8 juillet 2026, a adopté la même position : les scripts de dépendances ne s’exécutent pas à moins que le paquet racine allowScripts si leur politique le leur permet, et npm approve-scripts --allow-scripts-pending répertorie tout ce qui est en attente d'une décision.
Il y a toutefois un hic. Un script non approuvé est ignoré avec un message d'avertissement, mais l'installation renvoie tout de même un code de sortie 0, ce qui peut laisser une dépendance native à moitié construite et entraîner un échec ultérieur lors de la compilation ou de l'exécution. Validez le allowScripts bloquer et définir strict-allow-scripts=true Dans CI, les scripts non validés entraînent donc l'échec de la compilation. Si vous utilisez npm 11 ou une version antérieure, l'option ci-dessous gère cela pour vous :
npm install --ignore-scriptsUtile, oui. Exhaustif, non. Rien de tout cela ne traite de l'exécution au moment de l'importation, ni d'un paquet malveillant dont le code de niveau supérieur se déclenche dès que votre application appelle require() contourne sans peine les mesures de protection du script d'installation.
Nous subissons une pression énorme lorsqu’il s’agit d’assumer la responsabilité du code que nous diffusons. Dans le rapport « Open Source Landscape Report 2026 » de TuxCare, parmi les personnes interrogées dont les organisations avaient signalé un incident de cybersécurité, 61,4 % ont déclaré qu’un correctif était DISPONIBLE mais n’avait jamais été appliqué. Ce chiffre devrait être extrêmement faible. Savoir qu’un risque existe n’équivaut pas à l’éliminer.
La profondeur des dépendances complique les choses. Une correction apportée en amont n'a aucun effet sur la copie située quatre niveaux plus bas dans votre arborescence.
La révision manuelle a toujours sa place dans le processus, mais il n’est pas réaliste de procéder à un audit manuel d’un graphe de cette taille. Le manque de visibilité sur ce que vous déployez peut compromettre votre infrastructure, et finira inévitablement par le faire.
Vaincre l'anxiété grâce à SecureChain
La gestion des risques liés aux dépendances doit faire partie intégrante de la politique. Mettre en œuvre cette gestion à grande échelle peut s'avérer insurmontable pour n'importe quelle équipe. SecureChain modifie le parcours de consommation. Au lieu de récupérer directement depuis le registre public, vos builds s'approvisionnent à partir d'un registre de paquets géré par TuxCare, dans lequel les paquets ont été recompilés, signés et corrigés selon un calendrier publié.
Chaque registre reste un acte de confiance. Ce qui change, c'est qu'une plus grande partie de cette confiance devient vérifiable.
Renforcement du code source
Chaque paquet, y compris les dépendances transitives, est recompilé à partir du code source dans des environnements sécurisés et isolés, puis analysé à la recherche de logiciels malveillants connus et de code suspect, plutôt que de redistribuer tel quel tout artefact publié en amont.
Mises à jour continues
SecureChain fournit des correctifs dans le cadre du SLA dès l'apparition de vulnérabilités CVE. Pour les paquets dont la prise en charge en amont arrive à terme, le service Endless Lifecycle Support (ELS) continue d'appliquer les correctifs critiques et de gravité élevée aux versions que vous utilisez déjà.
Configurez votre gestionnaire de paquets pour qu’il utilise SecureChain, ou le gestionnaire de référentiels que vous utilisez déjà, compatible avec Artifactory et Nexus. Vous obtiendrez ainsi des informations de provenance conçues pour garantir une conformité SLSA de niveau 3 vérifiable, des documents VEX indiquant les CVE affectant une version de paquet, ainsi que des SBOM lisibles par machine pour l’ensemble des composants pris en charge, dont la couverture ne cesse de s’étendre. Rien de tout cela ne remplace toutefois les bonnes pratiques de sécurité. Vous devez toujours utiliser des fichiers de verrouillage, des règles de registre à portée limitée et des identifiants CI basés sur le principe du privilège minimal.
À retenir
Vous pouvez atténuer quelque peu votre inquiétude lorsque vous déployez du code que vous n'avez pas écrit vous-même. La sécurité est une tâche et une politique de longue haleine. Il ne s'agit en aucun cas d'une approche ou d'une pratique du type « configurez-le et n'y pensez plus ». Comprendre les dépendances transitives et prendre conscience des problèmes qui en découlent vous aidera à déployer un code de production fiable.
Le but n'est pas de cesser de faire confiance à l'open source. Nous en dépendons tous. Le but est de cesser de considérer cette confiance comme quelque chose d'invisible.
L'utilisation d'outils tels que SecureChain peut alléger quelque peu ce lourd fardeau qui pèse sur nous tous. Gardez une longueur d'avance et sécurisez VOTRE chaîne d'approvisionnement.
