Comment sécuriser les dépendances NPM ? Guide complet de la sécurité de la chaîne d'approvisionnement pour les développeurs d'API

En bref

Les attaques de la chaîne d'approvisionnement NPM ont atteint plus de 3 000 paquets malveillants rien qu'en 2024, et le compromis Axios de mars 2026 a prouvé que même les paquets du top 10 ne sont pas sûrs. Ce guide couvre chaque couche de défense dont les développeurs d'API ont besoin : application des fichiers de verrouillage, blocage des scripts post-installation, vérification de la provenance, outils d'analyse comportementale et choix architecturaux qui réduisent votre surface d'attaque.

Introduction

L'attaque de la chaîne d'approvisionnement Axios du 31 mars 2026 n'était pas le premier compromis npm. Ce ne sera pas le dernier. Mais avec 83 millions de téléchargements hebdomadaires et un RAT multiplateforme déployé via un seul compte de mainteneur piraté, ce fut le plus fort avertissement que l'écosystème JavaScript ait reçu.

Voici ce qui la différencie du conseil habituel "mettez à jour vos dépendances" : l'attaque Axios a contourné toutes les défenses traditionnelles. Le code malveillant ne se trouvait pas dans Axios lui-même. Il a été injecté via une dépendance fantôme qui a déclenché un hook postinstall. Les fichiers de verrouillage n'ont pas aidé si vous avez exécuté npm install pendant la fenêtre d'attaque. L'épinglage de version n'a pas aidé si vous n'aviez pas encore épinglé.

Les développeurs d'API sont particulièrement exposés. Vos scripts de test, pipelines CI/CD, serveurs de maquette et clients HTTP tirent tous de npm. Un seul paquet compromis dans votre chaîne d'outils peut divulguer des clés API, des identifiants de base de données et des jetons cloud depuis votre machine de développement.

Ce guide couvre sept couches de protection, de l'hygiène de base des fichiers de verrouillage à l'analyse comportementale avancée.

Couche 1 : application des fichiers de verrouillage

Pourquoi les fichiers de verrouillage sont importants

Un fichier de verrouillage enregistre la version exacte de chaque paquet et dépendance transitive au moment de l'installation. Sans fichier de verrouillage, npm install résout la dernière version correspondant à votre plage semver. Si votre package.json indique "axios": "^1.14.0" et qu'une version malveillante 1.14.1 existe sur le registre, vous obtenez la version malveillante.

Les règles

Toujours committer votre fichier de verrouillage. Qu'il s'agisse de package-lock.json (npm), yarn.lock (Yarn), pnpm-lock.yaml (pnpm) ou bun.lock (Bun), il doit être dans le contrôle de version.

Utilisez des installations gelées en CI/CD. Ne jamais exécuter npm install dans des environnements automatisés. Utilisez l'équivalent du fichier de verrouillage gelé :

# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile

npm ci supprime node_modules et installe strictement à partir du fichier de verrouillage. Si le fichier de verrouillage ne correspond pas à package.json, cela échoue. Cela évite les surprises de résolution.

Examinez les différences de fichier de verrouillage dans les pull requests. Lorsqu'une PR modifie package-lock.json, vérifiez ce qui a changé. Les nouvelles dépendances, les augmentations de version et les changements d'URL de registre méritent tous un examen minutieux. Des outils automatisés comme Socket.dev peuvent signaler les changements de fichier de verrouillage suspects dans les revues de PR.

La lacune des fichiers de verrouillage

Les fichiers de verrouillage protègent contre la résolution inattendue de versions, mais ils ne protègent pas contre la première installation. Si vous initialisez un projet ou ajoutez une nouvelle dépendance pendant une fenêtre d'attaque, la version malveillante est verrouillée. C'est pourquoi les fichiers de verrouillage sont la Couche 1, pas la seule couche.

Couche 2 : désactiver les scripts post-installation

Le principal vecteur d'attaque

L'attaque Axios, l'attaque ua-parser-js, l'attaque event-stream, et des dizaines d'autres ont toutes utilisé le même mécanisme : un script postinstall qui exécute du code arbitraire pendant npm install. Ce hook s'exécute avant que votre code d'application ne s'exécute, avant que vous ne révisiez le paquet, et avant que tout outil de sécurité d'exécution ne puisse intervenir.

Bloquer les scripts globalement

Ajoutez à votre .npmrc :

ignore-scripts=true

Ou définissez-le via la ligne de commande :

