Chaîne d’approvisionnement logicielle sous pression : comment GlassWorm a compromis plus de 400 outils de développement

5 Min. Temps de lecture

454.648 nouveaux packages malveillants dans les registres Open Source rien qu’en 2025. 75 % de plus qu’en 2024. Et en mars 2026, la campagne GlassWorm montre à quel point les attaques de la chaîne d’approvisionnement logiciel sont désormais industrialisées : 433 composants compromis en une semaine, dissimulés par des caractères Unicode invisibles et des commits de couverture générés par IA. Pour les entreprises qui ne surveillent pas systématiquement leurs dépendances Open Source, leur propre environnement de développement devient une porte d’entrée.

Les points clés en bref

454.648 nouveaux packages malveillants identifiés dans les registres Open Source en 2025, soit plus de 1,2 million de packages malveillants connus au total (Sonatype, janvier 2026).
GlassWorm a compromis plus de 433 composants en mars 2026 : 72 extensions VS Code, 88 packages npm, 151+ référentiels GitHub (Aikido Security / BleepingComputer).
75 % de croissance de la malware Open Source, avec 9 800 milliards de téléchargements (rapport Sonatype 2026).
65 % de toutes les vulnérabilités Open Source n’ont pas de score CVSS attribué par le NVD – écart d’évaluation important (Sonatype 2026).
La directive NIS-2 exige explicitement une gestion des risques de la chaîne d’approvisionnement. Le BSI a défini l’obligation de SBOM comme base avec la TR-03183-2.

GlassWorm : Anatomie d’une attaque industrialisée

En mars 2026, des chercheurs en sécurité de Aikido Security ont découvert l’une des campagnes de chaîne d’approvisionnement les plus sophistiquées à ce jour. L’opération baptisée GlassWorm a compromis plus de 433 composants logiciels en moins de deux semaines : 72 extensions de code Visual Studio dans le marché Open VSX, 88 packages npm et plus de 151 référentiels GitHub.

Ce qui rendait GlassWorm unique n’était pas la quantité, mais la méthode. Les attaquants ont utilisé des caractères Unicode invisibles – appelés sélecteurs de variation et codes de zone d’utilisation privée – pour cacher du code malveillant dans le code source. Pour les réviseurs humains, le code semblait propre. Ce n’est qu’une analyse automatisée des séquences d’octets qui a révélé les charges utiles cachées.

Ils ont également utilisé des « commits de couverture » générés par IA : des modifications de code sans danger qui étaient censées masquer le véritable code malveillant dans l’historique des commits. La communication avec les serveurs de commande et de contrôle s’est effectuée via la blockchain Solana – avec Google Calendar comme canal de secours. Les outils classiques de surveillance réseau ne détectent pas ces canaux de communication car ils utilisent des services légitimes.

454.648

nouveaux packages malveillants dans les registres Open Source (2025)

Source : Sonatype, State of the Software Supply Chain Report 2026

Les objectifs : collecter des informations d’identification pour npm, GitHub et les configurations Git, vider les portefeuilles de crypto-monnaies et installer des backdoors persistants dans les environnements de développement. Quiconque a installé une extension VS Code compromise a donné aux attaquants accès à son ordinateur de travail entier – y compris toutes les informations d’identification stockées.

L’industrialisation de la chaîne d’approvisionnement en logiciels comme surface d’attaque

GlassWorm n’est pas un cas isolé. Selon le rapport « State of the Software Supply Chain 2026 » de Sonatype, plus de 454 648 nouveaux paquets malveillants ont été identifiés en 2025 dans des registres open source tels que npm, PyPI et Maven Central. Cela représente une croissance de 75 % par rapport à l’année précédente. Au total, plus de 1,2 million de paquets malveillants connus sont désormais documentés.

Les méthodes d’attaque ont fondamentalement changé. Alors que les attaques contre la chaîne d’approvisionnement étaient il y a quelques années le fait d’acteurs individuels qui exploitaient des erreurs de frappe dans les noms de paquets (typosquatting), aujourd’hui des groupes soutenus par l’État opèrent avec des moyens industriels. Le groupe Lazarus (Corée du Nord) a utilisé en 2025 des chaînes de payload à plusieurs niveaux, où un seul paquet manipulé déclenchait une cascade de cinq autres composants malveillants.

