Shai-hulud : quand une dépendance npm expose les secrets d’une équipe

Une dépendance peut devenir un accès privilégié

Le 6 août 2026, la Cyber Security Agency of Singapore a publié un avis sur une campagne active visant l’écosystème npm. Le malware Shai-Hulud, dans la variante décrite comme « ChainDrop », s’appuie sur des versions malveillantes de paquets pour voler des identifiants de développeurs et se propager vers d’autres paquets.

L’alerte cite notamment des versions compromises de keyv, flat-cache, file-entry-cache, cacheable et de paquets associés. Le problème ne se limite pas au code livré à l’application : un paquet peut aussi exécuter des scripts d’installation dans le contexte du poste de développement ou du runner CI qui le télécharge.

Ce que l’attaquant cherche réellement

Le nom du malware attire l’attention, mais le risque opérationnel est plus simple à comprendre : une dépendance compromise observe l’environnement auquel elle a accès.

Cela peut inclure :

• des tokens GitHub ou GitLab présents dans les variables d’environnement ;
• des clés API conservées dans un fichier local ou un terminal ;
• des identifiants cloud, SSH, Terraform ou Kubernetes ;
• des secrets CI/CD réutilisables depuis un runner trop permissif ;
• des fichiers de configuration ou des sessions déjà ouvertes.

Un secret oublié dans un .env, un script shell ou une variable de pipeline n’est donc pas « seulement local ». Dès qu’un outil tiers s’exécute avec les mêmes droits, il peut devenir un pont vers l’organisation.

La réponse immédiate pour une petite équipe

Si une version potentiellement touchée a été installée, la priorité est de traiter la machine et le pipeline comme suspects. La CSA recommande d’identifier et supprimer les versions concernées, de reconstruire les systèmes affectés, de faire tourner les identifiants exposés et de rechercher les accès ou changements inhabituels.

Une séquence praticable tient en cinq temps :

1. Stopper la propagation. Mettez en pause les déploiements et installations automatisées liés au projet concerné.
2. Vérifier l’inventaire. Cherchez les paquets et versions dans les lockfiles, caches, postes de développement, runners et artefacts.
3. Isoler puis reconstruire. Ne réutilisez pas un runner ou un poste potentiellement contaminé comme base de confiance ; repartez d’une image saine.
4. Révoquer et remplacer. Faites tourner les tokens, clés API, clés SSH et secrets cloud accessibles depuis les environnements concernés. Un nouveau secret ne suffit pas si l’ancien reste valide.
5. Contrôler les traces. Examinez les connexions, publications de paquets, modifications de workflows et changements de permissions depuis la première installation suspecte.

La rotation doit être hiérarchisée : commencez par les comptes d’administration, les clés permettant de publier du code et les identifiants donnant accès aux données ou à la production. Documentez qui a tourné quoi, quand et où le nouveau secret est stocké.

Trois catégories de secrets à ne pas mélanger

Un coffre de mots de passe sert surtout aux secrets humains : comptes SaaS, accès partagés, codes de récupération ou informations d’administration. Il doit offrir des secrets uniques, un partage contrôlé et une récupération maîtrisée.

Les secrets machine — tokens d’API, clés SSH, credentials cloud — doivent être limités dans le temps, dans leur périmètre et dans leur usage. Ils ne devraient pas être copiés dans un document partagé simplement parce qu’une équipe n’a pas encore formalisé son processus.

Enfin, les secrets CI/CD doivent être injectés par les mécanismes prévus par la plateforme. Préférez des identités dédiées, courtes et peu privilégiées ; isolez les runners et auditez les workflows sensibles. Soclyde ne remplace pas un secret manager CI/CD : son rôle est de réduire les copies et les partages risqués autour des secrets humains, avec un coffre chiffré local-first.

Réduire la surface d’attaque avant le prochain incident

Les recommandations de Google Threat Intelligence prolongent la réponse d’urgence par quelques garde-fous réalistes : attendre avant d’adopter une version nouvellement publiée, vérifier l’intégrité et la provenance des artefacts, désactiver les scripts d’installation par défaut quand c’est compatible avec le projet, et n’autoriser que les dépendances nécessaires.

Pour une petite équipe, cela peut devenir une checklist mensuelle :

• conserver et relire les lockfiles dans les changements de dépendances ;
• utiliser npm ci ou l’équivalent reproductible en CI ;
• appliquer une période de refroidissement aux versions fraîchement publiées ;
• exécuter les installations dans un runner éphémère et restreint en sortie réseau ;
• inventorier les tokens, leur propriétaire, leur portée et leur date d’expiration ;
• protéger les branches et examiner les workflows qui disposent de secrets ;
• stocker les mots de passe humains dans un coffre chiffré et éviter les copies dans les tickets, tableurs ou messages.

Le but n’est pas de rendre l’équipe méfiante de chaque paquet. Il est de faire en sorte qu’un paquet compromis ne trouve ni un token permanent, ni un runner réutilisable, ni une collection de secrets copiés partout.

Pour revoir l’architecture et les limites d’un coffre local-first, consultez le guide Soclyde sur les gestionnaires de mots de passe local-first.