npm config set ignore-scripts true

Cela empêche l'exécution de tous les scripts de cycle de vie (preinstall, install, postinstall, prepare) pendant l'installation du paquet.

Gérer les paquets qui nécessitent des scripts

Certains paquets nécessitent des scripts post-installation pour la compilation native (comme bcrypt, sharp ou sqlite3). Vous avez deux options :

Option 1 : Exécuter les scripts de manière sélective après l'installation

npm ci --ignore-scripts
npm rebuild bcrypt sharp

Option 2 : Utiliser une liste blanche (npm 10+)

Créez un fichier .scriptsrc.json qui n'autorise que les paquets de confiance à exécuter des scripts :

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}

Option 3 : Utiliser des binaires précompilés

De nombreux paquets qui nécessitaient auparavant une compilation native offrent désormais des binaires précompilés. sharp, par exemple, fournit des binaires précompilés pour la plupart des plateformes, éliminant le besoin de compilation post-installation. Vérifiez vos dépendances ; vous pourriez avoir besoin de moins d'exceptions de script que vous ne le pensez.

La mise en garde PackageGate

En janvier 2026, des chercheurs ont divulgué six vulnérabilités zero-day appelées "PackageGate" affectant npm, pnpm, vlt et Bun. Une découverte : les dépendances basées sur Git peuvent contenir des fichiers de configuration qui permettent l'exécution de code même lorsque les scripts de cycle de vie sont désactivés. Si votre package.json référence des URL Git pour les dépendances, ignore-scripts seul ne suffit pas. Épinglez ces dépendances à des hachages de commit spécifiques et auditez le contenu du dépôt.

Couche 3 : épingler les versions exactes

Arrêtez d'utiliser les plages de versions sémantiques (semver)

Le comportement par défaut de npm install --save ajoute des paquets avec un préfixe accent circonflexe :

{
  "axios": "^1.14.0"
}

Le ^ signifie "compatible avec 1.14.0", ce qui résout la dernière version 1.x.x. Pendant l'attaque Axios, cela signifiait la résolution à 1.14.1.

Épinglez plutôt des versions exactes :

{
  "axios": "1.14.0"
}

Configurez npm pour enregistrer les versions exactes par défaut :

# .npmrc
save-exact=true
save-prefix=

Utiliser des remplacements pour les dépendances transitives

Vos dépendances directes ont leurs propres dépendances. Si une dépendance transitive est compromise, épingler votre dépendance directe n'aide pas. Utilisez des remplacements pour contrôler la résolution transitive :

{
  "overrides": {
    "axios": "1.14.0",
    "plain-crypto-js": "npm:empty-npm-package@1.0.0"
  }
}

Pour Yarn :

{
  "resolutions": {
    "axios": "1.14.0"
  }
}

Pour pnpm :

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}

Le compromis

L'épinglage exact signifie que vous n'obtenez pas les mises à jour automatiques des correctifs. Vous devrez augmenter manuellement les versions, ce qui crée une surcharge de maintenance. Le compromis est délibéré : vous choisissez des mises à jour contrôlées plutôt que des mises à jour automatiques. Pour les projets sensibles à la sécurité, ce compromis en vaut la peine.

Couche 4 : vérifier la provenance des paquets

Ce que la provenance signifie

L'attestation de provenance npm relie un paquet publié à son code source et à son environnement de construction à l'aide de signatures Sigstore enregistrées dans un registre de transparence public. Lorsqu'un paquet est publié à partir d'un pipeline CI/CD avec la provenance activée, le paquet inclut une preuve cryptographique de :

• Du dépôt source à partir duquel il a été construit
• Du système CI/CD qui l'a construit
• Du commit qui a déclenché la construction

Comment vérifier la provenance

npm audit signatures

Ceci vérifie que les paquets installés ont des attestations de provenance valides. Les paquets publiés manuellement depuis la machine d'un développeur n'auront pas de provenance.

Les versions malveillantes d'Axios manquaient de liaison de provenance OIDC et n'avaient pas de commits GitHub correspondants. Si la vérification automatisée de la provenance avait été une pratique courante, l'attaque aurait immédiatement soulevé des drapeaux rouges.

Activer la provenance pour vos propres paquets

Si vous publiez des paquets npm, activez la provenance dans votre CI/CD :

# Exemple GitHub Actions
- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Ajoutez à votre .npmrc :

provenance=true

Limitations

