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

5 min de lecture

454 648 nouveaux paquets malveillants détectés dans les registres open source rien qu’en 2025. Soit 75 % de plus qu’en 2024. Et en mars 2026, la campagne GlassWorm illustre à quel point les attaques contre la chaîne d’approvisionnement logicielle sont désormais industrialisées : 433 composants compromis en une semaine, dissimulés grâce à 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 pour les cybercriminels.

L’essentiel

454 648 nouveaux paquets malveillants identifiés dans les registres open source en 2025, portant à plus de 1,2 million le nombre cumulé de paquets malveillants connus (Sonatype, janvier 2026).
La campagne GlassWorm a compromis plus de 433 composants en mars 2026 : 72 extensions VS Code, 88 paquets npm, plus de 151 dépôts GitHub (Aikido Security / BleepingComputer).
Croissance de 75 % du malware open source, les téléchargements atteignant 9 800 milliards (Rapport Sonatype 2026).
65 % de toutes les CVE open source n’ont pas reçu de score CVSS de la part du NVD – une lacune d’évaluation massive (Sonatype 2026).
La directive NIS2 exige explicitement une gestion des risques liés à la chaîne d’approvisionnement. Le BSI (Office fédéral de la sécurité informatique) a défini l’obligation de SBOM comme fondement via la norme technique TR-03183-2.

GlassWorm : anatomie d’une attaque industrialisée

En mars 2026, des chercheurs en sécurité d’Aikido Security ont mis au jour l’une des campagnes les plus sophistiquées menées à ce jour contre la chaîne d’approvisionnement logicielle. Baptisée GlassWorm, cette opération a compromis plus de 433 composants logiciels en moins de deux semaines : 72 extensions Visual Studio Code sur le marché Open VSX, 88 paquets npm et plus de 151 dépôts GitHub.

Ce qui distingue GlassWorm, ce n’est pas le volume, mais la méthode. Les attaquants ont utilisé des caractères Unicode invisibles – appelés sélecteurs de variation et codes de la zone d’usage privé – pour dissimuler du code malveillant dans le code source. Pour un relecteur humain, 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.

S’ajoutent à cela des « commits » de couverture générés par IA : des modifications de code apparemment anodines destinées à masquer le code malveillant réel dans l’historique des commits. La communication avec les serveurs de commande et de contrôle s’effectuait 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 passent par des services légitimes.

454.648

nouveaux paquets malveillants dans les registres open source (2025)

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

Les objectifs : récupérer les identifiants npm, GitHub et les configurations Git, vider les portefeuilles de cryptomonnaies et installer des backdoors persistantes dans les environnements de développement. Toute personne ayant installé une extension VS Code compromise donnait aux attaquants un accès complet à son poste de travail – y compris à toutes les informations d’identification stockées localement.

L’industrialisation de la chaîne logicielle comme surface d’attaque

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

Les méthodes d’attaque ont fondamentalement évolué. Si les attaques contre la chaîne d’approvisionnement étaient autrefois le fait d’acteurs isolés exploitant des fautes de frappe dans les noms de paquets (typosquatting), ce sont désormais des groupes soutenus par des États qui opèrent avec des moyens industriels. Le groupe Lazarus (Corée du Nord) a utilisé en 2025 des chaînes de charge utile en plusieurs étapes, où un seul paquet manipulé en chargeait en cascade cinq autres composants malveillants.

L’incident « Shai-Hulud » marque un autre tournant : le premier ver npm autoréplicatif, ayant créé plus de 500 nouveaux paquets dans le registre en quelques jours. Désormais, 55,9 % de tous les paquets malveillants documentés utilisent le détournement de dépôts 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 désormais une infrastructure de production, les attaquants le savent, et l’IA accélère tout le système. La confiance doit désormais évoluer à la vitesse des machines dans le développement logiciel – ce qui exige des mesures de protection automatisées intégrées aux flux de travail, et non des rapports rétroactifs (Sonatype, State of the Software Supply Chain Report 2026).

Pourquoi les approches classiques de sécurité échouent

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

La lacune d’évaluation du NVD : selon Sonatype, 65 % des CVE open source ne disposent d’aucun score CVSS de la part de la National Vulnerability Database (NVD). Les scanners de vulnérabilités basés sur les données du NVD sont donc systématiquement aveugles face à une grande partie des vulnérabilités connues. Les entreprises qui s’appuient uniquement sur des analyses automatisées vivent dans une fausse sécurité.

Les postes de développeurs comme zone d’ombre : les extensions d’IDE ne sont généralement pas surveillées par la sécurité informatique dans la plupart des entreprises. La campagne GlassWorm cible précisément cette faille : les extensions VS Code disposent de permissions étendues sur le système hôte, mais elles sont rarement traitées comme des logiciels à part entière. Microsoft a également averti en mars 2026 des extensions d’assistants IA capables de voler les historiques de discussion de Copilot et d’autres outils LLM.

L’IA contre les relectures manuelles : lorsque les attaquants utilisent des « commits » de couverture générés par IA, les relectures manuelles du code 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 comportementale, et non sur des vérifications de signature, devient obligatoire.

