Comment les attaquants ont retourné le système de confiance du NPM contre lui

le processus de vérification sigstore de npm a été contourné

L’automatisation en matière de sécurité est puissante, mais elle n’est pas infaillible. Le 19 mai, des attaquants ont pénétré le système de confiance de npm en utilisant un compte de mainteneur compromis pour générer des certificats de signature valides. Le système a tout vérifié, la construction du code, le certificat de signature, l’enregistrement de la provenance. Malheureusement, il n’a pas pu vérifier l’intention. Au total, 633 versions de paquets malveillants ont passé la vérification et sont entrées dans la chaîne d’approvisionnement, bénéficiant de la confiance totale des développeurs et des systèmes qui s’appuient sur le badge vert de Sigstore.

Il ne s’agissait pas d’un bogue logiciel, mais d’un défaut de conception. Sigstore a fait son travail, mais il lui manquait ce que l’on pourrait appeler la connaissance de la situation : il a vérifié le paquet, mais pas l’identité qui se cachait derrière. Le modèle de confiance supposait qu’un certificat valide équivalait à un auteur légitime, ce qui n’est plus suffisant à l’ère du vol d’identité.

Les dirigeants doivent comprendre ce qu’il faut retenir : l’automatisation ne peut pas remplacer la vérification humaine sans des mesures de protection de l’identité plus approfondies. Les systèmes doivent évoluer pour vérifier l’autorisation, et pas seulement la cryptographie. Il ne s’agit plus de prouver une signature, mais de prouver que la bonne personne a réellement approuvé l’action. Dans la chaîne d’approvisionnement moderne des développeurs, où les attaquants peuvent générer des identifiants légitimes à partir de jetons volés, la vérification doit passer des contrôles statiques à la validation comportementale et contextuelle.

Selon Endor Labs et Socket, cette campagne a finalement impliqué plus de 1 055 versions malveillantes dans 502 paquets distribués par npm, PyPI et Composer. Le problème s’étend aux écosystèmes, et non à une seule plateforme. Si votre entreprise dépend de composants open-source, elle dépend d’un modèle de confiance fragile qui a besoin d’être renforcé de toute urgence.

Des informations d’identification volées dans des outils de développement ont permis de compromettre la chaîne d’approvisionnement à grande échelle

Le vol d’informations d’identification devient le moyen le plus rapide d’entrer dans la chaîne d’approvisionnement des logiciels. StepSecurity a signalé que des attaquants ont publié une mise à jour malveillante de l’extension Nx Console pour Visual Studio Code, utilisée par des millions de développeurs dans le monde. La version compromise a permis de recueillir des informations sensibles, notamment des jetons GitHub, des clés AWS et même des données de coffre-fort 1Password. Elle a été active pendant moins d’une heure, mais a tout de même atteint près de 6 000 installations grâce à sa fonction de mise à jour automatique.

C’est un rappel brutal que les attaques réelles n’ont plus besoin d’une exposition prolongée. La vitesse et l’automatisation des outils de développement amplifient tout, les succès comme les échecs. Dès qu’une mise à jour est mise en ligne, les mécanismes de mise à jour automatique peuvent distribuer le code compromis avant toute détection humaine. La campagne Mini Shai-Hulud a poussé ce phénomène encore plus loin en relançant des paquets npm dormants depuis longtemps, qui semblaient être des mises à jour normales. De nombreux systèmes de détection ont manqué ces changements simplement parce qu’ils n’ont pas été conçus pour s’interroger sur les raisons pour lesquelles un paquet silencieux depuis des années est soudainement revenu à la vie.

Pour les dirigeants, il s’agit d’une question stratégique. Vous ne pouvez plus vous fier uniquement aux garanties de sécurité fournies par les fournisseurs ou aux processus de validation du marché. La surface d’attaque commence bien avant qu’un produit n’entre en production, elle commence dans l’environnement du développeur, dans le pipeline CI/CD et dans chaque échange automatique qui vérifie le logiciel sans examen humain.

L’analyse de StepSecurity montre comment les attaquants exploitent l’automatisation elle-même. La vitesse, qui était autrefois l’avantage concurrentiel du développement de logiciels, est devenue une arme dans leur boîte à outils. Pour garder une longueur d’avance, les entreprises doivent équilibrer le développement rapide avec des contrôles d’identité solides, des politiques d’extension strictes et des mécanismes de réponse immédiate. La vitesse est toujours importante, mais la vitesse contrôlée l’est encore plus.