La provenance est optionnelle. La plupart des paquets npm ne l'ont pas encore. Et la provenance ne prouve que l'endroit où un paquet a été construit. Elle ne prouve pas que le code source est sûr. Un pipeline CI/CD compromis pourrait publier un paquet malveillant avec une provenance valide.

Couche 5 : utiliser des outils d'analyse comportementale

Au-delà de l'analyse des vulnérabilités

Les outils traditionnels comme npm audit et Snyk vérifient par rapport à des bases de données de vulnérabilités connues (CVEs). Ils détectent les problèmes signalés mais manquent les attaques zero-day. Le compromis Axios ne figurait dans aucune base de données CVE lors de sa publication.

Les outils d'analyse comportementale examinent ce que font les paquets, et non ce qui a été rapporté à leur sujet.

Socket.dev

Socket analyse le comportement des paquets pendant l'installation et l'exécution. Il signale :

• Les requêtes réseau pendant l'installation
• L'accès au système de fichiers en dehors du répertoire du paquet
• L'exécution de commandes shell
• La collecte de variables d'environnement
• Les modèles de code obfusqué

Lorsqu'il est intégré à GitHub, Socket commente les PRs lorsque de nouvelles dépendances présentent des comportements suspects. La dépendance plain-crypto-js de l'attaque Axios aurait déclenché de multiples alertes Socket : code obfusqué, requêtes réseau pendant le postinstall et écritures dans le système de fichiers en dehors du répertoire du paquet.

# Installer Socket CLI
npm install -g @socketsecurity/cli

# Scanner votre projet
socket scan

Snyk

Snyk fournit une gestion des vulnérabilités avec des scores de risque, des données de maturité d'exploitation et des conseils de correction. Il est plus efficace pour les vulnérabilités connues mais moins pour la détection comportementale zero-day.

# Installer Snyk CLI
npm install -g snyk

# Tester votre projet
snyk test

Approche multicouche

Utilisez les deux. Socket détecte les anomalies comportementales que Snyk manque. Snyk détecte les vulnérabilités connues avec un contexte plus riche que celui fourni par Socket. Ajoutez npm audit comme base :

# Base
npm audit

# Analyse comportementale
socket scan

# Gestion des vulnérabilités
snyk test

Exécutez les trois en CI/CD comme des portes. Toute découverte critique devrait bloquer la construction.

Couche 6 : minimiser votre surface de dépendance

La question plus profonde

Chaque paquet dans votre node_modules est une décision de confiance. L'attaque Axios a compromis un paquet avec 83 millions de téléchargements hebdomadaires. Le projet Node.js moyen a des centaines de dépendances transitives. Chacune est un vecteur d'attaque potentiel.

La défense la plus efficace est d'avoir moins de dépendances à défendre.

Auditer votre arbre de dépendances

# Comptez toutes vos dépendances
npm ls --all | wc -l

# Vérifiez les doublons
npm ls --all | sort | uniq -c | sort -rn | head -20

Posez-vous ces questions pour chaque dépendance :

• Le langage ou le runtime fournit-il cela nativement ? Node.js 18+ inclut fetch, crypto, URL, FormData, et de nombreux utilitaires qui nécessitaient auparavant des paquets.
• Cette dépendance entraîne-t-elle des dizaines de dépendances transitives ? Un seul paquet avec 50 sous-dépendances multiplie votre surface d'attaque par 50.
• Pouvez-vous l'intégrer (vendoriser) ? Pour les petits paquets utilitaires, copier la source dans votre projet élimine complètement le risque de la chaîne d'approvisionnement.

Alternatives natives pour les paquets courants

Spécifiquement pour les tests d'API

Les workflows de tests d'API dépendent généralement de bibliothèques clientes HTTP, de bibliothèques d'assertions, de runners de tests et de serveurs de maquette. Chaque dépendance est une surface d'attaque.

Apidog remplace l'ensemble de la pile par une seule plateforme :

• Client HTTP : Intégré, aucune dépendance npm nécessaire
• Assertions : Constructeur de tests visuel avec assertions intégrées
• Runner de tests : Scénarios de tests automatisés avec intégration CI/CD via Apidog CLI
• Serveur de maquette : Maquette intelligente avec réponses dynamiques, pas d'Express ou de bibliothèques de maquettes tierces
• Documentation : Générée automatiquement à partir de vos spécifications d'API

