Comment auditer vos dependances npm contre les attaques supply chain en 7 etapes

La prochaine attaque supply chain npm ne se fera pas remarquer. Elle arrivera dans une mise a jour de routine d'un paquet que vous utilisez depuis trois ans. Le code malveillant sera dans une dependance de deuxieme ou troisieme niveau — un utilitaire de formatage de date, un parseur de query string, une bibliotheque de validation de schemas. Quelque chose de tellement banal que personne ne le regarde deux fois.

En 2026, cette menace n'est plus theorique. Les attaques documentees atteignent environ 9 par mois sur les registres npm et PyPI combines. La campagne Shai-Hulud a compromis 444 paquets npm d'un coup en aout 2026. Le ver Miasma a touche 57 paquets en juin. Et ce ne sont que les attaques detectees et publiees.

Ce guide propose 7 etapes concretes pour auditer vos dependances npm et reduire votre surface d'attaque. Il n'elimine pas le risque — aucune methode ne le peut — mais il le ramene a un niveau gerable. Chaque etape est independante : commencez par celle qui correspond a votre situation actuelle.

Etape 1 : Executez npm audit et traitez les resultats (30 minutes)

C'est le point de depart, pas la destination. npm audit compare vos dependances installees a la base de donnees GitHub Advisory et signale les vulnerabilites connues. C'est necessaire et tres insuffisant — mais c'est l'etape que beaucoup d'equipes sautent parce qu'elles savent qu'elle va produire du bruit.

Executez la commande dans votre projet :

npm audit --production
# Pour un rapport exploitable en JSON :
npm audit --json > audit-report.json
# Pour ne voir que les vulnerabilites critiques et hautes :
npm audit --audit-level=high

Le piege classique est de lancer npm audit fix sans regarder ce qu'il va faire. Cette commande met a jour les paquets vers des versions corrigees, mais elle peut casser votre application si la mise a jour inclut des changements de comportement. Traitez chaque vulnerabilite individuellement :

• Critique ou haute dans une dependance de production : corrigez immediatement, testez, deployez.
• Moyenne ou basse dans une dependance de production : planifiez la correction dans le prochain sprint.
• Toute severite dans une dependance de developpement uniquement : evaluez si elle peut etre exploitee lors du build (la reponse est souvent oui dans un pipeline CI/CD).

La limite de npm audit est structurelle : il ne detecte que ce qui est deja dans la base de donnees. Un paquet malveillant publie hier et pas encore signale n'apparaitra pas. C'est pourquoi les 6 etapes suivantes existent.

Etape 2 : Verifiez et verrouillez votre lockfile (20 minutes)

Le fichier package-lock.json est le seul endroit ou l'arbre complet de vos dependances est decrit, avec les versions exactes et les hashes d'integrite. Si ce fichier n'est pas commite dans votre depot, vous ne savez pas ce qui est installe en production. Si ce fichier est modifie sans que personne ne le remarque, un attaquant peut substituer une dependance.

Trois verifications immediates :

# 1. Verifier que le lockfile est a jour
npm ci  # echoue si package.json et package-lock.json sont desynchronises

# 2. Verifier l'integrite des paquets installes
npm audit signatures

# 3. Compter vos dependances transitives
jq '.packages | length' package-lock.json

Ce dernier chiffre est generalement celui qui surprend. Un projet Next.js standard a Paris, Lyon ou ailleurs en France embarque entre 500 et 1 200 dependances transitives. Chacune est un maillon de votre chaine de confiance. Chez les equipes que nous auditons a Nantes et a Bordeaux, le chiffre moyen est de 683 dependances transitives pour un projet de taille moyenne.

Ajoutez une regle dans votre pipeline CI pour rejeter toute pull request qui modifie le lockfile sans justification. La modification du lockfile doit etre un acte delibere, pas un effet de bord d'un npm install lance sur un poste de developpement avec une version de Node differente.

Etape 3 : Epinglez les versions de vos dependances directes (45 minutes)

