Chaîne logicielle 2026 : quand une intrusion en déclenche des centaines

En 2026, les attaques sur la chaîne logicielle ont commencé à se propager seules. Un compte de développeur compromis infecte le suivant, puis le suivant, sans que l’attaquant intervienne à nouveau. Une intrusion unique peut contaminer des centaines de projets.

Trois cas ont marqué l’année : Shai-Hulud, un ver qui se répand à travers npm ; GlassWorm, un logiciel malveillant qui survit à la revue de code ; et une campagne multi-registres qui a touché jusqu’aux outils de sécurité censés détecter ce genre de menace. Voici comment chacun fonctionne, qui est probablement derrière, et les quatre défenses qui limitent vraiment les dégâts.

Pourquoi le scénario a changé

Pendant des années, l’attaquant choisissait une cible, trouvait une dépendance faible à l’intérieur, et exploitait ce chemin. La vague 2026 inverse l’effort. L’attaquant compromet un seul paquet, laisse ce paquet contaminer ses voisins, et récupère les identifiants trouvés en chemin.

Les pipelines de build sont la vraie cible. Ils hébergent des jetons de publication, des accès aux registres, des clés de signature, et ils exécutent du code non vérifié à chaque installation de dépendance. Un seul jeton npm volé transforme une intrusion unique en publication sur l’ensemble des paquets que ce jeton peut publier. Le danger n’est plus le paquet que vous venez d’installer, mais tous les paquets dont il dépend, jusqu’au fond de l’arbre — dans un projet moderne, cela représente des centaines de bibliothèques que vous n’avez jamais choisies directement.

Shai-Hulud : un paquet qui compromet ses voisins

Shai-Hulud est le cas npm le plus marquant de 2026 : un ver autopropageant.

La mécanique est simple. Un développeur ou un job d’intégration continue installe un paquet compromis. Lors de l’installation, un script de cycle de vie (généralement postinstall) s’exécute sur la machine. Ce script cherche des identifiants : variables d’environnement du runner CI, contenu de ~/.npmrc, points de terminaison de métadonnées cloud, tout jeton mis en cache qu’il peut atteindre. Quand il trouve un jeton de publication npm, il ne se contente pas de le voler. Il l’utilise.

Avec ce jeton, le ver liste tous les paquets que le mainteneur peut publier, glisse sa charge utile dans chacun, incrémente la version, et republie. Chaque projet en aval qui accepte une plage de versions avec ^ ou ~ reçoit la mise à jour empoisonnée sans que personne touche au code. Certains de ces mainteneurs ont eux-mêmes des jetons de publication, donc depuis chaque nouveau compte la boucle recommence. Le ver continue à se propager après que l’attaquant est parti, ce qui fait de Shai-Hulud autopropageant et non simplement un malware à diffusion large.

Les scripts de cycle de vie expliquent pourquoi npm est si exposé : npm install exécute du code du paquet par défaut, donc l’attaquant peut faire tourner son code avant que quiconque en lise une ligne. La même installation qui télécharge un correctif peut embarquer le ver.

Auditer le paquet que vous venez d’ajouter ne suffit plus. Il était peut-être propre la semaine dernière et weaponisé du jour au lendemain, par un mainteneur trois niveaux au-dessus de votre arbre que vous n’avez jamais rencontré.

GlassWorm : un logiciel malveillant qui survit à la revue de code

GlassWorm, signalé en mars 2026, cible les extensions VS Code et OpenVSX via un vecteur différent : l’écart entre ce que votre écran affiche et ce que l’interpréteur lit.

La charge utile est écrite dans des caractères Unicode invisibles, de largeur nulle, qui n’occupent aucun espace à l’écran. Lors d’une revue de code, la diff semble propre. Un reviewer lisant la pull request voit du JavaScript ordinaire et inoffensif, parce que les instructions malveillantes ne s’affichent pas dans l’éditeur ni dans la visionneuse de diff web.

C’est pour ça que GlassWorm échappe à la revue de code manuelle. La revue est un acte visuel : on fait confiance au fait que ce qu’on voit à l’écran est ce qui s’exécute. Les caractères de largeur nulle et bidirectionnels brisent cette confiance. L’interpréteur lit chaque octet, l’humain ne lit que les caractères visibles. Une extension peut passer une revue attentive, être publiée sur OpenVSX, et embarquer une charge utile qu’aucun reviewer n’aurait pu détecter sans passer le fichier dans un dump hexadécimal ou un linter Unicode. Comme OpenVSX alimente plusieurs forks de VS Code et des éditeurs assistés par IA, la portée dépasse largement le marketplace de Microsoft.

La parade, c’est un outillage qui signale les caractères Unicode non imprimables et bidirectionnels dans le code source, et traiter les extensions d’éditeur comme ce qu’elles sont : du code privilégié qui se met à jour automatiquement. Une extension a accès à tous vos fichiers et jetons. Elle mérite le même niveau de contrôle qu’une dépendance, et ne l’obtient presque jamais.

La campagne multi-registres de 2026

