Sécurité npm : pourquoi un paquet publié et scanné n’est pas forcément sûr

Installer une dépendance avec npm install est devenu un geste banal. Pourtant, un paquet présent sur un registre officiel n’est pas automatiquement un paquet de confiance. Le retour récent du malware Shai-Hulud le rappelle de façon très concrète.

Un malware connu réapparaît sur npm

Le 7 septembre 2026, Aikido Security a signalé quatre nouvelles versions de paquets npm contenant une charge malveillante déjà observée plusieurs mois auparavant. Elle utilisait le même hash qu’un échantillon identifié le 19 mai 2026.

Après 111 jours sans nouvelle détection, Shai-Hulud est donc réapparu dans plusieurs paquets. C’est un rappel des limites d’un contrôle automatisé lorsqu’il est considéré comme une garantie absolue.

npm analyse désormais les paquets avant publication

Depuis juillet 2026, npm analyse les nouvelles publications pour rechercher des comportements malveillants. Selon le résultat, un paquet peut être publié, envoyé en vérification manuelle ou bloqué.

Cette évolution est importante, mais le retour de Shai-Hulud montre qu’une charge connue peut encore franchir une couche de détection. La sécurité du projet ne peut donc pas dépendre uniquement du registre utilisé.

Le vrai risque : la chaîne d’approvisionnement logicielle

Les dépendances directes entraînent souvent de nombreuses dépendances transitives. Lorsqu’un seul maillon est compromis, le problème peut se propager jusqu’au poste du développeur, au pipeline CI/CD ou à l’application finale.

Un attaquant peut notamment compromettre un compte de mainteneur, publier une version malveillante d’un paquet légitime, utiliser un nom ressemblant à une bibliothèque connue, exploiter une dépendance transitive ou exécuter du code pendant l’installation.

Verrouiller précisément les dépendances

Le fichier package-lock.json doit généralement être versionné. Dans les pipelines automatisés, npm ci est préférable à npm install lorsqu’un lockfile est disponible : l’installation respecte strictement les versions verrouillées et échoue si les fichiers ne sont plus cohérents.

Éviter les mises à jour aveugles

Mettre les dépendances à jour reste indispensable, notamment pour corriger les vulnérabilités. Mais automatiser leur détection ne signifie pas accepter automatiquement chaque nouvelle version.

Une chaîne raisonnable reste : détection → analyse → tests → mise en production. Dependabot et les outils SCA sont utiles pour proposer et qualifier les changements ; ils ne remplacent pas la validation du projet.

Surveiller les scripts exécutés à l’installation

npm permet aux paquets d’exécuter des scripts comme preinstall, install ou postinstall. Avant d’ajouter une dépendance peu connue ou sensible, vérifiez son package.json, son dépôt source, l’historique récent de ses versions, ses mainteneurs et les scripts exécutés.

Limiter les secrets accessibles au développement et à la CI

Une dépendance compromise devient beaucoup plus dangereuse lorsqu’elle s’exécute dans un environnement qui expose des tokens GitHub, des clés API, des identifiants cloud ou des credentials de publication.

Appliquez le principe du moindre privilège : une étape chargée uniquement de lancer des tests n’a pas besoin d’un jeton capable de publier une application ou de modifier l’infrastructure.

Sécuriser aussi ses propres publications

Pour les projets qui publient sur npm, le trusted publishing via OIDC permet de réduire l’usage de tokens longue durée dans la CI/CD. Combinez-le à l’authentification forte, à une portée minimale des permissions et à une revue des workflows de publication.

Checklist pratique

• versionner et vérifier package-lock.json ;
• utiliser npm ci dans les environnements automatisés ;
• faire passer les mises à jour par une pull request et des tests ;
• examiner les scripts d’installation des dépendances sensibles ;
• réduire les secrets et permissions disponibles dans la CI/CD ;
• surveiller les alertes de vulnérabilités et la provenance des paquets ;
• privilégier OIDC et le trusted publishing pour les publications automatisées.

Ce qu’il faut retenir

L’open source reste indispensable au développement moderne. L’objectif n’est pas d’arrêter d’utiliser des dépendances externes, mais de cesser de considérer leur installation comme une opération sans risque.

Faire confiance à une plateforme ne dispense jamais de contrôler ce que l’on intègre à son propre système.

Sources

• Aikido Security — Shai-Hulud npm resurfaces
• GitHub Changelog — npm publish-time malware scanning
• GitHub Changelog — npm trusted publishing
• npm Docs — Securing your code

Publié le 13 septembre 2026. Les mécanismes de détection et de publication npm peuvent évoluer ; vérifiez la documentation officielle avant de modifier un pipeline.