Par defaut, npm utilise le prefixe ^ dans package.json, ce qui autorise les mises a jour mineures et patch automatiques. C'est pratique pour recevoir les correctifs, mais c'est aussi le mecanisme que les attaquants exploitent : publier une version patch d'un paquet compromis, et la prochaine installation l'integre automatiquement.

# Configurer npm pour epingler par defaut
npm config set save-exact true

# Pour un projet existant, retirer les ^ et ~ de package.json :
npx npm-check-updates --removeRange

# Verifier les ecarts entre package.json et package-lock.json :
npx syncpack list-mismatches

L'objection la plus frequente des equipes que nous accompagnons, a Paris comme a Lyon, est : « Si on epingle tout, on ne recoit plus les correctifs de securite automatiquement. » C'est exact, et c'est le but. La question n'est pas de recevoir les correctifs plus vite, c'est de ne jamais executer du code que vous n'avez pas verifie. L'etape 7 (surveillance continue) compense en vous alertant quand un correctif est disponible, et vous decidez de l'appliquer apres verification.

Pour les monorepos, utilisez syncpack pour garantir que toutes les workspaces utilisent la meme version de chaque dependance. Des versions divergentes dans un monorepo sont un angle mort d'audit.

Etape 4 : Generez un SBOM de vos dependances (30 minutes)

Un SBOM (Software Bill of Materials) est la liste complete et structuree de tous les composants logiciels de votre projet, dependances transitives incluses. C'est le document qui repond a la question « qu'est-ce qui tourne exactement en production ? » — et dans la plupart des equipes, personne ne peut repondre a cette question sans un SBOM.

# Generer un SBOM au format CycloneDX (le plus adopte pour npm)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Ou au format SPDX si votre politique de conformite l'exige
npx spdx-sbom-generator -p .

# Analyser le SBOM pour les dependances a risque
npx bomber scan sbom.json

Le SBOM n'est pas un document que vous generez une fois et que vous oubliez. Il doit etre regenere a chaque changement de dependance et stocke avec l'artefact de build. En 2026, la reglementation europeenne (CRA — Cyber Resilience Act) va rendre le SBOM obligatoire pour les produits logiciels vendus dans l'UE. Les equipes a Paris et a Lyon qui s'y preparent maintenant auront un avantage significatif.

Ce que le SBOM revele souvent : des dependances transitives dont le mainteneur a change sans que personne ne le remarque, des paquets abandonnes depuis deux ans mais toujours presents dans l'arbre, et des licences incompatibles avec votre modele de distribution. A Bordeaux, une equipe que nous avons accompagnee a decouvert via son premier SBOM que 23 de ses dependances transitives n'avaient pas ete mises a jour depuis plus de 18 mois — un signe classique de paquet abandonne ou potentiellement repris par un acteur malveillant.

Etape 5 : Ajoutez une analyse comportementale (45 minutes)

L'analyse comportementale est le complement indispensable de npm audit. Au lieu de chercher des vulnerabilites connues, elle analyse ce que le code fait reellement : acces reseau, lecture du systeme de fichiers, execution de commandes systeme, acces aux variables d'environnement. Un paquet de formatage de dates qui envoie des requetes HTTP vers un serveur inconnu est une anomalie, meme s'il n'est dans aucune base de vulnerabilites.

# Socket.dev - le plus efficace pour la detection comportementale
npx socket report create --output report.json

# Ou via l'integration GitHub (gratuit pour les projets open source)
# Installer l'application Socket sur votre depot GitHub

# Alternative open source : Packj
pip install packj
packj audit npm <nom-du-paquet>

Socket.dev est l'outil que nous recommandons le plus souvent aux equipes que nous accompagnons, a Nantes comme ailleurs. Il detecte les comportements suspects avant meme qu'un paquet ne soit signale comme malveillant : scripts d'installation qui executent du code natif, acces aux variables d'environnement contenant des mots-cles sensibles, connexions reseau vers des domaines recemment enregistres.

L'integration dans le pipeline CI est directe : ajoutez le scan Socket comme etape bloquante apres l'installation des dependances et avant le build. Toute anomalie detectee arrete le pipeline et alerte l'equipe. Le taux de faux positifs est faible — environ 2 a 3 % dans notre experience — et chaque faux positif merite de toute facon une verification manuelle rapide.