L’incident « Shai-Hulud » marque un autre tournant : le premier ver npm auto-reproducteur, qui a créé plus de 500 nouveaux paquets dans le registre en quelques jours. 55,9 % de tous les paquets malveillants documentés utilisent désormais l’abus de référentiel comme méthode de distribution principale – les registres sont systématiquement exploités comme des plateformes publicitaires.

Brian Fox, CTO de Sonatype, résume la situation : l’open source est depuis longtemps une infrastructure de production, les attaquants le savent, et l’IA accélère l’ensemble du système. La confiance doit suivre la vitesse de la machine des logiciels – cela nécessite des mesures de protection automatisées dans le workflow, et non des rapports a posteriori (Sonatype, State of the Software Supply Chain Report 2026).

Pourquoi les concepts de sécurité classiques échouent

Trois problèmes structurels rendent particulièrement difficile la défense contre les attaques contre la chaîne d’approvisionnement :

L’écart d’évaluation de la NVD : 65 % de toutes les CVE open source n’ont pas de score CVSS de la National Vulnerability Database, selon Sonatype. Les scanners de vulnérabilités basés sur les données de la NVD sont ainsi systématiquement aveugles à une grande partie des vulnérabilités connues. Les entreprises qui se fient exclusivement à des analyses automatisées se bercent d’une fausse sécurité.

Les postes de travail des développeurs comme point aveugle : les extensions d’IDE ne sont pas surveillées par la sécurité informatique dans la plupart des entreprises. La campagne GlassWorm visait précisément ce point aveugle : les extensions de code VS ont des autorisations étendues sur le système hôte, mais sont rarement traitées comme des installations de logiciels. Microsoft a également averti en mars 2026 des extensions d’assistants IA qui volent les historiques de discussion de Copilot et d’autres outils LLM.

L’IA contre les examens manuels : lorsque les attaquants utilisent des commits de couverture générés par IA, les examens de code manuels ne suffisent plus. La vitesse à laquelle de nouveaux paquets malveillants sont créés et distribués dépasse la capacité des analystes humains. La détection automatisée basée sur l’analyse du comportement au lieu de la simple vérification de signatures devient une obligation.

65 %

de toutes les CVE open source sans score CVSS de la NVD

Source : Sonatype, State of the Software Supply Chain Report 2026

NIS-2 et l’obligation de la chaîne d’approvisionnement

Pour les entreprises en Allemagne, la sécurisation de la chaîne d’approvisionnement logiciel n’est plus facultative. NIS-2 exige explicitement dans l’article 21 des mesures de sécurité pour la chaîne d’approvisionnement. Le BSI a défini la SBOM comme instrument obligatoire avec la directive technique TR-03183-2.

La conséquence : les entreprises doivent documenter quelles sont les composantes Open Source utilisées dans leurs produits et outils internes. Elles doivent avoir des processus pour réagir rapidement en cas de vulnérabilités connues dans ces composantes. Et elles doivent effectuer des évaluations des risques pour leurs fournisseurs critiques, y compris les fournisseurs de logiciels.

L’IBM X-Force Threat Intelligence Index 2026 confirme l’urgence : l’exploitation d’applications accessibles publiquement a augmenté de 44 %, principalement due à l’absence de contrôles d’authentification et à la détection de vulnérabilités basée sur l’intelligence artificielle par les attaquants.

Sept mesures contre les attaques de la chaîne d’approvisionnement

1. Mettre en place un contrôle des extensions. Les extensions IDE, les extensions de navigateur et les outils CLI ne peuvent être installés que à partir de listes approuvées. VS-Code propose le paramètre « extensions.allowed » dans la politique d’entreprise.

2. Créer une SBOM pour tous les produits et outils internes. CycloneDX ou SPDX comme format, généré automatiquement dans la pipeline CI/CD. Sans SBOM, pas de vue d’ensemble des dépendances.