65 %

des CVE open source sans score CVSS du NVD

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

NIS2 et l’obligation de sécuriser les chaînes d’approvisionnement

Pour les entreprises en Allemagne, la sécurisation de la chaîne d’approvisionnement logicielle n’est plus optionnelle. La directive NIS2 exige explicitement, à l’article 21, des mesures de sécurité pour la chaîne d’approvisionnement. Le BSI (Office fédéral de la sécurité informatique) a défini, via la directive technique TR-03183-2, la SBOM comme outil obligatoire.

La conséquence : les entreprises doivent documenter quels composants open source sont intégrés dans leurs produits et outils internes. Elles doivent disposer de processus permettant de réagir rapidement aux vulnérabilités connues affectant ces composants. Et elles doivent réaliser des évaluations de risques pour leurs fournisseurs critiques, y compris les fournisseurs de logiciels.

Le Rapport 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 à l’utilisation par les attaquants de l’IA pour détecter les vulnérabilités.

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

1. Mettre en place une liste blanche d’extensions. Les extensions d’IDE, les modules complémentaires de navigateur et les outils CLI ne doivent être installés que s’ils figurent sur des listes approuvées. VS Code propose à cet effet le paramètre « extensions.allowed » dans les politiques d’entreprise.

2. Créer une SBOM pour tous les produits et outils internes. CycloneDX ou SPDX comme format, générés automatiquement dans la chaîne CI/CD. Sans SBOM, aucune visibilité sur ses propres dépendances.

3. Activer le balayage des dépendances dans la CI/CD. Des outils comme Snyk, Grype ou Dependabot vérifient automatiquement à chaque compilation si des vulnérabilités connues sont présentes dans les paquets utilisés.

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

5. Appliquer le modèle Zero Trust à l’environnement de développement. Les postes de développeurs doivent bénéficier du même niveau de sécurité que les serveurs de production : EDR, segmentation réseau, contrôle d’accès privilégié. L’époque où les postes de développeurs bénéficiaient d’un statut particulier est révolue.

6. Compléter les données du NVD par des services commerciaux de renseignement sur les menaces. Face à une lacune de 65 % dans les scores CVSS, les scanners basés uniquement sur le NVD sont insuffisants. Des services comme Sonatype, Snyk ou Tidelift fournissent des données plus complètes et actualisées.

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

Conclusion

Les attaques contre la chaîne d’approvisionnement logicielle sont industrialisées en 2026. La campagne GlassWorm montre comment les attaquants compromettent simultanément des extensions IDE, des paquets npm et des dépôts GitHub, en utilisant des caractères Unicode invisibles et des commits générés par IA. Pour les responsables de la sécurité informatique, cela signifie que leur environnement de développement n’est plus digne de confiance tant qu’il n’est pas activement protégé. NIS2 rend la gestion des risques liés à la chaîne d’approvisionnement obligatoire, et le BSI fournit l’outil adéquat avec la norme SBOM. Celui qui n’agit pas maintenant sera pris au dépourvu lors de la prochaine attaque de type GlassWorm.

Questions fréquentes

Qu’est-ce qu’une attaque contre la chaîne d’approvisionnement logicielle ?

Une attaque qui ne vise pas directement l’entreprise cible, mais compromet une composante logicielle utilisée par celle-ci. Cela peut concerner des bibliothèques open source, des extensions d’IDE, des outils de compilation ou des paquets provenant de registres publics comme npm ou PyPI. Le code malveillant est automatiquement distribué lors de la prochaine mise à jour ou installation.

Comment savoir si mon entreprise est concernée ?

Sans SBOM ni analyse des dépendances, la réponse honnête est : probablement pas. La première étape consiste à faire l’inventaire de tous les composants open source utilisés. Des outils comme Grype ou Syft peuvent générer automatiquement des SBOM et les comparer aux bases de données de vulnérabilités connues.

Une Web Application Firewall (WAF) 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 réseau. Les attaques de la chaîne d’approvisionnement proviennent de l’intérieur – via des dépendances compromises considérées comme fiables. Seuls l’analyse des dépendances, la gestion de SBOM et la liste blanche d’extensions sont efficaces.

Que demande concrètement NIS2 concernant la chaîne logicielle ?

L’article 21 de la directive NIS2 exige des mesures de sécurité pour la chaîne d’approvisionnement, y compris les relations avec les fournisseurs et prestataires directs. Le BSI précise cette exigence dans la TR-03183-2 en imposant la SBOM. Les entreprises doivent documenter les composants utilisés et disposer de processus permettant de réagir rapidement aux vulnérabilités.

Quel est le coût de sécurisation de la chaîne d’approvisionnement logicielle ?

Pour les PME disposant d’une chaîne CI/CD existante, le coût s’élève à 10 000 à 30 000 Euro (une fois) pour les outils, la mise en place de la SBOM et les politiques d’extensions, plus des coûts annuels de 2 000 à 10 000 Euro pour les bases de données commerciales de vulnérabilités. Sans CI/CD, les coûts montent à 40 000 à 80 000 Euro, car l’infrastructure doit d’abord être construite.