Des défaillances systémiques dans la vérification des outils de développement mises en évidence par plusieurs équipes de recherche

Les récentes enquêtes menées dans l’ensemble de l’écosystème logiciel ont mis en évidence une chose : les cadres de vérification sont défaillants à grande échelle. Les recherches menées par Endor Labs, Socket, StepSecurity, Adversa AI, l’université Johns Hopkins, le CSEM de Microsoft et LayerX ont mis en évidence des faiblesses dans sept couches distinctes de la chaîne d’outils du développeur. Leurs conclusions ont révélé des défaillances dans la vérification de la provenance, la protection des références d’extension, l’intégrité du pipeline CI/CD, les cadres d’agents et même les pratiques de stockage de l’environnement de développement intégré (IDE).

Chaque découverte a été faite indépendamment, mais toutes ont mis en évidence la même faiblesse, à savoir des systèmes de confiance qui fonctionnent de manière isolée. Les outils vérifient ce qu’ils sont censés voir, mais aucun n’a de visibilité sur tous les points de défaillance. Cette conception fragmentée conduit à une fausse confiance. Un développeur ou une entreprise peut supposer que le fait de voir un badge « vérifié » ou de passer une analyse de vulnérabilité signifie que le système est sûr. En réalité, aucun cadre ne dispose d’une vue d’ensemble et les attaquants exploitent ce manque de cohésion.

Les dirigeants devraient considérer qu’il s’agit d’un signal d’alarme pour la gouvernance et la stratégie de vérification interne. La pratique traditionnelle consistant à s’appuyer entièrement sur les assurances du fournisseur ou sur des audits discrets est insuffisante. Les performances en matière de sécurité doivent être mesurées à chaque étape du processus de création et de déploiement. Les organisations ont besoin d’un audit continu et holistique, avec une responsabilité répartie entre les fournisseurs et les équipes de sécurité internes.

Les chercheurs Aonan Guan, Zhengyu Liu et Gavin Zhong de l’université Johns Hopkins ont montré comment une petite faille de processus négligée dans les flux de travail automatisés pouvait exposer les clés d’API par le biais d’interactions avec des outils d’IA. Leurs travaux, ainsi que ceux d’équipes de recherche commerciale, montrent comment les universités et l’industrie peuvent mettre à jour les risques systémiques, mais aussi comment la vérification fragmentée rend les entreprises vulnérables à l’exploitation multi-surface.

Le message sous-jacent est direct : la conformité technique n’est pas la même chose que la sécurité opérationnelle. Pour les dirigeants d’entreprise, renforcer les modèles de vérification signifie investir dans des intégrations qui révèlent les angles morts entre les systèmes des fournisseurs. Il ne s’agit pas d’acquérir de nouveaux outils de sécurité, mais de renforcer la visibilité entre les systèmes et d’éliminer l’hypothèse selon laquelle une seule couche de défense suffit.

Les outils de codage de l’IA utilisés par les développeurs présentent des vulnérabilités critiques en matière de confiance et d’exécution

Les outils de codage basés sur l’IA ont révolutionné la création de logiciels, mais ils ont également introduit de nouvelles catégories de vulnérabilités. Des recherches menées par Adversa AI, l’université Johns Hopkins, le CSEM de Microsoft et LayerX ont révélé que ces outils, bien qu’intelligents, fonctionnent souvent sur des architectures de confiance non sécurisées. Le rapport TrustFall d’Adversa AI a montré que des assistants de développement populaires tels que Claude Code, Gemini CLI, Cursor CLI et Copilot CLI exécutent automatiquement des serveurs MCP définis par le projet dès qu’un développeur accepte une demande de confiance pour un dossier. Dans la quasi-totalité des cas, la valeur par défaut de ces invites est « Trust », ce qui confère silencieusement tous les privilèges du système à un code non validé.

