Attaques supply chain : quatre cas réels, et le code tiers de 636
sites mesuré

Vous n'avez pas été piraté. Votre code est propre, vos serveurs sont à jour, votre mot de passe fait quarante caractères. Et pourtant, un matin, les portefeuilles Bitcoin de vos utilisateurs se vident. Le coupable n'est pas chez vous : c'est une brique open source, cinq niveaux plus bas dans votre arbre de dépendances, qu'un inconnu a récupérée puis piégée. Vous ne l'avez jamais installée volontairement. Elle est arrivée en passager clandestin, tirée par une autre bibliothèque que vous, si. Voilà une attaque supply chain : on ne vous vise pas, on vise ce à quoi vous faites confiance.

Le terme est à la mode, mais l'idée est vieille comme le commerce : pour atteindre une forteresse bien gardée, on empoisonne ce qu'elle importe. Appliqué au logiciel, ça donne la compromission de la chaîne d'approvisionnement logicielle, un angle mort, parce que le code moderne n'est plus écrit, il est assemblé. Un projet web banal embarque des centaines de dépendances qu'aucun humain n'a lues. Cet article couvre ce qu'est une supply chain attack, quatre cas réels et datés, les vecteurs d'entrée, ce que valent le SBOM et la SCA, et comment repérer une compromission depuis l'extérieur, là où vos utilisateurs la subissent.

Une attaque supply chain, c'est quoi exactement ?

Une attaque de la chaîne d'approvisionnement logicielle consiste à compromettre un maillon en amont, une dépendance, un outil de build, un fournisseur, un script hébergé ailleurs, pour atteindre, par ricochet, tous ceux qui l'utilisent en aval. L'attaquant ne force pas votre porte : il empoisonne quelque chose que vous allez inviter chez vous de votre plein gré, généralement lors d'un npm install, d'un pip install, d'une mise à jour automatique ou d'un <script src> pointant vers un CDN.

Le calcul de l'attaquant est économique : pourquoi attaquer mille entreprises une par une quand on peut compromettre une bibliothèque que ces mille entreprises importent ? Le rapport effort/portée est imbattable. C'est ce qui explique l'explosion de ces attaques : elles frappent en amont, à l'endroit où la confiance est implicite et la surveillance faible.

La confiance transitive, justement, est le cœur du problème. Vous faites confiance à la bibliothèque A. La bibliothèque A fait confiance à B. B tire C, qui tire D. Vous n'avez jamais entendu parler de D, son mainteneur est un pseudonyme, son dernier commit date de 2019, et pourtant son code s'exécute avec les mêmes droits que le vôtre. Multipliez par les centaines de nœuds d'un node_modules typique, et vous obtenez une surface de confiance que personne ne maîtrise.

Quatre attaques supply chain réelles, pour comprendre

Voici quatre cas documentés, choisis parce qu'ils illustrent chacun un vecteur différent : une dépendance npm, un pipeline de build, la confiance humaine dans un mainteneur, et un script tiers chargé dans le navigateur. Ce sont les quatre grandes portes d'entrée.

2018, event-stream : la dépendance npm offerte puis piégée

event-stream était un paquet npm des plus anodins pour manipuler des flux de données, avec près de deux millions de téléchargements par semaine. Son auteur, Dominic Tarr (@dominictarr), ne s'en servait plus et l'avait laissé dormir. En septembre 2018, un contributeur au pseudonyme @right9ctrl propose gentiment de reprendre la maintenance. Tarr accepte et lui donne les clés, sur GitHub comme sur npm.

Le nouveau mainteneur ajoute une dépendance, flatmap-stream, dont la version 0.1.1 embarque, uniquement dans sa version minifiée, du code malveillant chiffré. Ce code ne se déclenche que dans un contexte très précis : le processus de build de copay, un portefeuille Bitcoin qui comptait event-stream parmi ses dépendances. La charge utilise la description du paquet parent comme clé de déchiffrement AES : partout ailleurs, elle produit du charabia et se tait ; chez la cible, elle déchiffre un voleur de clés de portefeuille. Une attaque chirurgicale, invisible pour l'immense majorité des installations, découverte presque par hasard par un développeur intrigué par un avertissement de build.

2020, SolarWinds / SUNBURST : le pipeline de build empoisonné

Ici, on change d'échelle. SolarWinds édite Orion, une plateforme de supervision réseau déployée dans des dizaines de milliers d'organisations, dont des agences fédérales américaines. Des attaquants, attribués à un groupe étatique, ne piègent pas une dépendance : ils s'infiltrent dans l'environnement de build de SolarWinds lui-même. Le premier update Orion vérolé est signé le 24 mars 2020 et distribué à partir du 26 mars, à travers le canal de mise à jour officiel, dûment signé numériquement.

