ChainDrop : auditer une dépendance npm sans conclure trop vite

Ce que l’alerte confirme

L’alerte officielle de la Cyber Security Agency of Singapore du 6 août 2026 décrit une campagne active ChainDrop, rattachée à la famille Shai-Hulud. Elle rapporte plus de 1 300 versions compromises et environ 2 milliards de téléchargements mensuels cumulés. Elle cite notamment keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6, cacheable-request@13.0.20 et cache-manager@7.2.10.

Ces éléments doivent rester datés. Une liste d’alerte évolue ; le nom d’un package dans un lockfile ne suffit pas à établir qu’un poste a été compromis.

Trois niveaux de preuve

Séparez trois questions :

Présence potentielle : le lockfile ou l’arbre de dépendances contient une version citée par l’alerte.
Indice local : un fichier, un script de cycle de vie, un domaine ou une modification inattendue correspond à un indicateur.
Compromission avérée : l’enquête relie l’installation à une exécution, une exfiltration ou un accès non autorisé.

Un résultat vide à une recherche locale ne prouve donc pas l’absence de compromission. Il réduit seulement un sous-ensemble d’hypothèses.

Commencer en lecture seule

Dans une copie de travail contrôlée, relevez les versions déclarées et transitives à partir du lockfile ou de l’outil de gestion déjà utilisé par le projet. Comparez ensuite les versions avec le bulletin CSA et son lien vers la liste complète. N’installez pas une dépendance et ne lancez pas npx pour vérifier une alerte.

Inspectez également les scripts de cycle de vie des paquets déjà présents, les fichiers récemment apparus dans l’environnement de dépendances et les workflows CI modifiés sans revue. Microsoft documente, dans une campagne npm distincte, le rôle d’un preinstall et d’un mécanisme destructif ; ce parallèle explique pourquoi les hooks doivent être examinés, mais ne permet pas d’attribuer chaque détail à ChainDrop.

Si une exposition est plausible

Traitez la machine et les identifiants comme potentiellement exposés. Isolez l’environnement, préservez les journaux utiles, révoquez puis régénérez les tokens concernés depuis un poste de confiance et recherchez les accès anormaux dans les dépôts, la CI et le cloud. La reconstruction doit suivre la procédure de l’organisation et partir d’artefacts vérifiés.

Ne publiez pas les secrets trouvés dans un rapport. Les IOC de l’alerte CSA doivent être utilisés avec les outils de sécurité de l’organisation, pas copiés dans une commande improvisée.

Prévention durable

Épinglez les versions, contrôlez l’intégrité et la provenance lorsque l’écosystème le permet, limitez les scripts d’installation selon la politique du projet et surveillez les changements de lockfile. La revue doit couvrir les dépendances transitives et les environnements CI, pas uniquement package.json.

Sources et limites

Sources officielles consultées le 22 septembre 2026 : CSA Singapore AD-2026-009 et Microsoft Security Blog sur une campagne npm distincte. Cet article ne conclut pas à une compromission sans preuve d’exécution ou d’accès non autorisé.