La vague 2026 a traversé les registres et les écosystèmes de conteneurs simultanément.

Un groupe à motivation financière suivi sous le nom de TeamPCP a mené une campagne durant le premier semestre 2026 qui a ciblé une série d’outils de développement très utilisés. En mars 2026, l’équipe Microsoft Defender Security Research a documenté la compromission de Trivy, le scanner de conteneurs et d’infrastructure, après que les attaquants ont exploité une correction incomplète d’un problème antérieur, en abusant de tags de version mutables pour pousser des commits malveillants dans l’arbre de versions de Trivy. La campagne s’est poursuivie en avril : le 22 avril, des images empoisonnées ont été poussées sur le dépôt Docker de Checkmarx kics, et une version malveillante du paquet @bitwarden/cli a été publiée sur npm. Plus tôt dans la campagne, un SDK PyPI avait également été ciblé. Les cibles couvraient des outils CLI Go, des images Docker Hub, des paquets npm et PyPI — les attaquants n’étaient fidèles à aucun registre en particulier.

Quand le scanner lui-même est compromis, l’outil censé détecter la menace devient celui qui la livre. Le Bitwarden CLI manipule des secrets par conception, donc une version altérée est un chemin rapide vers des identifiants, même si ce paquet npm n’est resté en ligne qu’environ quatre-vingt-dix minutes avant d’être retiré. L’image kics est restée sur Docker Hub, un dépôt avec des millions de pulls, donc la contamination a traversé des registres de paquets vers le monde des conteneurs et les pipelines CI qui tirent des images à chaque run.

Un build moderne tire depuis de nombreuses sources à la fois, et chacune est un canal séparé avec ses propres contrôles de publication. L’attaquant n’a besoin que du plus faible. La surface s’élargit plus vite que la plupart des équipes ne peuvent même lister ce qu’elles tirent au moment du build.

Qui est derrière, avec une attribution mesurée

L’attribution dans les attaques sur la chaîne logicielle est rarement nette. Ce qui suit est une évaluation, pas un verdict.

Le groupe le plus directement lié à l’activité des vers en 2026 est TeamPCP, un groupe à motivation financière apparu fin 2025. Les chercheurs relient les vagues Mini Shai-Hulud ainsi que les compromissions de Trivy, Checkmarx kics et Bitwarden CLI au même cluster. En mai 2026, le groupe a publié en open source son framework Shai-Hulud sur GitHub, une boîte à outils modulaire pour collecter des identifiants et empoisonner des chaînes logicielles. Les chercheurs qui suivent ce groupe décrivent son objectif comme financier : une méthode répétable et automatisée pour monétiser la confiance des développeurs.

Le rapport 2026 de Group-IB place cette activité dans un paysage plus large d’acteurs de la chaîne logicielle. Lazarus, très probablement lié à la Corée du Nord, publie des paquets npm malveillants qui imitent des bibliothèques populaires et attire les développeurs avec des malwares voleurs d’identifiants via de faux entretiens d’embauche. DragonForce gère un service de ransomware ciblant les prestataires de services managés, puis exploite leur accès administrateur pour atteindre chacun de leurs clients en aval. Un groupe suivi sous le nom 888 vend des accès basés sur des liens vendeurs partagés ; dans un cas, il a compromis un prestataire unique travaillant pour plusieurs entreprises et a récupéré leur code source d’un coup.

Ce qui relie ces groupes, c’est un calcul commun : s’introduire chez un fournisseur ou un prestataire en amont est moins coûteux et plus discret qu’attaquer chaque cible une par une. Acteurs étatiques, groupes de ransomware et courtiers en accès ont tous convergé vers cette approche.

Quatre défenses qui réduisent vraiment la surface d’impact

La plupart des conseils sur la chaîne logicielle sont génériques. Ces quatre contrôles s’articulent directement sur les attaques décrites ci-dessus, avec la raison pour laquelle chacun fonctionne.

Générer et consommer un SBOM

Un SBOM (Software Bill of Materials) — la nomenclature de votre logiciel — est l’inventaire sans lequel on ne peut pas se défendre. La campagne multi-registres fonctionne en partie parce que les équipes ne savent pas ce qu’elles tirent. Générez un SBOM (format CycloneDX ou SPDX) à chaque build, stockez-le comme artefact, et comparez-le d’un build à l’autre. Quand le prochain avis de sécurité cite un paquet, répondre à « sommes-nous exposés » doit prendre des minutes, pas des jours. Un diff de SBOM est ce qui détecte une republication nocturne par un ver avant qu’elle n’atteigne la production.

Épingler les dépendances et vérifier l’intégrité du lockfile

L’épinglage des versions est le geste à plus fort impact contre la propagation des vers. La faille, c’est l’opérateur ^ ou ~ dans les plages de versions. Un caret accepte silencieusement une nouvelle version mineure ou patch — exactement comment une version empoisonnée et republiée vous atteint sans que vous ayez touché au code. Épinglez les versions exactes, committez votre lockfile, utilisez npm ci plutôt que npm install en CI, et vérifiez les hashes d’intégrité. Là où une version compromise est connue, forcez un épinglage jusqu’au bas de l’arbre :