La porte dérobée, baptisée SUNBURST, était intégrée à un binaire légitimement signé par SolarWinds. Aucune vérification de signature ne pouvait la détecter, puisqu'elle venait de la chaîne officielle. Jusqu'à 18 000 organisations ont téléchargé la mise à jour piégée ; une centaine, triées sur le volet, ont fait l'objet d'une intrusion approfondie. L'affaire n'a éclaté qu'en décembre 2020, quand l'éditeur de sécurité FireEye a découvert avoir été lui-même compromis par ce biais.

2024, xz-utils / CVE-2024-3094 : deux ans de patience pour une backdoor

Le cas xz-utils est le plus vertigineux, parce qu'il attaque la ressource la plus précieuse de l'open source : la confiance humaine. liblzma, la bibliothèque de compression fournie par xz-utils, est présente dans quasiment toutes les distributions Linux, et liée à des composants aussi sensibles que le démon SSH. Un contributeur signant "Jia Tan" (JiaT75) s'investit pendant près de deux ans dans le projet, gagne la confiance du mainteneur épuisé, obtient les droits de publication, puis glisse une porte dérobée dans les tarballs de release des versions 5.6.0 (février 2024) et 5.6.1.

La backdoor, dissimulée dans des fichiers de test binaires et reconstruite à la volée pendant le build, modifiait liblzma pour détourner l'authentification de sshd : quiconque possédait la bonne clé privée pouvait exécuter du code à distance, en root, sur des millions de machines. Score CVSS : 10.0, le maximum que la formule du score CVSS autorise, comme le référence la fiche CVE-2024-3094 du NVD. Elle n'a été découverte que grâce à un développeur Microsoft, Andres Freund, intrigué par… quelques centaines de millisecondes de latence anormale sur des connexions SSH. Divulgation le 29 mars 2024, juste avant que les versions piégées n'atteignent les distributions stables.

2024, polyfill.io : le script tiers qui trahit dans le navigateur

Les trois premiers cas frappaient au build ou au serveur. Celui-ci frappe dans le navigateur de vos visiteurs, et c'est pour ça qu'il nous intéresse particulièrement. polyfill.io était un service très répandu qui servait, depuis son CDN, de petits bouts de JavaScript pour faire fonctionner les sites modernes sur les vieux navigateurs. Plus de 100 000 sites chargeaient un <script> pointant vers cdn.polyfill.io.

En février 2024, le domaine et le dépôt GitHub passent sous le contrôle d'une société chinoise, Funnull. L'auteur original, Andrew Betts, exhorte publiquement tout le monde à retirer le script au plus vite. Il avait raison : le CDN se met à injecter du code malveillant, qui redirige les utilisateurs mobiles vers des sites d'arnaque et de paris, avec des techniques d'évasion soignées (il évite les administrateurs, se tait si un outil d'analyse est présent, ne se déclenche qu'à certaines heures sur certains appareils). L'éditeur Sansec sonne l'alerte le 25 juin 2024 ; le registrar Namecheap finit par neutraliser le domaine. La plupart des sites touchés n'avaient rien changé chez eux. Ils avaient juste laissé, des années plus tôt, une balise <script> vers un domaine tiers, et ce domaine a changé de camp.

Les vecteurs : par où entre une attaque supply chain

Nos quatre cas dessinent la carte. Une chaîne d'approvisionnement logicielle s'attaque à plusieurs étages, du code source que vous importez jusqu'au JavaScript qui s'exécute chez vos visiteurs. Voici les étages, du plus profond au plus visible.

Les dépendances open source. C'est le vecteur le plus courant, et de loin. Plusieurs techniques cohabitent : la prise de contrôle d'un paquet abandonné (event-stream), le vol du jeton de publication d'un mainteneur (par hameçonnage, comme chalk et debug), la publication d'une version malveillante par un mainteneur devenu hostile, et surtout le typosquatting, publier reqeusts ou loadash en pariant sur vos fautes de frappe. On a consacré un article entier à ce dernier : comment fonctionne le typosquatting de paquets et de domaines et comment le détecter.

La confusion de dépendances (dependency confusion). Une variante redoutable : si votre build cherche un paquet interne @masociete/utils et qu'un homonyme public du même nom existe sur npm avec un numéro de version plus élevé, votre gestionnaire de paquets peut aller chercher le public. L'attaquant n'a qu'à deviner le nom de vos paquets privés, souvent lisibles dans un vieux package.json qui a fuité, pour faire exécuter son code au cœur de votre CI.

Le pipeline CI/CD. Votre système de build est votre joyau : il a accès au code, aux secrets, aux clés de signature, et son résultat est déployé partout, avec confiance. Le compromettre (via une action GitHub tierce non épinglée, un runner mal isolé, un secret exfiltré) revient à signer soi-même le malware, comme dans SolarWinds. Un cousin fréquent : le vibe coding et les dépendances hallucinées, un sujet qu'on creuse dans sécurité du code généré par IA.