En outre, les chercheurs de Johns Hopkins ont découvert qu’une seule instruction malveillante intégrée dans le titre d’une demande d’extraction GitHub pouvait déclencher la fuite publique de la clé API d’un agent d’examen de code d’IA, une exposition notée 9,4 Critical sur l’échelle CVSS par le programme HackerOne d’Anthropic. Les révélations du CSEM de Microsoft ont renforcé l’urgence en confirmant deux failles critiques dans le cadre du Semantic Kernel : l’une permettant l’exécution de code arbitraire à partir d’entrées de données manipulées, et l’autre exposant les fonctions de téléchargement de fichiers sur la machine hôte. Ces découvertes n’étaient pas théoriques, elles ont prouvé que les vulnérabilités des outils de développement de l’IA peuvent directement compromettre l’infrastructure d’une entreprise.

Pour les dirigeants, cela signifie que les avantages de l’automatisation de l’IA en termes de productivité doivent être mis en balance avec les risques opérationnels de l’automatisation sans supervision. Les systèmes d’IA exécutent des commandes sans contexte humain. Si les invites de confiance sont par défaut des approbations, ou si l’ingestion de données n’est pas étroitement contrôlée, les mêmes systèmes conçus pour accélérer la livraison de code peuvent exécuter des commandes hostiles instantanément.

Les dirigeants doivent pousser leurs organisations à adopter le consentement explicite et des modèles de privilèges minimaux pour tous les outils assistés par l’IA. La surveillance comportementale doit devenir la norme, afin de comprendre ce que ces systèmes exécutent, et pas seulement ce qu’ils génèrent. Chaque niveau de la pile d’outils de codage de l’IA, des SDK aux intégrations CI/CD, a besoin d’une gouvernance granulaire qui garantit qu’aucun processus ne peut agir au-delà de son champ d’autorisation.

L’adoption rapide d’outils d’IA dans le codage se poursuivra. La priorité essentielle est de remanier leurs défauts de confiance et leurs couches de vérification avant que les attaquants n’industrialisent leur exploitation. Les outils de codage modernes de l’IA ne sont plus des assistants passifs, mais des agents actifs dotés de droits d’exécution. Le modèle de sécurité doit évoluer pour s’adapter à cette puissance.

Les opérations de ciblage des données d’identification s’accélèrent dans le contexte des tendances d’exposition à l’IA

L’augmentation mondiale des vols d’informations d’identification n’est pas fortuite, elle est systématique. Les groupes de menaces s’adaptent rapidement à la façon dont les organisations utilisent les outils d’IA et les plateformes cloud, transformant ces mêmes outils en nouveaux points d’entrée. Selon le rapport Verizon 2026 Data Breach Investigations Report, 67 % des employés accèdent à des services d’IA à partir de comptes personnels, non professionnels, alors qu’ils utilisent des appareils professionnels. Cette pratique, souvent appelée « shadow AI », reflète la façon dont l’adoption de l’IA a dépassé la gouvernance. Les développeurs partagent des données confidentielles et des codes sources avec des modèles d’IA fonctionnant en dehors des cadres de contrôle de l’entreprise. Ces informations d’identification et ces référentiels sont désormais des cibles de choix pour les attaquants.

Le rapport 2026 Financial Services Threat Landscape Report de CrowdStrike ajoute plus de contexte. Le groupe STARDUST CHOLLIMA a triplé son rythme opérationnel contre les organisations financières à la fin de l’année 2025. Il a utilisé des profils de recruteurs générés par l’IA, de faux entretiens et des défis de codage malveillants pour récolter des tokens et des clés d’accès. Ces campagnes n’étaient pas aléatoires ; il s’agissait d’attaques calculées axées sur les environnements de développement, où sont stockés des secrets tels que les PAT GitHub, les jetons npm, les clés d’accès AWS et les informations d’identification CI/CD.

Pour les dirigeants, il s’agit là d’un changement clair dans la manière dont le vol d’informations d’identification est exécuté et étendu. Les attaquants ne se contentent plus de violer l’infrastructure de l’entreprise, ils ciblent les développeurs et les ingénieurs individuels qui détiennent les clés de confiance des systèmes de production. La responsabilité de la protection des informations d’identification doit donc s’étendre au-delà de la sécurité informatique et inclure la gouvernance du comportement des employés, l’utilisation des outils d’intelligence artificielle et les politiques de partage des données.

La prévention de l’exposition nécessite une visibilité axée sur la technologie et une discipline du personnel. Les entreprises doivent surveiller où et comment les employés se connectent aux services d’IA, appliquer des contrôles stricts sur le traitement des données et s’assurer que les informations d’identification ne quittent jamais les environnements sécurisés et gérés par l’entreprise. L’IA fantôme ne peut plus être considérée comme une expérimentation inoffensive. Elle est désormais l’un des principaux vecteurs de compromission d’identité de haut niveau et d’infiltration indirecte de la chaîne d’approvisionnement. La résilience de l’entreprise dépend de sa prise en charge systématique et immédiate.

