1. Ce qui a changé avec l’écosystème npm

Pendant longtemps, les risques liés à npm étaient vus comme quelque chose de relativement théorique :

• des librairies un peu obscures,
• des mainteneurs fantômes,
• quelques projets abandonnés.

Aujourd’hui, l’enjeu est tout autre :

• des dépendances pourtant populaires peuvent être modifiées ou reprises,
• des scripts d’installation peuvent accéder à votre environnement (process.env),
• des fichiers locaux, des clés SSH ou des tokens peuvent être ciblés.
  
  

Et surtout, l’attaque ne reste pas sur le poste du développeur.

Elle peut ensuite toucher :

• vos repositories (si des tokens Git sont exposés),
• vos pipelines CI/CD,
• vos environnements cloud (si des crédenciales sont présents localement),
• des services tiers auxquels votre environnement a accès.
  
  

En clair, une dépendance compromise n’est plus seulement un problème de code. C’est un point d’entrée dans votre chaîne de valeur.

2. Dans un projet JS, npm engage beaucoup plus que le poste d’un dev

Sur un projet JavaScript classique, on voit souvent le même scénario :

• un dev ajoute une lib “vite fait” pour tester une idée,
• une mise à jour mineure est faite “en passant”,
• une nouvelle dépendance apparaît dans package.json sans vraie discussion.
  
  

Sur le moment, ça ressemble à un détail technique.

En réalité, à chaque `npm install` :

• vous ajoutez du code tiers qui s’exécute sur vos machines,
• vous élargissez votre surface d’attaque,
• vous rendez plus difficile le suivi de qui a introduit quoi, quand et pourquoi.
  
  

Ce n’est plus un geste individuel isolé. C’est une action qui impacte toute la chaîne technique : développeurs, CI/CD, environnements de staging, de production, voire les postes d’autres équipes (Ops, QA…).

3. Quatre règles simples pour reprendre le contrôle sur npm install

L’objectif n’est pas de transformer chaque ajout de dépendance en comité de validation de trois heures. Mais quelques règles légères peuvent déjà changer beaucoup de choses.

3.1. Séparer l’envie de tester d’une dépendance “officielle”

Tester une nouvelle librairie est une excellente chose. Le risque, c’est de le faire directement dans le projet principal, avec tous les secrets, tokens et config qui vont avec.

Bon réflexe :

• expérimenter une lib dans un petit projet séparé, sans secrets, sans accès sensibles,
• ne l’ajouter au vrai package.json qu’une fois le besoin confirmé (et la lib comprise).
  
  

On garde ainsi le côté exploratoire, tout en évitant de transformer l’application principale en terrain d’expérimentation permanent.

3.2. Toujours déployer depuis un lockfile validé

Un des meilleurs garde-fous reste le lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml).

Quelques principes simples :

• ne jamais déployer sur un environnement sensible (staging / prod) sans lockfile validé,
• éviter les installs “fraîches” en prod qui vont chercher la dernière version disponible au hasard,
• intégrer le lockfile dans la revue de code (PR) au même titre que le code applicatif.
  
  

L’idée : ce que vous déployez doit être exactement ce que vous avez testé, pas ce que l’écosystème npm a décidé de publier entre-temps.

3.3. Traiter l’ajout de dépendance comme une décision de design

Ajouter une lib n’est pas un simple “gain de temps”. C’est une décision d’architecture.

Avant d’ajouter une dépendance, quelques questions à rendre systématiques :

• Doublon ? On n’a pas déjà une lib équivalente dans le projet (ou dans le standard de l’entreprise) ?
• Maintenance ? Le repo est-il maintenu ? Issues répondues ? Dernier commit récent ?
• Installation ? Est-ce qu’on a regardé ce que fait la lib au moment de l’install (scripts, postinstall, etc.) ?
• Périmètre ? Est-ce qu’on ne peut pas faire la même chose avec un peu de code interne, mieux maîtrisé ?
  
  

Une dépendance en plus, c’est :

• du confort immédiat,
• une surface d’attaque et de maintenance à long terme.

3.4. Mettre en place des garde-fous automatiques

Ce n’est pas au développeur, seul devant sa console, de porter 100 % du poids de la décision.

Quelques garde-fous techniques simples à mettre en place au niveau de l’organisation :

• alertes de sécurité sur les repos (GitHub Security Alerts, GitLab, etc.),
• scan régulier des dépendances (npm audit, scanners tiers, intégration CI),
• surveillance des libs critiques : auth, crypto, HTTP, ORM, logging, monitoring…
  
  

Ce sont celles qui méritent le plus d’attention (et parfois un fork ou une alternative interne).

Le but est de faire en sorte que les problèmes évidents soient détectés automatiquement, sans compter uniquement sur la vigilance manuelle des devs.

4. Changer la façon de voir npm install

L’idée n’est pas de faire paniquer toute l’équipe à chaque install, ni de bloquer la vélocité.

L’idée, c’est de changer le réflexe mental :

npm install ce n’est plus “ajouter un petit bout de code pratique”. C’est exécuter du code tiers dans un environnement qui a de la valeur.

À partir du moment où on le voit comme ça :

• on devient naturellement plus exigeant sur ce qu’on ajoute,
• on accepte plus facilement de séparer expérimentation et prod,
• on comprend que le choix d’une dépendance est un choix de sécurité.
  
  

npm install restera toujours une commande ultra-courante. Ce qui doit évoluer, ce n’est pas la commande elle-même, c’est la culture qui l’entoure.

Et après ?

Si vous avez :

• un mono-repo JS/TS avec des dizaines de dépendances,
• des pipelines CI/CD critiques,
• ou une production cloud où “tout passe par npm”,
  
  

c’est sans doute le bon moment pour :

• cartographier vos dépendances,
• identifier les packages sensibles,
• mettre en place quelques garde-fous simples (process + outils).

Ce sont des sujets que nous traitons régulièrement chez Etixio avec nos clients : audits JavaScript/TypeScript, sécurisation de la chaîne de build, bonnes pratiques autour de npm, pnpm, yarn, et durcissement des pipelines CI/CD.

Si vous voulez faire un état des lieux de vos dépendances et réduire votre surface d’attaque sans casser la productivité des devs, on peut en parler.