Les scripts tiers côté navigateur. Le vecteur le plus sous-estimé, parce qu'il ne laisse aucune trace dans votre dépôt. Chaque <script src> vers un tag manager, un outil d'analytics, un chatbot, une régie publicitaire ou un CDN est une délégation de confiance à un tiers, qui s'exécute avec les pleins pouvoirs sur vos pages. Si ce tiers est compromis, ou racheté par un acteur hostile, c'est polyfill.io. Ce vecteur-là ne se voit pas depuis le code : il faut regarder ce qui se charge réellement dans le navigateur.

La mesure : le code tiers de 636 pages d'accueil

On parle beaucoup des scripts tiers sans les compter. Le 6 octobre 2026, on a relevé une fois la page d'accueil de 704 organisations : les entreprises du SBF 120, 65 universités, 488 communes de plus de 20 000 habitants et 32 CHU ou CHR. Une visite chacune, puis une analyse hors ligne du HTML de 636 pages exploitables. Seul le HTML statique est lu : les scripts qu'un gestionnaire de balises injecte ensuite ne sont pas vus, et aucun fichier JavaScript n'a été téléchargé. Tous les chiffres ci-dessous sont donc des minorants.

La délégation de confiance est massive et rarement verrouillée. 397 pages sur 636 exécutent du code servi par un autre domaine que le leur, le plus souvent un CDN public de bibliothèques (cdnjs sur 86 pages, jsDelivr sur 56, unpkg sur 24, code.jquery.com sur 23) ou un service Google. Sur 1 177 balises de script tiers, 39 seulement portent un attribut integrity. On ne peut pas reprocher son absence à un gestionnaire de balises ou à un widget dont le contenu change par nature. Mais sur les 160 pages qui chargent une bibliothèque à version exacte depuis un CDN public, cas d'école où SRI ne coûte qu'une ligne, 153 le font au moins une fois sans.

Deux traces montrent ce que devient un script tiers qu'on ne relit plus. Une page du panel porte encore une balise vers un hôte de la famille polyfill.io, plus de deux ans après l'affaire. Et 93 pages portent un marqueur de Google Analytics Universal, service qui ne traite plus aucune donnée depuis le 1er juillet 2023 (le 1er juillet 2024 pour la version 360) ; 29 d'entre elles chargent toujours la bibliothèque analytics.js ou ga.js elle-même. Du code qui ne sert plus à rien, servi par un tiers, et exécuté avec les pleins pouvoirs sur la page.

Des bibliothèques connues pour être vulnérables, à découvert

Quand l'URL ou le nom du fichier trahit la version d'une bibliothèque, on peut la confronter à la base de retire.js. C'est le cas sur 163 pages, et 92 d'entre elles (56,4 %) embarquent au moins une version dans une plage vulnérable connue, soit 14,5 % des 636 pages. La gravité maximale par page est moyenne pour 80 d'entre elles, haute pour 11, critique pour 1. jQuery écrase tout : 75 pages vulnérables sur 138 où sa version se lit, la 3.3.1 à elle seule sur 23 pages.

Par panel, les pages concernées sont 7 sur 96 au SBF 120, 11 sur 56 dans les universités, 70 sur 454 dans les communes et 4 sur 30 dans les CHU. "Vulnérable" veut dire ici "dans une plage de versions qui a reçu un avis", pas "exploitable sur cette page" : une vieille jQuery n'est dangereuse que si le site lui passe des données contrôlées par un visiteur. C'est en revanche un excellent indicateur de dépendance que personne ne met à jour, et c'est ce genre de maillon qu'un attaquant supply chain cherche : un composant tiers, figé, que plus personne ne regarde.

SBOM et SCA : la défense classique, et sa frontière

Face à cette prolifération, deux outils sont devenus la réponse standard. Ils sont indispensables, mais il faut comprendre où s'arrête leur portée.

Le SBOM (Software Bill of Materials, nomenclature logicielle) est l'inventaire exhaustif des composants qui entrent dans votre logiciel : chaque dépendance, sa version, sa licence, son origine. Les formats standards sont CycloneDX et SPDX ; on détaille leur génération, leurs formats et leurs limites dans notre article dédié au SBOM (software bill of materials), et on montre ce que remontent concrètement OWASP Dependency-Check et npm audit sur de vrais projets. Un SBOM répond à une question simple : "quand la prochaine faille du type xz-utils tombe, suis-je concerné, et où ?". Sans lui, vous passez des jours à fouiller vos projets à la main. Les réglementations récentes, NIS2 et DORA en tête, poussent d'ailleurs à formaliser cette gestion des risques liés aux fournisseurs, un point qu'on développe dans notre pilier sur la directive NIS2. Côté fournisseurs humains plutôt que logiciels, l'instrument standard de cette formalisation est le questionnaire de sécurité fournisseur, avec la même limite que le SBOM : il inventorie ce qu'on lui déclare.