Les équipes chargées de la gouvernance et de l’approvisionnement doivent réévaluer les cadres de confiance dans les environnements de développement.

En réponse à ces défaillances, les organisations doivent revoir la manière dont elles évaluent les fournisseurs de technologie et passent des contrats avec eux. Les brèches dans npm, VS Code et les outils de codage d’IA révèlent une faiblesse fondamentale dans les modèles de confiance qui sous-tendent les décisions d’achat. La plupart des organisations partent du principe que la certification ou la signature d’un fournisseur est une preuve suffisante de sécurité. La récente série de versions compromises montre que les signaux de confiance, tels que les attestations signées ou les badges d’automatisation des fournisseurs, peuvent être falsifiés ou utilisés à mauvais escient lorsque les informations d’identification sont volées.

Les responsables de la sécurité devraient revoir la gestion des fournisseurs avec de nouveaux critères centrés sur la « résistance aux identités volées ». Un fournisseur fiable devrait être en mesure de démontrer non seulement que ses progiciels sont cryptographiquement valides, mais aussi que son identité de publication ne peut pas être usurpée par le biais de jetons ou de comptes CI/CD compromis. Les équipes d’achat et d’audit doivent donc demander des preuves des contrôles d’autorisation, du suivi de la provenance des builds et des protocoles de récupération pour les mainteneurs compromis avant de renouveler ou d’acheter de nouveaux outils.

La grille d’audit des outils de développement en cas d’usurpation d’identité, décrite dans une étude récente, fournit un cadre à cet effet. Elle explique comment la pile de chaque fournisseur a échoué, quelles méthodes de vérification ont échoué et où s’arrête la visibilité de l’entreprise. La réduction des risques la plus efficace ne provient pas d’une nouvelle liste d’outils, mais de conversations structurées et transparentes entre les équipes de sécurité des entreprises et les fournisseurs lors des renouvellements de contrats. Chaque non-réponse sur la couverture ou la responsabilité lors de ces discussions définit la frontière de sécurité la plus faible de votre organisation.

Les dirigeants devraient demander à leurs équipes d’intégrer ces discussions dans les cycles d’approvisionnement dès maintenant, et non pas après une nouvelle violation. Tout système ou fournisseur qui ne peut prouver l’intégrité de l’identité doit être considéré comme une solution temporaire jusqu’à ce que des méthodes de vérification plus robustes soient mises en œuvre. L’avenir de la sécurité des logiciels d’entreprise dépendra de l’établissement de partenariats contractuels et opérationnels qui rendent la vérification de l’identité et la validation des intentions non négociables.

La confiance dans l’automatisation doit évoluer vers une assurance mesurable. La gouvernance et l’approvisionnement sont les leviers organisationnels qui peuvent rendre cette évolution réelle.

Les mesures d’atténuation recommandées mettent l’accent sur la vérification par couches, la surveillance du comportement et le renforcement des politiques.

La sécurisation de la chaîne d’approvisionnement en logiciels nécessite désormais une action coordonnée et à plusieurs niveaux. Les recherches montrent qu’aucun système de contrôle ou de vérification ne peut à lui seul assurer une protection totale contre l’usurpation d’identité ou le vol automatisé de données d’identification. La priorité pour les dirigeants est de mettre en place une structure où se superposent plusieurs couches de vérification, techniques, procédurales et comportementales. Cela permet de s’assurer qu’aucune ligne de défense ne fonctionne de manière isolée.

La grille d’audit de l’outil Developer Stolen-Identity présente des mesures pratiques que les dirigeants peuvent mettre en œuvre dès aujourd’hui. Les paquets npm à fort impact doivent être approuvés par deux parties avant d’être publiés, en particulier ceux qui dépassent 10 000 téléchargements hebdomadaires. Les outils de développement essentiels, tels que les extensions VS Code, doivent faire l’objet d’un épinglage de version et de politiques d’âge minimum qui réduisent l’exposition aux mises à jour compromises. Dans les outils de développement basés sur l’IA, les privilèges d’exécution automatique, tels que les serveurs MCP de confiance automatique, doivent être désactivés à moins d’être explicitement autorisés à l’avance.