Etape 6 : Mettez en place un registre npm prive (2-4 heures)

Toutes les etapes precedentes analysent ce qui est deja installe. Un registre prive avec liste d'autorisation empeche l'installation d'un paquet non approuve. C'est la seule mesure qui protege contre les attaques que personne n'a encore detectees.

Le principe est simple : au lieu de resoudre les paquets directement depuis le registre public npm, votre projet pointe vers un registre interne qui ne contient que les paquets que vous avez explicitement approuves. Tout paquet inconnu provoque un echec d'installation franc, et un humain decide s'il doit etre ajoute.

# Option 1 : Verdaccio (open source, auto-heberge)
docker run -d --name verdaccio -p 4873:4873 verdaccio/verdaccio
npm set registry http://localhost:4873/

# Option 2 : .npmrc au niveau du projet (approche intermediaire)
echo "registry=https://votre-registre.example.com/" > .npmrc
echo "//votre-registre.example.com/:_authToken=${NPM_TOKEN}" >> .npmrc

# Configurer Verdaccio pour proxifier le registre public avec approbation
# Modifier le fichier config.yaml de Verdaccio :
# uplinks:
#   npmjs:
#     url: https://registry.npmjs.org/
# packages:
#   '**':
#     access: $all
#     publish: $authenticated
#     proxy: npmjs  # <- retirer cette ligne pour bloquer le proxy

L'investissement est de 2 a 4 heures pour la mise en place initiale, puis une charge d'exploitation faible. Pour une PME francaise, Verdaccio sur un VPS OVH ou Scaleway offre le meilleur rapport controle/cout avec la garantie que les donnees restent en France.

Etape 7 : Automatisez la surveillance continue (1-2 heures)

Un audit ponctuel est necessaire mais insuffisant. Les nouvelles vulnerabilites sont publiees quotidiennement, les mainteneurs changent, les paquets sont repris par de nouveaux proprietaires. La surveillance continue transforme l'audit ponctuel en processus permanent.

# GitHub Dependabot - activer dans .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    # IMPORTANT : ne pas merger automatiquement
    # Chaque PR de mise a jour doit etre verifiee manuellement

# Renovate Bot - alternative plus configurable
# Installer l'application Renovate sur votre depot GitHub
# Configurer renovate.json :
{
  "extends": ["config:base"],
  "rangeStrategy": "pin",
  "automerge": false,
  "prConcurrentLimit": 5,
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
  }
}

La regle critique : jamais de merge automatique pour les mises a jour de dependances. Dependabot et Renovate peuvent creer les pull requests automatiquement, mais la decision de merger doit rester humaine. C'est exactement le mecanisme que TeamPCP a exploite dans l'attaque LiteLLM : une mise a jour automatique d'une dependance partagee a introduit le code malveillant sans verification humaine.

Ajoutez egalement une surveillance des changements de mainteneurs. Quand le proprietaire d'un paquet npm change, c'est un signal d'alerte qui merite une verification. L'outil npm owner ls <paquet> montre les mainteneurs actuels ; comparez-les periodiquement avec une reference de base.

Recapitulatif : temps et priorites

L'ordre n'est pas arbitraire. Les etapes 1 et 2 revelent l'etat actuel — c'est le diagnostic. Les etapes 3 a 6 durcissent la surface d'attaque. L'etape 7 garantit que le durcissement ne se degrade pas avec le temps. Pour approfondir le volet CI/CD, notre guide securiser vos pipelines GitHub Actions couvre les mesures de protection du pipeline lui-meme. Et si votre projet utilise egalement des dependances Python, la meme demarche est detaillee dans notre guide auditer ses dependances Python en 7 etapes.

Pour le volet gouvernance et conformite — NIS2, CRA, RGPD — nos confreres de WebGuard Agency traitent les obligations reglementaires en detail. Et pour les equipes qui integrent des outils d'IA dans leur pipeline de developpement, un audit des dependances de ces outils est tout aussi critique — les equipes de Plug-Tech documentent regulierement les risques specifiques a ce perimetre.

Questions frequentes