Bonnes pratiques de sécurité npm

Mar 28, 2026 · 4 min read

L’écosystème npm est le plus grand registre de paquets au monde, et cette échelle en fait une cible de grande valeur. Des attaques comme Shai-Hulud, event-stream et eslint-scope ont toutes démontré la même vérité inconfortable : installer un paquet peut exécuter du code arbitraire sur votre machine avant même que vous n’ayez lu une seule ligne de son code source. Ces bonnes pratiques de sécurité npm vous aident à réduire ce risque à chaque étape — installation, développement et publication.

Points clés à retenir

Désactivez les scripts post-installation globalement et n’autorisez que les paquets qui en ont réellement besoin.
Définissez un délai d’attente pour les nouvelles versions afin que les versions toutes récentes (et potentiellement malveillantes) n’atteignent jamais vos builds automatiquement.
Commitez toujours votre fichier de verrouillage et utilisez npm ci dans les pipelines CI pour des installations reproductibles et résistantes aux altérations.
Protégez les comptes des mainteneurs avec une 2FA basée sur WebAuthn et publiez via la publication de confiance OIDC pour éliminer les jetons à longue durée de vie.

Pourquoi la sécurité de la chaîne d’approvisionnement npm est importante maintenant

Les attaques de la chaîne d’approvisionnement n’exploitent pas votre code. Elles exploitent votre confiance dans celui de quelqu’un d’autre. Lorsqu’un paquet compromis atterrit dans votre node_modules, il peut voler des identifiants, exfiltrer des variables d’environnement ou se propager davantage. Le ver Shai-Hulud à lui seul a déclenché la suppression de plus de 500 paquets du registre en un seul incident. L’analyse de vulnérabilités seule ne détectera pas cette classe d’attaque — vous avez besoin d’une défense en profondeur.

Gestion sécurisée des dépendances : renforcez vos installations

Désactiver les scripts post-installation

Les scripts post-installation sont le vecteur d’attaque le plus courant dans les attaques de la chaîne d’approvisionnement npm. Désactivez-les globalement :

npm config set ignore-scripts true
npm config set allow-git none   # npm CLI 11.10.0+

Le paramètre allow-git=none est important car une dépendance basée sur git peut fournir son propre .npmrc qui réactive silencieusement les scripts de cycle de vie, contournant complètement ignore-scripts.

Si vous utilisez pnpm, la version 10+ désactive les scripts post-installation par défaut. Utilisez pnpm-workspace.yaml pour autoriser explicitement les paquets qui en ont légitimement besoin :

allowBuilds:
  esbuild: true
  core-js: false

Activez strictDepBuilds: true pour transformer tout script de build non vérifié en échec bloquant de CI plutôt qu’en avertissement silencieux. Bun bloque également les scripts post-installation par défaut, avec une activation via trustedDependencies dans package.json.

Lorsque vous avez réellement besoin de scripts de cycle de vie, utilisez @lavamoat/allow-scripts pour créer une liste d’autorisation auditable plutôt que d’activer les scripts globalement.

Ajouter un délai d’attente pour les nouvelles versions

Les paquets malveillants sont souvent découverts et dépubliés en quelques heures ou jours. Ignorer les versions toutes récentes donne à la communauté le temps de détecter les problèmes avant qu’ils ne vous atteignent :

npm config set min-release-age 3

Cela indique à npm d’ignorer toute version de paquet publiée il y a moins de trois jours. Pour les mises à jour automatisées de dépendances, des outils comme Renovate et Dependabot prennent en charge des paramètres minimumReleaseAge équivalents.

Commiter votre fichier de verrouillage et utiliser `npm ci`

Commitez toujours package-lock.json. Dans les environnements CI, remplacez npm install par :

npm ci

npm ci installe exclusivement à partir du fichier de verrouillage, échoue en cas de non-concordance et ne résout jamais silencieusement une version différente. C’est le fondement de builds reproductibles et sécurisés dans les pipelines automatisés.

Ne pas mettre à jour aveuglément

npm audit et npm outdated sont des signaux utiles, mais traitez-les comme une entrée parmi d’autres, pas comme une solution complète. Avant de mettre à jour une dépendance, consultez le changelog. Évitez les mises à jour en masse qui sautent cette étape — chaque changement de version est un changement potentiel de surface d’attaque.