Pour les environnements déjà exposés, les pipelines CI/CD doivent être mis à jour avec les derniers SDK sécurisés. Le CSEM de Microsoft, par exemple, recommande de mettre à jour le Semantic Kernel Python SDK à la version 1.39.4 et le .NET SDK à la version 1.71.0 afin de combler les récentes vulnérabilités d’exécution. Les postes de travail de développement nécessitent également une discipline plus stricte en matière de stockage des informations d’identification, en mettant en œuvre le cryptage et les trousseaux de clés au niveau du système d’exploitation pour protéger les jetons d’accès, les clés d’API et les informations d’identification de session au repos. Sur le réseau de l’entreprise, la mise en œuvre d’une gouvernance de l’IA au niveau du navigateur permettra aux organisations de surveiller et de restreindre l’utilisation de l’IA en dehors de l’entreprise qui pourrait entraîner des fuites de données propriétaires.

Les dirigeants devraient considérer ces mesures comme des contrôles essentiels, et non comme des mises à niveau facultatives. Chaque étape ajoute un point de contrôle vérifiable, qu’il s’agisse d’une approbation humaine, d’une automatisation en bac à sable ou d’une inspection environnementale. En termes pratiques, la vérification par couches consiste à réduire le nombre de chemins qu’un pirate peut exploiter avec un seul ensemble d’informations d’identification volées. Le coût opérationnel de la mise en œuvre de ces politiques est nettement inférieur au coût du rétablissement de la confiance ou de l’intégrité de la source après la compromission de la chaîne d’approvisionnement.

La surveillance comportementale doit devenir une pratique courante, et non une simple alerte classée dans un tableau de bord. Les équipes de sécurité doivent suivre le comportement des outils, et pas seulement vérifier s’ils passent les analyses. Si un processus interagit avec des systèmes en dehors de son champ d’application défini, il doit déclencher une enquête immédiate. Combiné à une application plus stricte des politiques, cela permet d’établir un environnement de sécurité vivant qui s’adapte en temps réel aux abus d’identité et aux menaces basées sur l’automatisation.

L’avantage commercial d’une sécurité multicouche et comportementale est la stabilité à long terme. En allant au-delà de la conformité statique et en intégrant une surveillance dynamique dans les opérations quotidiennes, les organisations évoluent vers des performances prévisibles en matière de défense. L’objectif n’est pas de ralentir l’innovation, mais de rendre les progrès durables. La sécurité n’a de valeur que si elle s’adapte à la vitesse et à l’ambition de l’entreprise. Grâce à ces mesures stratifiées, les dirigeants peuvent maintenir les deux.

Le bilan

Les systèmes de confiance qui régissent l’économie logicielle d’aujourd’hui atteignent leurs limites. Les signatures numériques, les certificats et l’automatisation garantissaient autrefois l’intégrité. Aujourd’hui, ils sont manipulés avec précision. Chaque violation décrite ici, de la fausse provenance de npm aux fuites d’informations d’identification des outils d’IA, met en évidence une vérité universelle : la vérification de l’identité ne suffit plus à elle seule.

Pour les chefs d’entreprise, il ne s’agit pas d’une question de compétence technique, mais de continuité opérationnelle et de confiance dans la marque. Les attaquants ont appris à opérer à l’intérieur de processus légitimes, en utilisant des identifiants volés et des flux de travail automatisés pour ne pas se distinguer des vrais développeurs. Cela signifie que chaque entreprise qui s’appuie sur des chaînes d’approvisionnement numériques, des services cloud ou des intégrations d’IA est exposée à moins que l’identité, l’autorisation et le comportement ne soient validés ensemble.

Le moment est venu de passer de la conformité conventionnelle à la vérification proactive. Appuyez-vous sur des approbations multipartites, des audits comportementaux continus et une responsabilité des fournisseurs qui va au-delà d’un scan réussi ou d’un certificat signé. La sécurité n’est pas un investissement statique, c’est une capacité continue.

Les entreprises qui agissent maintenant définiront la prochaine norme en matière d’intégrité numérique. Celles qui tardent hériteront du risque lié aux systèmes de confiance conçus pour une ère antérieure plus simple. La technologie est prête pour le changement ; le leadership doit l’être aussi.