Sécuriser sa chaîne d'approvisionnement npm

Un risque à grande échelle

Un projet Next.js compte vite plusieurs centaines de paquets, directs et transitifs. Chacun est du code exécuté sur votre machine, en CI, voire en production. Compromettre un seul maillon suffit : c'est une attaque de la chaîne d'approvisionnement.

Les menaces courantes

• Typosquatting : un paquet au nom proche (reakt au lieu de react).
• Compte de mainteneur compromis : une version malveillante est publiée.
• Scripts d'installation : postinstall s'exécute au npm install.
• Dépendance abandonnée : plus de correctifs de sécurité.

1. Versionner le lockfile

package-lock.json fige l'arbre exact des versions et leurs empreintes d'intégrité. En CI, préférez :

npm ci

Cette commande installe exactement ce que décrit le lockfile et échoue en cas d'écart, contrairement à npm install.

2. Auditer régulièrement

npm audit
npm audit --omit=dev   # uniquement ce qui part en production

L'audit signale des vulnérabilités connues. Il ne détecte pas un paquet fraîchement piégé, mais reste un filet de base.

3. Automatiser les mises à jour

Dependabot ou Renovate ouvrent des pull requests de mise à jour. Avantage : de petites étapes, relues et testées par la CI, plutôt qu'un gros saut une fois par an.

4. Réduire la surface

• Chaque dépendance ajoutée est une confiance accordée : demandez-vous si dix lignes de code ne suffisent pas.
• Vérifiez l'activité, le nombre de mainteneurs et l'ancienneté du paquet avant d'adopter.
• Désactivez les scripts à l'installation quand c'est possible :

npm ci --ignore-scripts

5. Limiter les droits

• Les jetons de publication npm doivent avoir une portée minimale et activer l'authentification à deux facteurs.
• En CI, ne donnez accès aux secrets qu'aux jobs qui en ont besoin.

Une checklist rapide

À retenir

La sécurité d'une application dépend de celle de ses dépendances. On ne peut pas tout vérifier à la main : on automatise, on réduit le nombre de paquets et on garde le lockfile sous contrôle.