{
  "overrides": {
    "compromised-pkg": "1.2.3"
  }
}

Un lockfile épinglé et vérifié par hash aurait neutralisé le cœur du mécanisme de Shai-Hulud — la mise à jour silencieuse vers une version empoisonnée.

Signer les artefacts et vérifier la provenance

Arrêtez de supposer qu’un registre vous a livré ce que le mainteneur a réellement publié. Signez les artefacts de build et vérifiez la signature et la provenance avant de les exécuter. Cosign de Sigstore combiné aux attestations de provenance SLSA vous permet de prouver où un artefact a été construit et par quel pipeline, puis de rejeter tout ce qui ne passe pas la vérification :

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/your-org/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/your-org/your-image:latest

C’est la même idée appliquée aux artefacts. Au lieu de faire confiance au canal, vous vérifiez chaque artefact et chaque identité dans le pipeline — la posture que notre guide zero trust pour 2026 applique au réseau et aux identités. La vérification des artefacts est précisément la réponse au cas de scanner compromis comme la compromission de Trivy en mars.

Passer à la publication via OIDC

Les jetons à longue durée de vie sont le carburant qui permet à un ver de se propager. Shai-Hulud se répand parce qu’il trouve un jeton npm réutilisable dans un runner CI et le rejoue. La plupart des configurations CI ont exactement un jeton npm à longue durée de vie, ajouté il y a des années par quelqu’un qui a depuis quitté l’entreprise. La publication via OIDC supprime le jeton : le registre fait confiance à une identité éphémère, scopée à un seul workflow et générée fraîchement à chaque run — il n’y a donc rien de permanent à voler depuis ~/.npmrc ou l’environnement d’un runner. Pas d’identifiant persistant, pas de carburant pour le ver. Si vous publiez depuis un pipeline CI en 2026, c’est le changement qui ferme la boucle sur laquelle le ver s’appuie.

Questions fréquentes

Qu’est-ce qu’une attaque sur la chaîne logicielle ?

Elle empoisonne le logiciel avant qu’il vous parvienne, en altérant une dépendance, un outil de build, un registre ou les identifiants d’un mainteneur. Vous intégrez ensuite le code malveillant via votre installation ou mise à jour habituelle, sans intrusion directe dans vos propres systèmes.

En quoi Shai-Hulud diffère-t-il d’un paquet malveillant ordinaire ?

Il se propage seul. Un paquet malveillant ordinaire s’installe dans un registre et attend d’être installé. Shai-Hulud vole les jetons de publication de quiconque l’installe, les utilise pour empoisonner et republier les autres paquets de ce mainteneur, puis recommence depuis chaque nouveau compte atteint — sans que l’attaquant ait à lever le petit doigt.

Comment GlassWorm échappe-t-il à la revue de code ?

Il écrit sa charge utile dans des caractères Unicode invisibles et de largeur nulle qui n’apparaissent pas à l’écran. Un reviewer lisant la diff voit du code propre, car les instructions malveillantes n’occupent aucun espace visible, tandis que l’interpréteur lit et exécute chaque octet.

Quels outils ont été touchés dans la campagne multi-registres 2026 ?

La campagne TeamPCP a touché Trivy en mars 2026, documentée par Microsoft Defender Security Research, puis l’image Docker Checkmarx kics et le paquet npm @bitwarden/cli le 22 avril, avec une activité PyPI plus tôt dans la même campagne. Elle couvrait des outils CLI Go, Docker Hub et plusieurs registres de paquets — pas un seul écosystème.

Qui est derrière les attaques sur la chaîne logicielle en 2026 ?

Les chercheurs en sécurité relient les vagues Mini Shai-Hulud et les compromissions de Trivy, kics et Bitwarden CLI à un groupe à motivation financière appelé TeamPCP. Le rapport 2026 de Group-IB les place dans un paysage plus large d’acteurs, incluant Lazarus, DragonForce et un groupe suivi sous le nom 888. L’attribution reste une évaluation, pas une certitude.

Quelle est la défense la plus efficace ?

Contre la propagation des vers spécifiquement : épinglez les versions exactes avec un lockfile vérifié par hash, et combinez cela avec la publication via OIDC pour éliminer les jetons à longue durée de vie. L’épinglage bloque la mise à jour empoisonnée silencieuse ; OIDC supprime l’identifiant dont le ver a besoin pour se propager.

Ce qu’on retient

La vague 2026 récompense les équipes qui savent ce qu’elles exécutent et le vérifient avant de le faire tourner. Commencez par deux gestes ce trimestre : épinglez et vérifiez par hash vos lockfiles pour éliminer les mises à jour silencieuses, et basculez la publication CI vers OIDC pour ne plus avoir de jetons permanents à voler. Ajoutez ensuite la génération de SBOM et la vérification cosign. Rien de tout cela n’est exotique, et ensemble ces quatre mesures transforment un mainteneur compromis en incident contenu plutôt qu’en contamination autopropageante.