Déplacer votre workflow de tests d'API vers Apidog élimine des dizaines de dépendances npm de votre infrastructure de test. Moins de dépendances signifie moins de décisions de confiance et moins de vecteurs d'attaque.

Essayez Apidog gratuitement pour consolider votre pile de tests d'API.

Couche 7 : surveillance du réseau et de l'exécution

Bloquer les domaines malveillants connus

Après toute attaque de la chaîne d'approvisionnement, bloquez l'infrastructure de commande et de contrôle au niveau du réseau :

# Ajouter à /etc/hosts
echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts

Pour les environnements CI/CD, restreignez l'accès réseau sortant aux domaines de confiance connus. La plupart des processus de construction n'ont besoin d'accéder qu'au registre npm, à votre hôte git et à vos cibles de déploiement. Tout le reste devrait être bloqué par défaut.

Utiliser StepSecurity Harden-Runner pour le CI/CD

Harden-Runner de StepSecurity surveille les workflows GitHub Actions en temps réel. Il a détecté le dropper Axios contactant C2 dans les 1,1 secondes suivant le démarrage de npm install. L'outil fournit :

• Une surveillance du réseau sortant pour GitHub Actions
• Un suivi de l'exécution des processus
• Une surveillance de l'intégrité des fichiers
• Une alerte automatique en cas de comportement anormal

# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # ou 'block' pour le mode strict

Surveillance des processus d'exécution

Pour les machines de développement, envisagez des outils de détection et de réponse aux points d'extrémité (EDR) qui signalent les processus enfants suspects générés par Node.js. Le RAT Axios a généré osascript (macOS), cscript (Windows) et python3 (Linux) depuis le processus d'installation npm. Ces modèles de processus enfants sont détectables.

Configuration .npmrc recommandée

Voici un fichier .npmrc renforcé en sécurité combinant les couches ci-dessus :

# Épingler les versions exactes
save-exact=true
save-prefix=

# Désactiver les scripts de cycle de vie
ignore-scripts=true

# Activer la provenance pour la publication
provenance=true

# Utiliser le registre officiel
registry=https://registry.npmjs.org/

# Exiger 2FA pour la publication
auth-type=web

# Seuil de niveau d'audit
audit-level=moderate

Commitez ce fichier dans votre dépôt afin que chaque membre de l'équipe utilise les mêmes paramètres de sécurité.

Exemple de pipeline de sécurité CI/CD

Voici un workflow GitHub Actions qui applique les sept couches :

name: Secure Build
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # Couche 1+2: Fichier de verrouillage gelé, pas de scripts
      - run: npm ci --ignore-scripts

      # Couche 3: Vérifier l'absence de versions inattendues
      - run: npm ls --all > deps.txt

      # Couche 4: Vérifier la provenance
      - run: npm audit signatures

      # Couche 5: Analyse comportementale
      - run: npx socket scan

      # Couche 5: Analyse de vulnérabilité
      - run: npx snyk test

      # Couche 1: Audit de base
      - run: npm audit --audit-level=moderate

      # Reconstruire uniquement les dépendances natives autorisées
      - run: npm rebuild sharp bcrypt

Ce qui s'en vient pour la sécurité de npm

Provenance obligatoire pour les paquets populaires

npm discute de l'exigence d'attestation de provenance pour les paquets dépassant un certain seuil de téléchargements. Cela empêcherait la publication manuelle basée sur des jetons qui a permis l'attaque Axios.

Approbation de publication par deux personnes

Comme pour les transactions financières nécessitant une double autorisation, les paquets très téléchargés pourraient nécessiter l'approbation d'un second mainteneur pour les publications. Un seul compte compromis ne suffirait pas.

Définition des permissions d'exécution

Deno restreint déjà ce à quoi les scripts peuvent accéder (réseau, système de fichiers, variables d'environnement) sauf autorisation explicite. Node.js explore des modèles de permission similaires. Lorsque cela sera mis en œuvre, les scripts post-installation auraient besoin d'une permission explicite pour effectuer des requêtes réseau ou accéder au système de fichiers.

Convergence des gestionnaires de paquets

Le modèle d'isolation strict de pnpm (les paquets ne peuvent accéder qu'à leurs dépendances déclarées) prévient de nombreuses attaques par confusion de dépendances. À mesure que npm adoptera une stricte similaire, la surface d'attaque diminuera.

FAQ

Qu'est-ce qu'une attaque de la chaîne d'approvisionnement dans npm ?

