Attaques supply chain sur NuGet : une analyse de risque

Quand un développeur tape dotnet add package, il fait confiance à un mainteneur qu'il ne connaît pas, à du code que personne dans l'équipe ne relira, et à un registre qui ne vérifie pas ce qui y est publié. Cette confiance fonctionne dans l'immense majorité des cas, et c'est précisément ce qui la rend exploitable. Les attaques supply chain documentées sur NuGet ne cassent aucun mécanisme de sécurité : elles falsifient les indicateurs sur lesquels cette confiance repose. Cet article propose une analyse de risque de l'utilisation d'un package NuGet, structurée autour de ces indicateurs de confiance et des cas documentés de leur falsification.

Cet article se concentre sur l'analyse de risque et les mécanismes d'attaque documentés sur les packages NuGet. Un second article, évaluer un package NuGet, propose une grille d'évaluation technique d'un package avant son intégration au projet. Un troisième article, en préparation, traitera de la gouvernance des dépendances dans une équipe.

Cadrage : l'objet étudié et la méthode

L'objet étudié est la décision d'utiliser un package NuGet public, et ce qui en dépend. Le cas-type retenu pour concrétiser l'analyse : une équipe .NET qui développe et livre une application métier, consomme ses dépendances depuis nuget.org, et compile sur les postes des développeurs et dans une chaîne d'intégration continue.

La structure suit la logique de la méthode EBIOS Risk Manager de l'ANSSI : identifier ce que l'équipe craint de perdre (les événements redoutés), qui aurait intérêt à provoquer ces pertes (les sources de risque), et par quels chemins concrets (les scénarios). Une attaque supply chain ne vise pas directement l'application : elle vise un composant que l'application intègre, pour que le code adverse soit déployé par le canal de confiance habituel. Le CERT-FR suit ces campagnes au niveau national : la vague npm dite Shai-Hulud de novembre 2025, plus de 700 paquets affectés par auto-réplication, a fait l'objet d'un suivi dédié. La menace n'est pas un sujet de niche.

Ce qui suit n'est pas une analyse EBIOS RM complète, qui partirait des valeurs métier propres à une organisation donnée. C'est une instance générique sur le cas-type, destinée à être adaptée : chaque équipe pondérera les événements redoutés selon son contexte.

Ce qu'une équipe risque concrètement

Un événement redouté, au sens EBIOS, est une atteinte à ce qui a de la valeur pour l'équipe. Chaque événement ci-dessous est adossé à au moins un cas documenté sur NuGet : aucun n'est hypothétique.

La gravité relative de ces événements dépend du contexte : une équipe qui manipule des secrets de production sur les postes de développement n'a pas le même profil qu'une équipe dont la CI est isolée. C'est cette pondération qui relève de l'analyse propre à chaque organisation.

Qui attaque, et pourquoi

Les cas documentés sur NuGet couvrent trois profils de sources de risque, aux objectifs distincts :

1. L'opportuniste à but lucratif immédiat. Cible les secrets monnayables : portefeuilles crypto, tokens d'API de paiement. Les cas Netherеum.All et StripeApi.Net relèvent de ce profil : investissement faible, ciblage large, monétisation directe.
2. Le ciblage sectoriel. Vise un écosystème précis : intégrateurs bancaires brésiliens (Sicoob.Sdk), utilisateurs de bibliothèques d'entreprise chinoises (bmrxntfj), systèmes de contrôle industriel (packages du compte shanhai666). L'investissement est plus élevé, la cible plus étroite, l'objectif potentiellement du renseignement ou du sabotage.
3. Le patient qui construit un capital de confiance. Le profil le plus difficile à détecter : cinq ans d'historique cohérent pour Tracer.Fody.NLog, tentative de captation de réputation à grande échelle en janvier 2026 (détaillée plus bas). L'attaque n'est pas dans le package d'aujourd'hui, elle est dans la position acquise pour demain.

Les scénarios : chaque indicateur de confiance et sa falsification

Le développeur qui choisit un package s'appuie, souvent sans le formuler, sur des indicateurs : un nom reconnu, un volume de téléchargements, un dépôt GitHub, un mainteneur établi. Chaque scénario ci-dessous prend un indicateur et montre, cas documenté à l'appui, comment il a été falsifié. C'est le coeur de l'analyse : le risque ne vient pas d'un défaut des indicateurs, mais de la confiance accordée à des indicateurs falsifiables à faible coût.

Le nom que je lis

L'indicateur : "ce nom est celui du package que je connais". Sa falsification : le typosquatting par variation ASCII, et l'homoglyphe, indétectable visuellement. Le cas Netherеum.All (Socket, octobre 2025) substitue un "е" cyrillique (U+0435) au "e" latin du client Ethereum Nethereum. La falsification par homoglyphe était rendue possible par une caractéristique du registre : nuget.org validait les identifiants avec une expression régulière Unicode-inclusive, visible dans PackageIdValidator.cs, là où npm et PyPI restreignent les noms à l'ASCII. NuGet a annoncé fermer ce vecteur pour les nouveaux packages (voir le traitement du risque) ; les identifiants homoglyphes déjà publiés, eux, restent en place. Le typosquatting par variation ASCII, lui, n'est visé par aucune de ces mesures.