Workflows npm sécurisés pour les mainteneurs de paquets

Activer la 2FA — et passer à WebAuthn

Les prises de contrôle de comptes sont le mécanisme principal derrière les attaques de la chaîne d’approvisionnement sur le registre. Activez la 2FA sur votre compte npm avec une protection en mode écriture :

npm profile enable-2fa auth-and-writes

GitHub encourage de plus en plus les passkeys et l’authentification basée sur WebAuthn, qui sont nettement plus résistantes au phishing que la 2FA traditionnelle basée sur TOTP. Une clé matérielle ou une passkey est beaucoup plus difficile à usurper qu’un code TOTP, donc passer à cette méthode le plus tôt possible est judicieux.

Publier avec la publication de confiance (OIDC)

Les jetons npm à longue durée de vie sont un handicap. La publication de confiance via OIDC permet à GitHub Actions ou GitLab CI de s’authentifier directement auprès de npm en utilisant des identifiants à courte durée de vie et limités au workflow — aucun jeton stocké n’est requis. Cela génère également automatiquement des attestations de provenance, donnant aux consommateurs une preuve cryptographique de l’endroit et de la manière dont un paquet a été construit.

C’est la direction que prend l’écosystème. GitHub a signalé son intention de supprimer progressivement les jetons hérités et de faire de la publication de confiance le chemin par défaut pour l’automatisation.

Vérifier ce que vous installez

Ne supposez pas que le registre officiel est sûr. Utilisez Socket ou npq pour examiner les paquets à la recherche de comportements suspects avant l’installation. Vérifiez le nombre de téléchargements, l’activité du dépôt et l’historique des mainteneurs — en particulier pour les paquets suggérés par les assistants de codage IA, qui peuvent halluciner des noms de paquets que les attaquants enregistrent ensuite (une technique appelée slopsquatting).

Conclusion

Aucun outil unique ne prévient toutes les attaques de la chaîne d’approvisionnement npm. Les pratiques qui comptent le plus sont superposées : désactiver les scripts de cycle de vie, imposer les fichiers de verrouillage, ajouter un délai d’attente sur les nouvelles versions, utiliser npm ci en CI et migrer la publication vers OIDC avec 2FA. Chaque couche réduit indépendamment le risque. Ensemble, elles rendent votre workflow significativement plus difficile à compromettre.

FAQ

Oui, certains paquets comme esbuild ou sharp nécessitent des scripts post-installation pour télécharger des binaires spécifiques à la plateforme. Plutôt que de réactiver les scripts globalement, utilisez une approche par liste d'autorisation avec la configuration allowBuilds de pnpm ou allow-scripts de LavaMoat pour accorder la permission uniquement à des paquets spécifiques et de confiance qui ont réellement besoin d'étapes de build.

Non. npm audit vérifie les vulnérabilités connues dans les avis publiés, mais il ne peut pas détecter les nouvelles attaques de la chaîne d'approvisionnement comme le typosquatting, les prises de contrôle de comptes ou le code malveillant injecté dans des paquets par ailleurs légitimes. Traitez audit comme un signal utile au sein d'une stratégie de défense en profondeur plus large qui inclut l'application des fichiers de verrouillage, les restrictions de scripts et les outils de filtrage pré-installation.

npm install lit package.json, résout les plages de dépendances et peut modifier le fichier de verrouillage. npm ci lit uniquement à partir de package-lock.json, installe les versions exactes et échoue immédiatement si le fichier de verrouillage est manquant ou incohérent avec package.json. Utilisez toujours npm ci dans les pipelines d'intégration continue pour garantir des builds reproductibles et résistants aux altérations.

Les jetons npm traditionnels sont des secrets à longue durée de vie stockés dans les environnements CI, ce qui en fait des cibles de vol attractives. La publication de confiance OIDC génère des identifiants à courte durée de vie, limités au workflow et liés à un dépôt et une exécution d'action spécifiques. Aucun secret n'est stocké nulle part, et chaque opération de publication est cryptographiquement liée à sa source, produisant automatiquement des attestations de provenance vérifiables.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.