Une attaque de la chaîne d'approvisionnement dans npm cible la chaîne de dépendances logicielles plutôt que votre application directement. Les attaquants compromettent les comptes des mainteneurs de paquets, injectent du code malveillant dans des paquets populaires, ou publient des paquets typosquattés avec des noms similaires. Lorsque vous installez ou mettez à jour des dépendances, le code malveillant s'exécute sur votre machine ou dans votre pipeline CI/CD, volant des identifiants, installant des portes dérobées, ou exfiltrant des données.

Est-ce que npm audit est suffisant pour se protéger contre les attaques de la chaîne d'approvisionnement ?

Non. npm audit vérifie par rapport à une base de données de vulnérabilités connues (CVEs). Les attaques zero-day comme le compromis Axios ne figurent dans aucune base de données CVE lorsqu'elles se produisent. Vous avez besoin d'outils d'analyse comportementale comme Socket.dev qui examinent ce que font les paquets, et non ce qui a été rapporté à leur sujet. Utilisez npm audit comme base, pas comme votre seule défense.

Dois-je arrêter d'utiliser npm entièrement ?

Non. npm reste le plus grand écosystème de paquets, et la plupart des paquets sont sûrs. L'objectif est de réduire votre exposition grâce à l'épinglage exact des versions, l'application des fichiers de verrouillage, le blocage des scripts et la minimisation des dépendances. Considérez si chaque dépendance est nécessaire, et utilisez des alternatives natives si possible.

Comment Apidog aide-t-il à réduire le risque d'attaque de la chaîne d'approvisionnement npm ?

Apidog fournit un client HTTP intégré, un runner de tests, un serveur de maquette et un générateur de documentation pour le développement d'API. Cela élimine le besoin de paquets npm comme Axios, node-fetch, Jest, Express (pour les maquettes), et d'autres dépendances de test. Moins de dépendances npm signifie moins de vecteurs d'attaque dans votre workflow de développement d'API.

Qu'est-ce que la provenance des paquets dans npm ?

La provenance des paquets utilise Sigstore pour lier cryptographiquement un paquet publié à son dépôt source et à son environnement de construction CI/CD. Elle prouve où et comment un paquet a été construit. Vous pouvez vérifier la provenance avec npm audit signatures. Les paquets publiés manuellement depuis les machines des développeurs n'ont pas de provenance, ce qui est un signal d'alarme pour les paquets très téléchargés.

Combien de paquets npm sont malveillants ?

Snyk a identifié plus de 3 000 paquets npm malveillants en 2024. Au quatrième trimestre 2025, Sonatype a bloqué 120 612 attaques de logiciels malveillants en un seul trimestre sur npm, PyPI et d'autres registres. Ce nombre est en augmentation. La plupart des paquets malveillants sont des typosquats peu téléchargés, mais des compromis très médiatisés comme Axios prouvent que les paquets populaires ne sont pas immunisés.

Qu'est-ce que la vulnérabilité PackageGate ?

PackageGate est un ensemble de six vulnérabilités zero-day divulguées en janvier 2026 affectant npm, pnpm, vlt et Bun. Une découverte montre que les dépendances basées sur Git peuvent contenir des fichiers de configuration permettant l'exécution de code même lorsque les scripts de cycle de vie sont désactivés. Cela signifie que ignore-scripts seul ne suffit pas si vos dépendances référencent des dépôts Git. Épinglez les dépendances Git à des hachages de commit spécifiques.

Points clés à retenir

• L'application des fichiers de verrouillage est votre fondation, mais elle ne protégera pas contre la première installation pendant une fenêtre d'attaque.
• Désactivez les scripts post-installation globalement avec ignore-scripts=true dans .npmrc.
• Épinglez les versions exactes avec save-exact=true pour éviter les surprises des plages semver.
• Vérifiez la provenance des paquets avec npm audit signatures pour détecter les téléchargements manuels.
• Superposez Socket.dev (analyse comportementale) à Snyk (vulnérabilités connues) et npm audit (base).
• Réduisez votre nombre de dépendances en utilisant les API natives de Node.js et des plateformes intégrées comme Apidog.
• Surveillez l'égression réseau CI/CD avec StepSecurity Harden-Runner.

Chaque dépendance est une décision de confiance. Moins vous avez de dépendances, plus votre surface d'attaque est petite. Plus vous appliquez de couches de vérification, plus il est difficile pour un attaquant de passer. Construisez vos défenses en profondeur, et non de manière isolée.