La popularité que je constate

L'indicateur : "des millions de téléchargements, donc une adoption qui vaut validation". Sa falsification : l'inflation par scripting, sans mécanisme côté nuget.org qui l'empêche en pratique. Netherеum.All affichait 11,6 millions de téléchargements générés en quelques jours. La contre-mesure intuitive, regarder la trajectoire plutôt que le volume, est elle-même déjà contournée : le cas StripeApi.Net (ReversingLabs, février 2026) répartit environ 180 000 téléchargements artificiels sur 506 versions, soit près de 300 par version, simulant une progression organique. La falsification s'adapte aux heuristiques de détection à mesure qu'elles se diffusent.

Le dépôt que je vérifie

L'indicateur : "le code est sur GitHub, je peux le lire, l'historique est ancien". Sa falsification prend deux formes. La façade clean-source : le dépôt publié est propre, la charge ne vit que dans la DLL distribuée sur NuGet, que le champ dépôt, déclaratif et non vérifié par nuget.org, ne relie à rien. Le cas Sicoob.Sdk (Socket, mai 2026) exfiltrait des certificats bancaires avec une organisation GitHub créée la veille de la première publication et un compte contributeur créé environ deux minutes avant l'organisation elle-même. La seconde forme : l'antidatage. Les timestamps git sont des données client, acceptées sans validation par les forges ; deux ans d'historique se fabriquent en quelques heures, et le narratif "projet interne rendu public" justifie l'absence de toute trace externe datée.

Le mainteneur en qui j'ai confiance

L'indicateur : "ce publisher est établi, ses packages sont sûrs". C'est l'indicateur le plus précieux, donc le plus attaqué, et sa falsification a une dimension temporelle : l'identité peut être vraie aujourd'hui et compromise demain. Trois variantes documentées ou activement tentées sur NuGet :

• L'imitation d'identité. Le cas Tracer.Fody.NLog (Socket, décembre 2025) typosquatte le nom du publisher plutôt que celui du package, avec cinq ans d'historique patiemment construit et une malveillance logée dans le code compilé uniquement.
• La captation de réputation. En janvier 2026, des milliers de mainteneurs NuGet ont reçu des invitations à devenir co-owners d'un package TestPackage.Security.Research ou à rejoindre une organisation, depuis un compte sans historique. L'objectif documenté par les mainteneurs ciblés, dont Andrew Gubskiy : si un mainteneur connu accepte, le compte attaquant gagne instantanément un statut de confiance, capitalisable plus tard pour distribuer du code malveillant sous couvert de légitimité. L'attaque ne vise pas du code : elle vise le modèle de confiance lui-même.
• La prise de contrôle de compte. Un mainteneur inactif est une cible : l'attaquant qui prend le contrôle du compte publie une version compromise en héritant de toute la confiance accumulée. C'est le vecteur que la 2FA obligatoire, généralisée par nuget.org depuis 2022, vise directement ; les écosystèmes voisins l'ont payé pour l'apprendre (incidents ua-parser-js et event-stream sur npm, documentés dans la taxonomie de menaces du framework S2C2F).

Les analyses qui m'ont précédé

L'indicateur : "ce package existe depuis des mois, les scanners l'auraient signalé". Sa falsification : la rotation de versions. Le compte bmrxntfj (Socket, mai 2026), cinq packages imitant des bibliothèques .NET chinoises, a maintenu 219 des 224 versions publiées non répertoriées, une seule version visible à la fois par package, invalidant les indicateurs de compromission fondés sur les hashes des versions déjà analysées, pour environ 65 000 téléchargements sur au moins sept mois. Le comportement du registre qui rend cette rotation possible : un package non répertorié reste installable par ID et version exacte, un choix conçu pour ne pas casser les builds existants.

Le traitement du risque

Dans une analyse de risque, les scénarios appellent des mesures. Trois niveaux, du registre à l'équipe :

Côté registre

Plusieurs mesures existent et progressent :