La SCA (Software Composition Analysis, analyse de composition logicielle) exploite ce SBOM : elle confronte votre liste de dépendances aux bases de vulnérabilités connues et vous alerte quand une version embarquée est concernée par une CVE. C'est le prolongement naturel du SBOM, et l'un des maillons d'une chaîne d'outils qu'on compare dans SAST, DAST et IAST. Notre propre module d' analyse de composition logicielle s'occupe des dépendances déclarées dans votre code.

Détecter la compromission depuis la surface d'attaque externe

Le SBOM regarde votre logiciel de l'intérieur, à la compilation. Mais une partie de votre chaîne d'approvisionnement ne vit qu'à l'exécution, dans le navigateur, et échappe donc à cette vue. Pour la couvrir, il faut adopter le point de vue de l'attaquant, et de l'utilisateur : regarder ce qui se charge réellement sur vos pages publiques, depuis l'extérieur. C'est le domaine de la gestion de la surface d'attaque externe (EASM), dont la sécurité de la chaîne d'approvisionnement est un volet à part entière.

Concrètement, on crawle vos pages avec un vrai navigateur, en passif (aucun payload, aucune exploitation, compatible production), et on inventorie chaque script tiers qui s'exécute vraiment : tag manager, analytics, widgets, chatbots, CDN, pixels marketing. Un fichier JavaScript minifié ne dit pas d'où il vient ; on remonte donc sa provenance, chemins node_modules résiduels dans le bundle, source maps exposées, en-têtes de licence, pour rattacher le code chargé aux paquets npm dont il est issu, et à leur version. On passe ainsi de "un blob de 400 ko" à une nomenclature réelle de ce qui tourne chez vos visiteurs.

Une fois la provenance établie, chaque dépendance est notée par risque : santé du paquet (abandon, bus-factor faible sur GitHub), signaux de paquet malveillant, dependency confusion, typosquat npm, intégrité de sous-ressource (SRI) manquante là où elle s'applique, script servi par un domaine qui change de mains, ou secret oublié dans une source map exposée. Et parce qu'une surface d'attaque bouge tous les jours, la surveillance est continue : le jour où un CDN change de propriétaire ou qu'un nouveau script apparaît sur une page, l'alerte tombe. C'est ce que fait notre module sécurité de la chaîne d'approvisionnement.

Réduire la surface : les réflexes qui paient

Aucune parade unique n'existe, mais quelques habitudes coupent la grande majorité des scénarios. Elles coûtent peu d'argent et demandent surtout de la discipline.

• Épinglez tout. Versions exactes (lockfiles committés), hash des artefacts, actions CI épinglées par SHA et non par tag mouvant. Une version flottante ^0.1.0, c'est la porte par laquelle flatmap-stream@0.1.1 est entré.
• Intégrité de sous-ressource pour tout script externe. Un attribut integrity (SRI) sur vos balises <script> tierces bloque net toute modification du fichier servi, à condition que ce fichier soit figé : une bibliothèque à version exacte sur un CDN public. Sur 160 pages qui en chargent une dans notre mesure, 153 le font au moins une fois sans integrity. Pour un service qui sert un contenu variable par conception, comme l'était polyfill.io, SRI casserait le script : la seule parade est d'auto-héberger, ou de retirer.
• Réduisez la surface de dépendances. Chaque paquet ajouté est un mainteneur à qui vous accordez l'exécution de code. La dépendance la plus sûre est celle qu'on n'ajoute pas.
• Isolez le build. Runners éphémères, secrets à portée minimale, pas de token de publication qui traîne dans l'environnement d'un preinstall. C'est ce genre de jeton que le ver Shai-Hulud a siphonné pour se propager.
• Surveillez en continu, de l'extérieur. Un SBOM daté du mois dernier ne voit pas le CDN qui a basculé hier. La veille sur ce que vos pages chargent réellement est la seule à capter les compromissions qui surviennent après votre déploiement.

À retenir

Dans la plupart des organisations, le point aveugle est le code qu'on charge, souvent sans le savoir, sur ses propres pages, plus que celui qu'on écrit. Savoir quels scripts et quelles dépendances tiers tournent chez vos visiteurs, d'où ils viennent et à quel point ils sont sains, c'est le métier de notre module sécurité de la chaîne d'approvisionnement, au sein de la plateforme EASM d'own2pwn. Ou parlez-en de vive voix avec un pentester via la page contact.

Questions fréquentes sur les attaques supply chain