Les conséquences de Shai-Hulud 2 et ce qui aurait pu être fait différemment

Le ver npm Shai-Hulud 2.0 est l'un de ces incidents auxquels les équipes de sécurité applicative feront référence dans leurs analyses post-mortem pendant des années.

Analysons ce qui s'est passé, qui a été touché et comment une plateforme SSCS comme ScribeHub aurait pu aider les organisations à prévenir, ou du moins à limiter considérablement, le rayon de l'explosion.

1. Qu'est-ce que Shai-Hulud 2.0 ?

Shai-Hulud est apparu pour la première fois en septembre 2025 en tant que ver autoréplicatif ciblant l'écosystème npm, compromettant des centaines de packages JavaScript et se propageant via des identifiants volés et une republication automatisée. 

Quelques mois plus tard, les chercheurs ont commencé à observer un vague de suivi beaucoup plus agressive et automatisée, désormais communément appelé « Shai-Hulud 2.0 », « Sha1-Hulud 2.0 » ou « La Seconde Venue ». 

Caractéristiques principales de Shai-Hulud 2.0 :

• Priorité à la chaîne d'approvisionnement. Au lieu d'attaquer une seule entreprise, elle s'attaque à une seule. packages npm de confiance et, dans des versions ultérieures, même les écosystèmes Java (Maven), empoisonnant des éléments constitutifs utilisés dans des milliers de projets.
• Ver à reproduction autonome. Une fois qu'il compromet un mainteneur, il ouvre automatiquement des portes dérobées tous des paquets de ce mainteneur et les republie, permettant une diffusion exponentielle à travers les graphes de dépendances.
• Voleur d'informations et de secrets. La charge utile collecte de manière agressive les variables d'environnement, les jetons GitHub et npm, les identifiants cloud et les secrets CI/CD des machines des développeurs et des pipelines de construction. 
• Interrupteur de sécurité destructeur. Si le logiciel malveillant ne parvient pas à atteindre son serveur de commande et de contrôle (C2) ou s'il ne parvient pas à se propager, certaines variantes tentent d'effacer le répertoire personnel de l'utilisateur, transformant ainsi une compromission de la chaîne d'approvisionnement en un incident potentiellement destructeur.

2. Déroulement de l'attaque – Étape par étape

Les différents fournisseurs ont observé des outils et des scripts légèrement différents, mais la chaîne d'attaque globale ressemble à peu près à ceci :

2.1 Premier point d'appui : comptes de maintenance compromis

Les attaquants:

1. Comptes de mainteneurs npm/GitHub compromis utilisation de jetons volés antérieurement, hameçonnage, réutilisation de mots de passe ou authentification multifacteur faible.
2. J'ai utilisé ces comptes pour publier versions troyées de paquets légitimes – souvent avec une simple mise à jour de version au niveau du correctif, de sorte qu'elles se fondaient dans les schémas de mise à jour normaux.

Comme les paquets étaient signés/publiés par les responsables légitimes, ils paraissaient dignes de confiance aux utilisateurs finaux.

2.2 Infection via npm install / pipeline CI

Les organisations ont retiré ces colis :

• par voie normale npm installer en développement local,
• ou indirectement dans Pipelines CI / CD dans le cadre des processus de compilation automatisés.

Les paquets malveillants exploitaient généralement scripts de cycle de vie npm (préinstaller, installer, post-installation) comme vecteurs d'exécution, téléchargeant et exécutant une charge utile de deuxième étape telle que bundle.js, setup_bun.js, ou des fichiers volumineux obfusqués similaires. 

2.3 Vol d'identifiants et reconnaissance de l'environnement

Une fois en cours d'exécution, la charge utile :

• Variables d'environnement énumérées et fichiers de configuration locaux.
• Récolté identifiants cloud, jetons GitHub/GitLab, jetons d'accès npm, clés SSH et autres secrets.
• Des outils utilisés occasionnellement comme Numérisation de type TruffleHog rechercher des secrets dans les dépôts.

