Pendant longtemps, la sécurité d’une application était principalement pensée autour de son propre code.
Aujourd’hui, ce n’est plus suffisant.
Une application moderne peut dépendre de dizaines, centaines, voire milliers de composants externes : bibliothèques npm, packages Python, images Docker, actions GitHub, outils CI/CD, SDK cloud…
Et il suffit parfois qu’un seul élément de cette chaîne soit compromis pour qu’un attaquant entre indirectement dans votre environnement.
Les campagnes Shai-Hulud en sont une illustration particulièrement importante.
Identifié initialement en 2025, Shai-Hulud est désormais référencé par MITRE comme un ver de supply chain capable de se propager via des dépôts de code et des packages npm, tout en cherchant à voler des identifiants et des jetons d’accès.
Et en 2026, le problème ne s’est pas arrêté.
De nouvelles variantes et campagnes ont continué à apparaître, avec notamment Mini Shai-Hulud, puis plus récemment une variante baptisée ChainDrop qui a de nouveau touché massivement l’écosystème npm début août 2026.
Alors, comment une simple dépendance JavaScript peut-elle devenir un problème de cybersécurité à l’échelle d’une entreprise ?
Qu’est-ce qu’une attaque de supply chain logicielle ?
Pour comprendre Shai-Hulud, il faut d’abord comprendre la notion de software supply chain, ou chaîne d’approvisionnement logicielle.
Lorsque vous développez une application, vous n’écrivez presque jamais 100 % du code vous-même.
Vous utilisez par exemple :
- un framework ;
- des bibliothèques ;
- des packages open source ;
- des SDK ;
- des outils de compilation ;
- des pipelines CI/CD ;
- des images Docker ;
- des services cloud.
C’est parfaitement normal.
Le problème apparaît lorsque l’un de ces composants est compromis.
Au lieu d’attaquer directement votre entreprise, l’attaquant peut chercher à compromettre un fournisseur, un mainteneur ou un outil auquel vous faites déjà confiance.
Le code malveillant peut alors arriver chez vous à travers une mise à jour apparemment légitime.
C’est ce qui rend ces attaques particulièrement dangereuses :
la menace emprunte un chemin que votre système considère déjà comme fiable.
npm : un écosystème extrêmement puissant… mais très interconnecté
npm est l’un des gestionnaires de packages les plus utilisés dans l’écosystème JavaScript et Node.js.
Installer une dépendance est extrêmement simple :
npm install
Mais derrière cette simplicité se cache parfois une immense arborescence de dépendances.
Vous installez une bibliothèque.
Cette bibliothèque dépend d’une autre.
Qui dépend elle-même de trois autres packages.
Et ainsi de suite.
Votre application peut donc utiliser indirectement du code provenant de projets que vous n’avez jamais choisis explicitement.
C’est ce qu’on appelle les dépendances transitives.
Et c’est précisément ce qui rend une attaque de supply chain capable d’avoir un rayon d’impact très important.
Que fait Shai-Hulud ?
Shai-Hulud n’est pas simplement un package malveillant isolé.
MITRE le décrit comme un ver de supply chain capable de compromettre des comptes et des dépôts, de voler des jetons d’accès et d’utiliser ces accès pour continuer sa propagation.
Le principe général est particulièrement dangereux.
Une machine de développeur ou un environnement CI/CD installe une dépendance compromise.
Le code malveillant cherche alors des secrets accessibles dans cet environnement.
Cela peut concerner notamment :
des jetons GitHub, des accès npm, des identifiants cloud, des secrets CI/CD, des clés SSH ou encore certains secrets Kubernetes. Les différentes vagues Shai-Hulud observées en 2026 ont précisément ciblé ce type d’informations.
Si un jeton volé permet de publier un autre package, de modifier un dépôt ou d’utiliser un pipeline de publication, l’attaque peut alors continuer à se propager.
On obtient donc potentiellement :
Package compromis → machine ou CI/CD → secrets volés → compte compromis → nouveau package compromis → nouveaux utilisateurs exposés
C’est cet effet en chaîne qui transforme une compromission technique en véritable attaque de supply chain.
Pourquoi les pipelines CI/CD sont-ils particulièrement sensibles ?
Les pipelines CI/CD représentent une cible extrêmement intéressante.
Pourquoi ?
Parce qu’ils disposent justement des autorisations nécessaires pour automatiser le développement.
Un pipeline peut par exemple :
compiler → tester → créer une image → accéder à un registre → publier un package → déployer dans le cloud.
Pour fonctionner, il doit donc souvent disposer de secrets.
Un développeur n’a normalement pas besoin d’écrire directement ces secrets dans son code.
Ils sont généralement stockés dans GitHub Actions, GitLab CI, Jenkins, Azure DevOps ou une autre plateforme.
C’est une bonne pratique.
Mais cela ne signifie pas que le secret est automatiquement protégé contre tout code exécuté dans le pipeline.
Si une dépendance compromise parvient à exécuter du code pendant une installation ou une compilation, la question devient :
À quoi ce processus a-t-il accès ?
Les campagnes Mini Shai-Hulud observées au printemps 2026 ont justement visé les environnements de build et les runners CI/CD afin d’y récupérer des informations sensibles.
Même une chaîne de publication moderne peut être attaquée
Il serait tentant de penser :
« Nous utilisons GitHub Actions, OIDC et des mécanismes de provenance, donc nous sommes protégés. »
Malheureusement, ce n’est pas toujours suffisant.
En mai 2026, une vague Mini Shai-Hulud liée notamment à TanStack a compromis des mécanismes de publication en s’attaquant directement au workflow de build.
Akamai a documenté une attaque exploitant le pipeline CI et le mécanisme de publication OIDC de npm.
Cela illustre une distinction fondamentale.
Une signature ou une attestation de provenance peut permettre de vérifier :
« Ce package a bien été produit par le pipeline attendu. »
Mais si le pipeline lui-même est compromis, cela ne garantit pas nécessairement :
« Le code produit par ce pipeline est sûr. »
Autrement dit :
La confiance dans la chaîne ne vaut que si chaque maillon est maîtrisé.
Une menace qui a continué à évoluer en 2026
Les campagnes Shai-Hulud ne se résument pas à un incident unique.
Au printemps 2026, différentes vagues ont touché plusieurs écosystèmes et projets.
Le NHS britannique a par exemple publié en mai une alerte concernant Mini Shai-Hulud, citant notamment des packages liés à TanStack, Mistral AI, UiPath et OpenSearch.
Quelques jours plus tard, une nouvelle vague touchait plus de 300 packages de l’écosystème @antv.
En juin, des packages officiels @redhat-cloud-services ont également été compromis, avec 96 versions réparties sur 32 packages détectées par Aikido.
Puis, début août 2026, une nouvelle variante baptisée ChainDrop a encore étendu le phénomène.
Selon les informations rapportées à partir des recherches d’Aikido, plus de 1 300 versions de packages npm ont été compromises dans cette campagne, avec des bibliothèques très utilisées telles que Keyv et Cacheable dans la chaîne d’impact.
Le problème doit donc être considéré comme une famille de techniques et de campagnes évolutives, plutôt qu’une menace que l’on pourrait simplement déclarer terminée.
Une dépendance populaire n’est pas automatiquement une dépendance sûre
Une erreur fréquente consiste à associer popularité et sécurité.
Un développeur peut se dire :
« Ce package est téléchargé des millions de fois, donc il doit être fiable. »
Ce raisonnement est compréhensible, mais insuffisant.
Un package peut être parfaitement légitime pendant plusieurs années, puis être compromis parce que :
- le compte d’un mainteneur est piraté ;
- un jeton de publication est volé ;
- un workflow CI/CD est modifié ;
- un poste développeur est compromis ;
- une dépendance indirecte est contaminée.
Le risque ne vient donc pas forcément du fait d’avoir choisi un projet douteux.
Il peut provenir de la compromission ultérieure d’un projet parfaitement légitime.
Comment réduire le risque ?
Il n’existe pas de bouton permettant de supprimer totalement le risque lié à la supply chain.
L’objectif est donc d’appliquer plusieurs couches de protection.
1. Maîtriser les versions réellement installées
Les fichiers de verrouillage comme :
package-lock.json
pnpm-lock.yaml
ou
yarn.lock
permettent de conserver une vision déterministe des versions installées.
Il est généralement préférable qu’une nouvelle version de dépendance ne se retrouve pas en production simplement parce qu’elle vient d’être publiée quelques minutes auparavant.
Les mises à jour doivent faire partie d’un processus contrôlé.
2. Scanner les dépendances
Les outils SCA — Software Composition Analysis — peuvent analyser les dépendances utilisées par une application.
Ils permettent notamment de détecter :
- des vulnérabilités connues ;
- des packages problématiques ;
- certaines dépendances malveillantes ;
- des versions obsolètes ;
- des risques liés à la licence ou à la maintenance.
Mais aucun scanner n’est parfait.
Une attaque toute récente peut exécuter son code avant même que les outils de sécurité aient identifié le package.
Aikido soulignait précisément ce problème lors des vagues Mini Shai-Hulud : dans certains cas, le payload s’exécutait au moment de l’installation, avant que la détection généralisée ne soit disponible.
Le scanner doit donc être considéré comme une couche de sécurité, pas comme l’unique protection.
3. Réduire les privilèges des environnements CI/CD
Un pipeline CI n’a pas besoin d’avoir accès à tous les secrets de l’entreprise.
C’est ici que le principe du moindre privilège devient essentiel.
Un pipeline destiné uniquement à exécuter des tests ne devrait pas disposer automatiquement :
des droits de production, des clés cloud administrateur et des secrets de déploiement.
Plus les permissions sont limitées, plus l’impact d’une dépendance compromise peut être contenu.
On retrouve ici une règle classique de cybersécurité :
Un secret inaccessible ne peut pas être volé par ce processus.
4. Séparer les différentes étapes
Il peut également être pertinent de séparer :
Build → Tests → Publication → Déploiement
plutôt que d’exécuter toutes ces étapes dans un environnement disposant simultanément de tous les accès.
Un environnement de build compromis ne devrait idéalement pas pouvoir immédiatement devenir administrateur de l’infrastructure de production.
Cette segmentation réduit le blast radius, c’est-à-dire l’ampleur potentielle d’une compromission.
5. Utiliser des identifiants temporaires lorsque c’est possible
Les secrets permanents constituent une cible particulièrement intéressante.
Une clé cloud valable pendant plusieurs années peut rester exploitable longtemps après son vol.
Les mécanismes modernes permettant d’utiliser des identifiants temporaires, des rôles ou de l’OIDC réduisent cette fenêtre d’exploitation.
Mais, comme l’ont montré certaines campagnes 2026, cela ne supprime pas la nécessité de sécuriser le pipeline lui-même.
Il faut donc combiner :
identifiants courts + moindre privilège + pipeline sécurisé + surveillance.
6. Protéger les comptes des mainteneurs et développeurs
Les comptes GitHub, npm ou autres outils de développement doivent être traités comme des comptes sensibles.
Cela implique notamment :
MFA, gestion rigoureuse des sessions, limitation des jetons, rotation des secrets et suppression des accès devenus inutiles.
L’importance de ces protections a encore été illustrée en mai 2026 lorsque npm a invalidé des jetons granulaires disposant de droits d’écriture et pouvant contourner la 2FA, dans le contexte des campagnes Mini Shai-Hulud.
7. Savoir exactement quelles dépendances sont utilisées
Il est difficile de protéger une supply chain si personne ne sait réellement ce qu’elle contient.
C’est ici qu’un SBOM — Software Bill of Materials — peut être utile.
On peut le comparer à la liste des ingrédients d’un logiciel.
Il permet de conserver une vision structurée des composants intégrés dans une application.
Lorsqu’une vulnérabilité ou une compromission importante apparaît, la question n’est alors plus :
« Est-ce qu’on utilise peut-être cette librairie quelque part ? »
mais :
« Quels produits, quelles versions et quels environnements utilisent cette dépendance ? »
Cette capacité à répondre rapidement peut faire une énorme différence lors d’un incident.
Que faire si une dépendance compromise a déjà été installée ?
Supprimer le package et relancer un npm install propre n’est pas nécessairement suffisant.
Si du code malveillant a déjà été exécuté, il faut partir du principe qu’il a potentiellement pu accéder aux secrets disponibles dans cet environnement.
Dans le cas de la récente campagne ChainDrop, les chercheurs ont recommandé de considérer un poste de développement ou un runner CI/CD ayant exécuté une version contaminée comme potentiellement compromis, même après suppression du package.
La réponse peut alors impliquer :
isoler l’environnement → rechercher les traces de compromission → révoquer les sessions → renouveler les secrets → vérifier les dépôts et workflows → reconstruire proprement l’environnement.
C’est exactement ce qu’OpenAI a expliqué avoir fait après avoir identifié en mai 2026 deux postes internes affectés par la compromission TanStack : isolation, révocation de sessions, rotation des identifiants concernés et restriction temporaire de certains workflows de déploiement. OpenAI indiquait n’avoir trouvé aucune preuve d’accès aux données utilisateurs ni de compromission de ses systèmes de production.
Le véritable enseignement de Shai-Hulud
Le message principal n’est pas :
« N’utilisez plus npm. »
Ni même :
« N’utilisez plus l’open source. »
Ce serait irréaliste.
L’open source est aujourd’hui un élément essentiel du développement logiciel.
La bonne conclusion est plutôt :
Une dépendance externe fait partie de votre surface d’attaque.
La cybersécurité d’une application ne commence donc plus uniquement à la frontière du serveur de production.
Elle commence dès :
le poste développeur → le dépôt Git → les dépendances → le pipeline CI/CD → le registre → l’infrastructure → la production.
C’est toute cette chaîne qu’il faut sécuriser.
Développement rapide ne doit pas signifier confiance aveugle
Les outils modernes permettent aujourd’hui de créer une application extrêmement rapidement.
Frameworks, bibliothèques open source, containers, CI/CD et désormais assistants IA accélèrent énormément le développement.
Mais cette vitesse augmente également le nombre d’éléments que l’on intègre.
Un développeur peut ajouter une nouvelle bibliothèque en quelques secondes.
Une IA de développement peut elle aussi proposer puis installer automatiquement plusieurs dépendances.
Cette facilité rend progressivement indispensable une politique claire :
quels packages pouvons-nous utiliser ?
qui valide les nouvelles dépendances ?
comment sont-elles mises à jour ?
quels outils les analysent ?
quels secrets sont accessibles pendant leur installation ?
Ces questions ne concernent plus uniquement les très grandes entreprises.
Une PME disposant d’une application métier, d’un site e-commerce ou d’un logiciel SaaS peut elle aussi dépendre d’une importante chaîne de composants externes.
Comment APT Informa aborde la sécurité de la supply chain
Chez APT Informa, nous considérons que la sécurité doit être intégrée dès la conception des applications et des infrastructures.
Cela signifie notamment prendre en compte :
le code, mais aussi les dépendances, les dépôts Git, la CI/CD, les secrets, l’infrastructure et les mécanismes de déploiement.
Lors de la conception ou de l’évolution d’une application, plusieurs mesures peuvent être mises en place selon le contexte :
contrôle et analyse des dépendances, automatisation des mises à jour, isolation des environnements, gestion sécurisée des secrets, restriction des permissions CI/CD, scans de sécurité et supervision des composants utilisés.
Le but n’est pas d’empiler vingt outils de cybersécurité.
Le but est de construire une chaîne :
compréhensible, maîtrisée, surveillée et capable de réagir lorsqu’un composant externe devient dangereux.
Ce qu’il faut retenir
Shai-Hulud montre à quel point une application peut être compromise sans que l’attaquant n’attaque directement son code métier.
Un composant légitime peut être détourné.
Un compte de mainteneur peut être compromis.
Un pipeline peut publier une version malveillante.
Et quelques minutes plus tard, cette version peut être installée automatiquement dans de nombreux environnements.
La question ne doit donc plus être uniquement :
« Notre application contient-elle des vulnérabilités ? »
Mais aussi :
« Peut-on réellement faire confiance à toute la chaîne qui construit notre application ? »
APT Informa peut vous accompagner
Vous développez une application, utilisez des pipelines CI/CD ou souhaitez renforcer la sécurité de votre infrastructure de développement ?
APT Informa peut vous accompagner dans l’analyse de votre chaîne logicielle, la sécurisation des dépendances, la gestion des secrets et la mise en place d’une approche DevSecOps adaptée à votre organisation.
L’objectif : réduire la surface d’attaque sans ralentir inutilement vos équipes de développement.