3. Activer l’analyse des dépendances dans la pipeline CI/CD. Des outils comme Snyk, Grype ou Dependabot vérifient automatiquement à chaque build si des vulnérabilités connues sont présentes dans les packages utilisés.

4. Utiliser la vérification Sigstore pour les packages critiques. Sigstore permet la signature et la vérification cryptographiques des artefacts logiciels. Les packages manipulés sans signature valide sont automatiquement bloqués.

5. Zero Trust pour l’environnement de développement. Les postes de travail des développeurs ont besoin du même niveau de sécurité que les serveurs de production : EDR, segmentation du réseau, contrôle d’accès privilégié. Les temps où les ordinateurs des développeurs avaient un rôle spécial sont révolus.

6. Compléter les données NVD avec une intelligence de menace commerciale. Étant donné l’écart de 65 % dans les scores CVSS, les scanners basés uniquement sur NVD sont insuffisants. Des services comme Sonatype, Snyk ou Tidelift fournissent des données plus complètes et à jour.

7. Définir un plan de réponse aux incidents pour les incidents de la chaîne d’approvisionnement. Qui est responsable si une bibliothèque compromise est découverte ? Comment les systèmes affectés peuvent-ils être identifiés et corrigés rapidement ? Ces processus doivent être mis en place avant l’incident, pas après.

Conclusion

Les attaques de la chaîne d’approvisionnement logiciel sont industrialisées en 2026. La campagne GlassWorm montre comment les attaquants compromettent simultanément les extensions IDE, les packages npm et les référentiels GitHub, déguisés en caractères Unicode invisibles et en commits générés par intelligence artificielle. Pour les responsables de la sécurité informatique, cela signifie que leur propre environnement de développement n’est plus digne de confiance tant qu’il n’est pas activement sécurisé. NIS-2 rend la gestion des risques de la chaîne d’approvisionnement obligatoire, le BSI fournit l’instrument avec la directive SBOM. Qui ne prend pas de mesures maintenant sera pris au dépourvu lors de la prochaine attaque GlassWorm.

Foire aux questions

Qu’est-ce qu’une attaque de la chaîne d’approvisionnement logiciel ?

Une attaque qui ne frappe pas directement l’entreprise cible, mais qui compromet une composante logicielle que l’entreprise utilise. Cela peut être des bibliothèques Open Source, des extensions IDE, des outils de construction ou des packages provenant de registres publics comme npm ou PyPI. Le code malveillant est distribué automatiquement avec la prochaine mise à jour ou installation.

Comment savoir si mon entreprise est concernée ?

Sans SBOM et scan des dépendances, la réponse honnête est : probablement pas. La première étape consiste à faire un état des lieux de tous les composants Open Source utilisés. Des outils comme Grype ou Syft peuvent créer automatiquement des SBOM et les comparer à des bases de données de vulnérabilités connues.

Une Web Application Firewall protège-t-elle contre les attaques de la chaîne d’approvisionnement ?

Non. Une WAF protège l’application contre les attaques externes au niveau du réseau. Les attaques de la chaîne d’approvisionnement viennent de l’intérieur – via des dépendances compromises qui sont considérées comme dignes de confiance. Ici, le scan des dépendances, la gestion des SBOM et le whitelist des extensions sont utiles.

Que demande concrètement NIS-2 pour la chaîne de fourniture de logiciels ?

L’article 21 de la directive NIS-2 exige des mesures pour la sécurité de la chaîne d’approvisionnement, y compris les relations avec les fournisseurs directs et les prestataires de services. Le BSI le précise dans la TR-03183-2 avec l’obligation de SBOM. Les entreprises doivent documenter les composants qu’elles utilisent et présenter des processus pour une réaction rapide en cas de vulnérabilités.

Combien coûte la sécurisation de la chaîne de fourniture de logiciels ?

Pour les PME avec une pipeline CI/CD existante, l’effort est estimé entre 10 000 et 30 000 euros (outillage, introduction de SBOM, politiques d’extension) plus des coûts courants pour des bases de données de vulnérabilités commerciales (2 000-10 000 euros/ an). Sans pipeline CI/CD, les coûts augmentent à 40 000 à 80 000 euros, car il faut d’abord construire l’infrastructure.