5 Min. Temps de lecture<\/p>\n
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 \u00e0 quel point les attaques de la cha\u00eene d’approvisionnement logiciel sont d\u00e9sormais industrialis\u00e9es : 433 composants compromis en une semaine, dissimul\u00e9s par des caract\u00e8res Unicode invisibles et des commits de couverture g\u00e9n\u00e9r\u00e9s par IA. Pour les entreprises qui ne surveillent pas syst\u00e9matiquement leurs d\u00e9pendances Open Source, leur propre environnement de d\u00e9veloppement devient une porte d’entr\u00e9e.<\/strong><\/p>\n Les points cl\u00e9s en bref<\/p>\n En mars 2026, des chercheurs en s\u00e9curit\u00e9 de Aikido Security<\/a> ont d\u00e9couvert l’une des campagnes de cha\u00eene d’approvisionnement les plus sophistiqu\u00e9es \u00e0 ce jour. L’op\u00e9ration baptis\u00e9e GlassWorm a compromis plus de 433 composants logiciels en moins de deux semaines : 72 extensions de code Visual Studio dans le march\u00e9 Open VSX, 88 packages npm et plus de 151 r\u00e9f\u00e9rentiels GitHub.<\/p>\n Ce qui rendait GlassWorm unique n’\u00e9tait pas la quantit\u00e9, mais la m\u00e9thode. Les attaquants ont utilis\u00e9 des caract\u00e8res Unicode invisibles – appel\u00e9s s\u00e9lecteurs de variation et codes de zone d’utilisation priv\u00e9e – pour cacher du code malveillant dans le code source. Pour les r\u00e9viseurs humains, le code semblait propre. Ce n’est qu’une analyse automatis\u00e9e des s\u00e9quences d’octets qui a r\u00e9v\u00e9l\u00e9 les charges utiles cach\u00e9es.<\/p>\n Ils ont \u00e9galement utilis\u00e9 des \u00ab commits de couverture \u00bb g\u00e9n\u00e9r\u00e9s par IA : des modifications de code sans danger qui \u00e9taient cens\u00e9es masquer le v\u00e9ritable code malveillant dans l’historique des commits. La communication avec les serveurs de commande et de contr\u00f4le s’est effectu\u00e9e via la blockchain Solana<\/a> – avec Google Calendar comme canal de secours. Les outils classiques de surveillance r\u00e9seau ne d\u00e9tectent pas ces canaux de communication car ils utilisent des services l\u00e9gitimes.<\/p>\n 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\u00e9veloppement. Quiconque a install\u00e9 une extension VS Code compromise a donn\u00e9 aux attaquants acc\u00e8s \u00e0 son ordinateur de travail entier – y compris toutes les informations d’identification stock\u00e9es.<\/p>\n GlassWorm n’est pas un cas isol\u00e9. Selon le rapport \u00ab\u00a0State of the Software Supply Chain 2026\u00a0\u00bb de Sonatype<\/a>, plus de 454 648 nouveaux paquets malveillants ont \u00e9t\u00e9 identifi\u00e9s en 2025 dans des registres open source tels que npm, PyPI et Maven Central. Cela repr\u00e9sente une croissance de 75 % par rapport \u00e0 l’ann\u00e9e pr\u00e9c\u00e9dente. Au total, plus de 1,2 million de paquets malveillants connus sont d\u00e9sormais document\u00e9s.<\/p>\n Les m\u00e9thodes d’attaque ont fondamentalement chang\u00e9. Alors que les attaques contre la cha\u00eene d’approvisionnement \u00e9taient il y a quelques ann\u00e9es le fait d’acteurs individuels qui exploitaient des erreurs de frappe dans les noms de paquets (typosquatting), aujourd’hui des groupes soutenus par l’\u00c9tat op\u00e8rent avec des moyens industriels. Le groupe Lazarus (Cor\u00e9e du Nord) a utilis\u00e9 en 2025 des cha\u00eenes de payload \u00e0 plusieurs niveaux, o\u00f9 un seul paquet manipul\u00e9 d\u00e9clenchait une cascade de cinq autres composants malveillants.<\/p>\n L’incident \u00ab\u00a0Shai-Hulud\u00a0\u00bb marque un autre tournant : le premier ver npm auto-reproducteur, qui a cr\u00e9\u00e9 plus de 500 nouveaux paquets dans le registre en quelques jours. 55,9 % de tous les paquets malveillants document\u00e9s utilisent d\u00e9sormais l’abus de r\u00e9f\u00e9rentiel comme m\u00e9thode de distribution principale – les registres sont syst\u00e9matiquement exploit\u00e9s comme des plateformes publicitaires.<\/p>\n Brian Fox, CTO de Sonatype, r\u00e9sume la situation : l’open source est depuis longtemps une infrastructure de production, les attaquants le savent, et l’IA acc\u00e9l\u00e8re l’ensemble du syst\u00e8me. La confiance doit suivre la vitesse de la machine des logiciels – cela n\u00e9cessite des mesures de protection automatis\u00e9es dans le workflow, et non des rapports a posteriori (Sonatype, State of the Software Supply Chain Report 2026).<\/p>\n Trois probl\u00e8mes structurels rendent particuli\u00e8rement difficile la d\u00e9fense contre les attaques contre la cha\u00eene d’approvisionnement :<\/p>\n L’\u00e9cart d’\u00e9valuation de la NVD :<\/strong> 65 % de toutes les CVE open source n’ont pas de score CVSS de la National Vulnerability Database, selon Sonatype. Les scanners de vuln\u00e9rabilit\u00e9s bas\u00e9s sur les donn\u00e9es de la NVD sont ainsi syst\u00e9matiquement aveugles \u00e0 une grande partie des vuln\u00e9rabilit\u00e9s connues. Les entreprises qui se fient exclusivement \u00e0 des analyses automatis\u00e9es se bercent d’une fausse s\u00e9curit\u00e9.<\/p>\n Les postes de travail des d\u00e9veloppeurs comme point aveugle :<\/strong> les extensions d’IDE ne sont pas surveill\u00e9es par la s\u00e9curit\u00e9 informatique dans la plupart des entreprises. La campagne GlassWorm visait pr\u00e9cis\u00e9ment ce point aveugle : les extensions de code VS ont des autorisations \u00e9tendues sur le syst\u00e8me h\u00f4te, mais sont rarement trait\u00e9es comme des installations de logiciels. Microsoft a \u00e9galement averti en mars 2026 des extensions d’assistants IA qui volent les historiques de discussion de Copilot et d’autres outils LLM.<\/p>\n L’IA contre les examens manuels :<\/strong> lorsque les attaquants utilisent des commits de couverture g\u00e9n\u00e9r\u00e9s par IA, les examens de code manuels ne suffisent plus. La vitesse \u00e0 laquelle de nouveaux paquets malveillants sont cr\u00e9\u00e9s et distribu\u00e9s d\u00e9passe la capacit\u00e9 des analystes humains. La d\u00e9tection automatis\u00e9e bas\u00e9e sur l’analyse du comportement au lieu de la simple v\u00e9rification de signatures devient une obligation.<\/p>\n Pour les entreprises en Allemagne, la s\u00e9curisation de la cha\u00eene d’approvisionnement logiciel n’est plus facultative. NIS-2 exige explicitement dans l’article 21 des mesures de s\u00e9curit\u00e9 pour la cha\u00eene d’approvisionnement. Le BSI a d\u00e9fini la SBOM comme instrument obligatoire<\/a> avec la directive technique TR-03183-2.<\/p>\n La cons\u00e9quence : les entreprises doivent documenter quelles sont les composantes Open Source utilis\u00e9es dans leurs produits et outils internes. Elles doivent avoir des processus pour r\u00e9agir rapidement en cas de vuln\u00e9rabilit\u00e9s connues dans ces composantes. Et elles doivent effectuer des \u00e9valuations des risques pour leurs fournisseurs critiques, y compris les fournisseurs de logiciels.<\/p>\n L’IBM X-Force Threat Intelligence Index 2026<\/a> confirme l’urgence : l’exploitation d’applications accessibles publiquement a augment\u00e9 de 44 %, principalement due \u00e0 l’absence de contr\u00f4les d’authentification et \u00e0 la d\u00e9tection de vuln\u00e9rabilit\u00e9s bas\u00e9e sur l’intelligence artificielle par les attaquants.<\/p>\n 1. Mettre en place un contr\u00f4le des extensions.<\/strong> Les extensions IDE, les extensions de navigateur et les outils CLI ne peuvent \u00eatre install\u00e9s que \u00e0 partir de listes approuv\u00e9es. VS-Code propose le param\u00e8tre \u00ab\u00a0extensions.allowed\u00a0\u00bb dans la politique d’entreprise.<\/p>\n 2. Cr\u00e9er une SBOM pour tous les produits et outils internes.<\/strong> CycloneDX<\/a> ou SPDX comme format, g\u00e9n\u00e9r\u00e9 automatiquement dans la pipeline CI\/CD. Sans SBOM, pas de vue d’ensemble des d\u00e9pendances.<\/p>\n 3. Activer l’analyse des d\u00e9pendances dans la pipeline CI\/CD.<\/strong> Des outils comme Snyk<\/a>, Grype ou Dependabot v\u00e9rifient automatiquement \u00e0 chaque build si des vuln\u00e9rabilit\u00e9s connues sont pr\u00e9sentes dans les packages utilis\u00e9s.<\/p>\n 4. Utiliser la v\u00e9rification Sigstore pour les packages critiques.<\/strong> Sigstore permet la signature et la v\u00e9rification cryptographiques des artefacts logiciels. Les packages manipul\u00e9s sans signature valide sont automatiquement bloqu\u00e9s.<\/p>\n 5. Zero Trust pour l’environnement de d\u00e9veloppement.<\/strong> Les postes de travail des d\u00e9veloppeurs<\/a> ont besoin du m\u00eame niveau de s\u00e9curit\u00e9 que les serveurs de production : EDR, segmentation du r\u00e9seau, contr\u00f4le d’acc\u00e8s privil\u00e9gi\u00e9. Les temps o\u00f9 les ordinateurs des d\u00e9veloppeurs avaient un r\u00f4le sp\u00e9cial sont r\u00e9volus.<\/p>\n 6. Compl\u00e9ter les donn\u00e9es NVD avec une intelligence de menace commerciale.<\/strong> \u00c9tant donn\u00e9 l’\u00e9cart de 65 % dans les scores CVSS, les scanners bas\u00e9s uniquement sur NVD sont insuffisants. Des services comme Sonatype, Snyk ou Tidelift fournissent des donn\u00e9es plus compl\u00e8tes et \u00e0 jour.<\/p>\n 7. D\u00e9finir un plan de r\u00e9ponse aux incidents pour les incidents de la cha\u00eene d’approvisionnement.<\/strong> Qui est responsable si une biblioth\u00e8que compromise est d\u00e9couverte ? Comment les syst\u00e8mes affect\u00e9s peuvent-ils \u00eatre identifi\u00e9s et corrig\u00e9s rapidement ? Ces processus doivent \u00eatre mis en place avant l’incident, pas apr\u00e8s.<\/p>\n Les attaques de la cha\u00eene d’approvisionnement logiciel sont industrialis\u00e9es en 2026. La campagne GlassWorm montre comment les attaquants compromettent simultan\u00e9ment les extensions IDE, les packages npm et les r\u00e9f\u00e9rentiels GitHub, d\u00e9guis\u00e9s en caract\u00e8res Unicode invisibles et en commits g\u00e9n\u00e9r\u00e9s par intelligence artificielle. Pour les responsables de la s\u00e9curit\u00e9 informatique, cela signifie que leur propre environnement de d\u00e9veloppement n’est plus digne de confiance tant qu’il n’est pas activement s\u00e9curis\u00e9. NIS-2 rend la gestion des risques de la cha\u00eene d’approvisionnement obligatoire, le BSI fournit l’instrument avec la directive SBOM. Qui ne prend pas de mesures maintenant sera pris au d\u00e9pourvu lors de la prochaine attaque GlassWorm.<\/p>\n Une attaque qui ne frappe pas directement l’entreprise cible, mais qui compromet une composante logicielle que l’entreprise utilise. Cela peut \u00eatre des biblioth\u00e8ques 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\u00e9 automatiquement avec la prochaine mise \u00e0 jour ou installation.<\/p>\n Sans SBOM et scan des d\u00e9pendances, la r\u00e9ponse honn\u00eate est : probablement pas. La premi\u00e8re \u00e9tape consiste \u00e0 faire un \u00e9tat des lieux de tous les composants Open Source utilis\u00e9s. Des outils comme Grype ou Syft peuvent cr\u00e9er automatiquement des SBOM et les comparer \u00e0 des bases de donn\u00e9es de vuln\u00e9rabilit\u00e9s connues.<\/p>\n Non. Une WAF prot\u00e8ge l’application contre les attaques externes au niveau du r\u00e9seau. Les attaques de la cha\u00eene d’approvisionnement viennent de l’int\u00e9rieur – via des d\u00e9pendances compromises qui sont consid\u00e9r\u00e9es comme dignes de confiance. Ici, le scan des d\u00e9pendances, la gestion des SBOM et le whitelist des extensions sont utiles.<\/p>\n L’article 21 de la directive NIS-2 exige des mesures pour la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement, y compris les relations avec les fournisseurs directs et les prestataires de services. Le BSI le pr\u00e9cise dans la TR-03183-2 avec l’obligation de SBOM. Les entreprises doivent documenter les composants qu’elles utilisent et pr\u00e9senter des processus pour une r\u00e9action rapide en cas de vuln\u00e9rabilit\u00e9s.<\/p>\n Pour les PME avec une pipeline CI\/CD existante, l’effort est estim\u00e9 entre 10 000 et 30 000 euros (outillage, introduction de SBOM, politiques d’extension) plus des co\u00fbts courants pour des bases de donn\u00e9es de vuln\u00e9rabilit\u00e9s commerciales (2 000-10 000 euros\/ an). Sans pipeline CI\/CD, les co\u00fbts augmentent \u00e0 40 000 \u00e0 80 000 euros, car il faut d’abord construire l’infrastructure.<\/p>\n SBOM-Praxischeck : Liste de logiciels jusqu’\u00e0 septembre 2026<\/a> (SecurityToday)<\/p>\n NIS2 en Allemagne : Ce que les entreprises doivent mettre en \u0153uvre maintenant (SecurityToday)<\/p>\n IA-Phishing : 82 % de tous les e-mails d’attaque sont issus de machines (SecurityToday)<\/p>\n NIS2 et cha\u00eene d’approvisionnement SaaS : La faille de conformit\u00e9<\/a> (cloudmagazin)<\/p>\n S\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement des conteneurs : SBOM et s\u00e9curisation de Docker – cloudmagazin<\/a><\/p>\n Cyber Resilience Act : Ce que les fabricants doivent faire maintenant – MyBusinessFuture<\/a><\/p>\n\n
GlassWorm : Anatomie d’une attaque industrialis\u00e9e<\/h2>\n
L’industrialisation de la cha\u00eene d’approvisionnement en logiciels comme surface d’attaque<\/h2>\n
Pourquoi les concepts de s\u00e9curit\u00e9 classiques \u00e9chouent<\/h2>\n
NIS-2 et l’obligation de la cha\u00eene d’approvisionnement<\/h2>\n
Sept mesures contre les attaques de la cha\u00eene d’approvisionnement<\/h2>\n
Conclusion<\/h2>\n
Foire aux questions<\/h2>\n
Qu’est-ce qu’une attaque de la cha\u00eene d’approvisionnement logiciel ?<\/h3>\n
Comment savoir si mon entreprise est concern\u00e9e ?<\/h3>\n
Une Web Application Firewall prot\u00e8ge-t-elle contre les attaques de la cha\u00eene d’approvisionnement ?<\/h3>\n
Que demande concr\u00e8tement NIS-2 pour la cha\u00eene de fourniture de logiciels ?<\/h3>\n
Combien co\u00fbte la s\u00e9curisation de la cha\u00eene de fourniture de logiciels ?<\/h3>\n
Lectures compl\u00e9mentaires<\/h2>\n
Plus de contenu du r\u00e9seau MBF Media<\/h2>\n