Ces identifiants étaient alors exfiltré vers des dépôts GitHub contrôlés par l'attaquant ou d'autres infrastructures C2, souvent nommées pour se fondre dans le décor (par exemple, les dépôts « Shai-Hulud » remplis de dumps d'environnement volés). 

2.4 Mouvements latéraux au sein des écosystèmes de développeurs

Le logiciel malveillant utilise les jetons volés :

• Tous les packages npm ont été compromis. Ces scripts, détenus par les responsables de la maintenance compromis, sont injectés et republiés par ces mêmes scripts malveillants.
• Planté Flux de travail malveillants de GitHub Actions et des portes dérobées dans les référentiels des victimes pour assurer la persistance et l'exfiltration continue pendant les exécutions CI.
• Dans certaines variantes 2.0, étendues au-delà de npm dans Dépôts Maven, démontrant ainsi une véritable portée de la chaîne d'approvisionnement inter-écosystèmes. 

Étant donné que de nombreuses bibliothèques populaires occupent une place importante dans les arbres de dépendances, un compromis de la part de quelques mainteneurs seulement se traduit par des dizaines de milliers de dépôts affectés en aval.

3. Ampleur et impact sur les victimes

Les différents fournisseurs de solutions de sécurité font état de chiffres légèrement différents, mais ils s'accordent tous sur un point : Shai-Hulud 2.0 est immense.

• Les chercheurs en sécurité estiment que plus de 25 000 dépôts GitHub et des centaines à environ 700 colis ont été touchées lors des vagues ultérieures, dont certaines apparaissent dans plus d'un quart des environnements cloud/code Ils ont scanné.
• Les analystes l'appellent ainsi L'une des attaques de la chaîne d'approvisionnement npm à propagation la plus rapide jamais observée, avec une automatisation qui a compromis Des centaines de colis en quelques heures.
• Parmi les victimes de premier plan figuraient des projets et des colis provenant de Zapier, ENS Domains, PostHog, Postman, et d'autres – ce qui signifie que les fournisseurs de solutions SaaS et des milliers de leurs clients étaient potentiellement exposés.

3.1 Impact technique direct

Pour les organisations ayant retiré un paquet infecté par un cheval de Troie, les conséquences typiques étaient les suivantes :

• Révélation des secrets de l'intégration continue/déploiement continu (CI/CD) (clés de fournisseur de cloud, jetons de déploiement, certificats de signature de code, etc.).
• Portes dérobées furtives dans les dépôts GitHub et les actions CI, permettant aux attaquants d'exécuter des commandes arbitraires dans les futures versions.
• artefacts altérés: le risque que des attaquants insèrent une logique malveillante dans des applications existantes sans que les développeurs ne s'en aperçoivent.
• Pour certains développeurs malchanceux, un effacement destructeur de la $ ACCUEIL annuaire lorsque le mécanisme de repli du logiciel malveillant s'est déclenché.

3.2 Impact sur l'activité

D'un point de vue commercial, cela se traduit par :

• Interventions en cas d'incident à grande échelleLes équipes de réponse aux incidents ont dû auditer chaque projet utilisant les packages concernés, faire tourner les jetons et parfois geler les déploiements.
• Exposition réglementaire et contractuelleLes secteurs réglementés (finance, santé, fournisseurs du gouvernement) sont désormais confrontés à la possibilité que des données réglementées ou des clés d'accès critiques à leurs systèmes aient été exfiltrées via un logiciel tiers.
• Érosion de la confiance dans les sources ouvertesLes responsables de la sécurité et de l'ingénierie sont contraints de revoir leur modèle de confiance pour les registres publics et d'envisager des contrôles plus stricts en matière de gestion des dépendances.

4. Là où les défenses traditionnelles peinent

Pourquoi Shai-Hulud 2.0 a-t-il réussi à percer autant de défenses ?

1. Il s'agissait d'un abus de confiance, et non d'une simple vulnérabilité. Les paquets étaient « légitimes » – publiés sous de vrais noms de responsables, souvent à partir de dépôts existants.
2. L'analyse statique SCA/SAST n'était pas suffisante. Même si les équipes disposaient de SBOM et d'analyseurs de vulnérabilités, beaucoup d'entre elles ne recherchaient pas comportementale Des indicateurs tels que des scripts de cycle de vie suspects ou une exfiltration sortante lors des compilations.
3. Les secrets et l'intégration continue/déploiement continu (CI/CD) étaient la véritable cible. De nombreuses organisations disposent de contrôles et d'une surveillance moins efficaces pour leurs environnements CI/CD que pour leurs environnements de production, ce qui en fait des cibles idéales.
4. Absence de traçabilité de bout en bout. La plupart des équipes n'ont pas pu répondre facilement : « Quelles versions, quels artefacts et quels déploiements précis impliquaient un package infecté par un cheval de Troie, et lesquels sont sains ? »

C'est précisément cet écart qui sécurité de la chaîne d'approvisionnement logicielle (SSCS) des plates-formes comme ScribeHub sont conçus pour répondre.

 

5. Comment ScribeHub SSCS pourrait contribuer à prévenir et à atténuer les attaques de type Shai-Hulud

Je vais faire correspondre les techniques de Shai-Hulud 2.0 aux fonctionnalités que vous mettriez généralement en œuvre avec la plateforme ScribeHub de Scribe Security et les outils associés (par exemple, la politique en tant que code Valint).

5.1 Garde-fous pour l'ingestion des dépendances

Problème dans Shai-Hulud 2.0 :
Les organisations ont automatiquement consommé les packages npm mis à jour (via ^/~ (plages de versions, Renovate/Dependabot ou scripts CI) avec peu d'analyse comportementale.

Avec ScribeHub :

• Contrôles de dépendance axés sur les politiques. Utilisez les politiques Valint pour restreindre les registres et les étendues considérés comme « de confiance », appliquer des listes blanches pour les paquets critiques et recevoir des alertes lorsque :
  • un nouveau responsable de la maintenance publie une version,
  • Des scripts de cycle de vie inattendus apparaissent.
  • ou qu'un paquet acquière soudainement un nouveau comportement réseau/d'exécution.
• Attestation relative aux composants tiers. ScribeHub peut ingérer et vérifier attestations de provenance et de construction pour les paquets disponibles (par exemple, métadonnées de type SLSA, Sigstore, in-toto), activer des règles comme « N’utiliser que les dépendances dont nous faisons confiance à la provenance de la construction. »

Cela ne résout pas comme par magie le problème de l'écosystème npm, mais cela l'améliore considérablement. place la barre plus haut avant qu'une nouvelle version ne soit autorisée dans vos builds.

5.2 Renforcer le pipeline CI/CD en tant qu’« atout de premier ordre »

La principale valeur de Shai-Hulud résidait dans l'exploitation Ordinateurs portables de développeurs et nœuds CI/CD comme coffres-forts secrets.

Utilisation de ScribeHub :

• Attestation de pipeline pour chaque exécution.
  Chaque tâche CI produit une attestation signée décrivant :
  • quels dépôts et branches ont été construits,
  • quelles dépendances et images de conteneurs ont été utilisées,
  • quels scripts ont été exécutés (y compris les hooks de cycle de vie),
  • et quels secrets ont été consultés.
• Ces données atterrissent dans Le lac de preuves de ScribeHub, vous offrant un historique infalsifiable de « qui a construit quoi, à partir de où et avec quelles ressources ».
• Contrôles d'exécution des politiques en tant que code.
  Avant qu'un artefact de build puisse être promu en préproduction/production, un moteur de règles effectue une validation :
  • que seuls les registres npm approuvés ont été utilisés,
  • qu'aucun script de cycle de vie interdit (boucle | bash, obscurci bundle.js, etc.) sont exécutés,
  • que le programme d'exécution ne s'exécutait pas en tant que root et ne montait pas les chemins d'accès hôtes sensibles.

Si Shai-Hulud injecte un supplément post-installation script qui exfiltre des secrets, ces exécutions échouer la politique et n'atteignent jamais la production.

5.3 Analyse rapide du rayon d'explosion

L'une des tâches les plus difficiles dans une campagne comme celle-ci est de répondre :

« Où exactement avons-nous utilisé des versions troyennées du package X, et qu'ont-elles touché ? »

Avec ScribeHub :

• Chaque build, déploiement et artefact est associé à attestations liées cryptographiquement: dépendances, détails de l'environnement, SHA des commits, condensés des conteneurs, etc.
• Lorsqu'un nouvel avis indique « versions 4.8.1–4.8.5 de une bibliothèque « font partie de Shai-Hulud 2.0 », demandez-vous à ScribeHub :
  
  
  « Montrez-moi toutes les versions compilées au cours des 90 derniers jours qui incluaient ces versions, ainsi que les déploiements ou images qu'elles ont produits. »
  
• Vous pouvez ensuite rotation secrète cible et une remédiation précise là où elle est nécessaire plutôt que de tout faire tourner à l'aveuglette (ce qui peut s'avérer irréaliste sur le plan opérationnel).

En d'autres termes, ScribeHub transforme une panique à l'échelle de l'écosystème en une incident circonscrit et auditable.

5.4 Protéger votre propre des colis destinés à être militarisés

De nombreuses organisations ne se contentent pas d'utiliser des logiciels libres ; elles… publier Ces paquets sont utilisés par les clients, les partenaires ou les équipes internes. Si un compte de maintenance au sein de votre organisation était compromis, vous pourriez devenir malgré vous un vecteur de propagation, à l'instar des responsables de la maintenance de Shai-Hulud.

ScribeHub peut vous aider en :

• Exiger des attestations signées de votre CI avant qu'un paquet puisse être publié sur npm ou sur un registre interne :
  • Les versions de paquets qui ne sont pas accompagnées des attestations attendues sont rejetées ou signalées.
• Surveillance continue de vos propres registres et dépôts :
  • Alertes lorsqu'un package est publié à partir d'un environnement de construction inconnu ou en dehors de vos pipelines CI approuvés.
  • Détection de nouvelles actions GitHub ou de nouveaux scripts npm qui n'étaient pas présents dans la dernière version « fiable ».

Cela le rend beaucoup plus difficile pour un attaquant avec un jeton volé glisser discrètement une version malveillante dans votre espace de noms.

5.5 Preuves à l'intention des organismes de réglementation, des clients et des parties prenantes internes

Les incidents comme Shai-Hulud 2.0 font l'objet d'un examen de plus en plus minutieux de la part des organismes de réglementation et des grands clients, notamment dans les secteurs alignés sur des cadres tels que NIST SSDF, PCI DSS 4ou les exigences d'attestation des logiciels gouvernementaux.

Parce que ScribeHub conserve un Enregistrement horodaté et signé de l'activité SDLC, vous pourrez :

• Démontrer quelles versions et quels déploiements n'ont pas été affectés par les dépendances infectées par un cheval de Troie.
• Fournir aux auditeurs des preuves concrètes de :
  • politiques de dépendance,
  • application du principe du moindre privilège dans les CI,
  • et les calendriers de rotation secrète après l'incident.

Cela transforme la conversation, passant de « nous pensons que tout va bien » à « voici la chaîne de traçabilité attestée de notre logiciel ».

6. Leçons pratiques à retenir pour les responsables de la sécurité

En résumé, voici comment je décrirais Shai-Hulud 2.0 et le rôle que peut jouer une plateforme comme ScribeHub :

1. Supposons que l'écosystème soit compromis. Les registres publics présentent un risque de défaillance trop important. Votre modèle de sécurité doit considérer les dépendances externes comme non fiables jusqu'à preuve du contraire.
2. Passez du « scanner et prier » à « attester et faire appliquer ». Les méthodes classiques de SCA et de peluchage restent importantes, mais Shai-Hulud 2.0 montre que nous avons également besoin de :
   • provenance solide,
   • constructions attestées,
   • et la promotion des artefacts encadrée par des politiques spécifiques.
3. Traitez l'intégration continue/déploiement continu (CI/CD) comme la production. Le ver s'attaquait aux secrets et aux pipelines car ce sont souvent des cibles plus faciles que les environnements d'exécution renforcés.
4. Investissez dans la traçabilité. Lorsque la prochaine crise touchant l'ensemble de l'écosystème surviendra – et elle surviendra –, votre capacité à répondre en quelques heures plutôt qu'en quelques semaines à la question « Où cela nous a-t-il affectés ? » fera la différence entre un incident maîtrisé et une crise de grande ampleur.

ScribeHub SSCS ne rend pas npm ou les logiciels libres magiquement sûrs, mais il vous offre la visibilité, le contrôle et la base de preuves nécessaires pour résister aux attaques de type Shai-Hulud avec beaucoup moins de chaos.

Si vous structurez votre cycle de vie de développement logiciel (SDLC) autour d'attestations signées continues, de politiques fondées sur des preuves et d'une hygiène CI/CD rigoureuse, la prochaine « plus grande attaque de la chaîne d'approvisionnement npm de l'histoire » deviendra un incident de plus à gérer, et non une menace existentielle pour votre entreprise.