• 2FA obligatoire depuis 2022, à 100% d'adoption chez les mainteneurs actifs selon le bilan de sécurité NuGet de juillet 2024. Réduit la prise de contrôle de comptes existants.
• Trusted publishing depuis septembre 2025. Renforce le lien entre le pipeline de build et la publication.
• Restriction ASCII sur les nouveaux identifiants, annoncée en juin 2026 (NuGet/Announcements#75). Aligne nuget.org sur npm et PyPI et ferme le vecteur homoglyphe pour les publications futures. Ne porte pas sur le stock existant, conservé par liste d'exception, et ne touche pas le typosquatting ASCII.

Ces mesures ferment des portes d'entrée, elles ne détectent pas les packages malveillants déjà passés. Le bilan 2024 le reconnaît lui-même : les outils disponibles échouent à détecter les attaques supply chain en cours. La campagne suivie par ReversingLabs, plus de 700 packages malveillants depuis août 2023, s'est déroulée intégralement après la généralisation de la 2FA. Les scanners tiers réduisent la fenêtre d'exposition sans l'annuler : quatre jours pour Netherеum.All, sept mois pour bmrxntfj.

Côté développeur

La mesure est l'évaluation au moment du choix : c'est l'objet de l'article suivant, qui reprend chaque indicateur falsifiable de la présente analyse et lui substitue des signaux plus coûteux à falsifier.

Côté organisation

La structuration de la décision et son suivi dans le temps relèvent de la gouvernance des dépendances. Pour une démarche de maturité complète côté consommation, le framework S2C2F (initié par Microsoft, porté par l'OpenSSF) fournit un modèle en huit pratiques et quatre niveaux, construit sur une taxonomie de menaces recoupant celle de cet article ; le guide d'évaluation OpenSSF en est le pendant concis côté sélection.

Limites

• Cette analyse est générique, pas contextualisée. Une analyse EBIOS RM réelle part des valeurs métier de l'organisation et pondère les événements redoutés en conséquence. Le cas-type retenu ici est un dénominateur commun, pas un substitut à cette pondération.
• Les cas documentés sont ceux qui ont été détectés. Biais de survie inévitable : les attaques réussies non détectées n'apparaissent dans aucun rapport. Le paysage réel est au moins aussi étendu que le paysage documenté.
• Les indicateurs de falsification évoluent. Le cas StripeApi.Net montre une adaptation directe aux heuristiques de détection diffusées publiquement. Chaque cas cité est daté ; les comportements du registre décrits sont ceux constatés au moment de la rédaction.
• L'analyse s'arrête au périmètre NuGet public. Les flux privés et la confusion de dépendances, les compromissions d'outils de build et les attaques sur l'infrastructure de CI sont des scénarios réels, hors du périmètre de ce dossier.

Conclusion

Le résultat central de cette analyse tient en une phrase : chaque indicateur sur lequel repose la confiance instinctive dans un package, le nom, la popularité, le dépôt, le mainteneur, l'ancienneté, a fait l'objet d'une falsification documentée sur NuGet, à un coût faible au regard des événements redoutés. La conséquence n'est pas de renoncer aux packages, mais de remplacer des indicateurs falsifiables par une évaluation dont les signaux sont coûteux à falsifier : c'est l'objet de la suite du dossier.

Cet article décrit des mécanismes d'attaque documentés publiquement, dans l'état constaté à la date de rédaction. Les cas cités renvoient aux rapports d'analyse originaux ; les packages concernés ont été retirés de nuget.org et ne sont plus vérifiables directement.

Ressources

• EBIOS Risk Manager : ANSSI : la méthode d'analyse de risque dont cet article reprend la structure.
• Bulletin d'actualité CERTFR-2025-ACT-051 : CERT-FR : suivi institutionnel français de la campagne npm Shai-Hulud, novembre 2025.
• Malicious NuGet packages typosquat Nethereum : Socket, octobre 2025 : cas Netherеum.All, homoglyphe et inflation des téléchargements.
• Malicious NuGet package targets Stripe : ReversingLabs, février 2026 : cas StripeApi.Net, inflation répartie sur 506 versions.
• Malicious NuGet package impersonates Sicoob SDK : Socket, mai 2026 : cas Sicoob.Sdk, façade clean-source et exfiltration de certificats.
• Malicious NuGet package typosquats popular .NET tracing library : Socket, décembre 2025 : cas Tracer.Fody.NLog, imitation de publisher sur cinq ans.
• 5 malicious NuGet packages impersonate Chinese UI libraries : Socket, mai 2026 : cas bmrxntfj, rotation de versions non répertoriées.
• 9 Malicious NuGet Packages Deliver Time-Delayed Destructive Payloads : Socket, novembre 2025 : compte shanhai666, neuf packages malveillants à déclencheurs échelonnés (sabotage de bases de données programmé pour 2027-2028, sabotage immédiat pour le typosquat Siemens S7 Sharp7Extend).
• Fil d'alerte d'Andrew Gubskiy : Bluesky, janvier 2026 [archivé] : documentation primaire de la tentative de captation de réputation TestPackage.Security.Research, par un des mainteneurs ciblés.
• Building a Safer Future : Microsoft, juillet 2024 : bilan des initiatives de sécurité NuGet, 2FA obligatoire, limites des outils.
• Malicious NuGet campaign uses homoglyphs and IL weaving : ReversingLabs, juillet 2024 : campagne active depuis août 2023, plus de 700 packages sur sa première phase.
• PackageIdValidator.cs : dépôt NuGet.Client : règle de validation des identifiants, expression régulière Unicode-inclusive.
• Secure Supply Chain Consumption Framework (S2C2F) : OpenSSF : framework de consommation sécurisée en huit pratiques et quatre niveaux de maturité, avec taxonomie de menaces sourcée.
• Concise Guide for Evaluating Open Source Software : OpenSSF : grille d'évaluation concise, convergente avec l'article 2 du dossier.