CrowdStrike, Google et la Shadowserver Foundation ont démantelé l’opération de malware GlassWorm, mais les experts affirment que le chaos plus large qui se déroule dans les écosystèmes open source rend les retraits isolés de plus en plus temporaires.
La suppression d’une vaste opération de malware a déjà marqué un progrès dans la sécurisation de l’écosystème open source. Maintenant, il s’enregistre à peine. L’interruption de la campagne GlassWorm survient à un moment où les attaquants peuvent rapidement se reconstituer, et où les défenseurs sont de plus en plus confrontés à un nouveau défi : distinguer les menaces réelles du bruit automatisé.
« Je pense que des actions coordonnées, comme GlassWorm, peuvent rompre le contrôle, augmenter considérablement les coûts des attaquants, gagner du temps pour la remédiation et signaler la possibilité d’une riposte », a déclaré Agnidipta Sarkar, évangéliste en chef chez ColorTokens. « Mais la plupart des éliminations sont des actions temporaires au cours d’un long combat. »
Le retrait mené par CrowdStrike, mené aux côtés de Google et de la Shadowserver Foundation, a perturbé l’infrastructure liée à la campagne qui avait empoisonné des centaines de référentiels avec des packages malveillants ciblant les développeurs.
Un jour après le retrait, dans le cadre d’un développement indépendant, la base de données OSV a retiré 157 rapports de logiciels malveillants après que les responsables ont déterminé que les soumissions étaient probablement des faux positifs automatisés.
Les retraits sont utiles, mais les analystes remettent en question l’impact à long terme
Le retrait a eu lieu le 26 mai à 14h00 UTC, CrowdStrike confirmant que l’opération avait détruit « simultanément les quatre canaux de commande et de contrôle (C2) de GlassWorm ». Cela aurait contribué à séparer les opérateurs de botnet de leurs machines infectées, les empêchant ainsi de diffuser de nouveaux logiciels malveillants.
CrowdStrike a décrit l’opération GlassWorm comme ciblant l’infrastructure utilisée pour distribuer des logiciels malveillants via des référentiels axés sur les développeurs, un vecteur d’attaque de plus en plus populaire alors que les adversaires recherchent l’accès CI/CD, les informations d’identification des développeurs et les environnements d’entreprise en aval.
GlassWorm était une opération multiplateforme affectant les systèmes Windows, macOS et Linux, avec des extensions VSCode trojanisées et des packages npm et Python compromis pour la collecte d’informations et d’identifiants.
« Dans le cadre de nos efforts de perturbation, nous travaillons avec des partenaires pour faire souffrir davantage les attaquants, en particulier lorsque nous les voyons abuser de nos produits ou cibler nos utilisateurs », a déclaré John Hultquist, analyste en chef du Google Threat Intelligence Group (GTIG), dans un article X.
Néanmoins, les aspects économiques plus larges de l’abus des dépôts restent inchangés. Les écosystèmes open source continuent d’offrir aux attaquants une distribution à faible coût, une portée massive et une vérification d’identité relativement faible par rapport aux canaux de distribution de logiciels traditionnels. Cela signifie que les opérateurs derrière des campagnes comme GlassWorm peuvent souvent réapparaître rapidement sous de nouveaux comptes, domaines ou noms de packages.
« Il s’agit d’une perturbation, pas d’une éradication », a prévenu Sarkar. « Pour renforcer la résilience après un retrait, les défenseurs doivent donner la priorité à une analyse rapide après le retrait afin de détecter la réémergence d’artefacts malveillants dans les référentiels et les plateformes de distribution associés. »
Ils doivent ensuite établir des micro-périmètres granulaires, développer des capacités pour contenir la propagation entre les charges de travail, les points de terminaison, les actifs IT/OT/IoT/cloud, et limiter le rayon d’action des compromissions de la chaîne d’approvisionnement (par exemple, un package NPM empoisonné ou un workflow GitHub volant des crédits ne peuvent pas facilement pivoter).
Sarkar a conseillé aux développeurs et aux organisations d’établir des « micro-périmètres granulaires », de développer des capacités pour contenir la propagation entre les charges de travail et de limiter le rayon d’action des compromissions de la chaîne d’approvisionnement.
Les faux positifs de l’IA font désormais partie du problème de la chaîne d’approvisionnement
Si GlassWorm met en évidence la persistance de véritables campagnes de malwares, l’incident de retrait d’OSV a révélé un problème parallèle affectant la chaîne d’approvisionnement des logiciels open source (OSS). Il s’agit de la fiabilité croissante des rapports de sécurité automatisés.
Le retrait de 157 rapports de logiciels malveillants considérés comme des faux positifs générés par l’IA est important, en particulier lorsqu’il inclut des packages tels que FastAPI v0.136.3. FastAPI est un framework Python largement adopté qui alimente les API de production, les services d’IA et les applications cloud natives dans tous les secteurs. Même quelques jours de faux signalements peuvent entraîner des retards de déploiement coûteux, des perturbations CI/CD et des heures de développement pour isoler des logiciels légitimes.
« Je recommanderais aux entreprises d’être suffisamment préoccupées par les problèmes de rapport signal/bruit pour envisager des mesures correctives, car l’automatisation érode la confiance dans les outils défensifs », a déclaré Sarkar. « À moins que vous ayez une entreprise hautement microsegmentée, le bruit fait perdre du temps aux analystes, ralentit la vitesse et risque de rater des attaques sophistiquées en raison de la fatigue. »
En 2026, avec l’accélération et l’augmentation des faux positifs dans les outils SAST/SCA, avec les logiciels malveillants assistés par l’IA et le reporting, l’automatisation défensive est aggravée de manière asymétrique par le volume de la chaîne d’approvisionnement, a-t-il noté.
Dans un article de blog, Socket a qualifié les mauvais enregistrements OSV de particulièrement dangereux, car la base de données populaire est rapidement transmise aux scanners de dépendances, aux vérifications CI, aux contrôles de registre, aux outils SBOM, aux tableaux de bord et aux systèmes de politique interne.
Tout espoir n’est cependant pas perdu, car les outils les plus récents promettent une moindre dépendance à l’IA pour traquer les vulnérabilités de dépendance. CVE Lite CLI, un scanner léger de vulnérabilités de dépendances JavaScript et TypeScript, offre aux développeurs un moyen de connaître les risques de dépendance pendant qu’ils écrivent encore du code, bien avant l’échec des scanners automatisés dans les pipelines CI.
