~5 minutes
Une dépendance compromise dans ta stack MCP, et c’est ton agent IA tout entier qui est sous contrôle d’un attaquant. Les supply chain attacks touchent maintenant l’écosystème IA avec la même efficacité dévastatrice que chez SolarWinds ou XZ Utils.
Partie de la série OWASP MCP Top 10
Description du risque
Je constate que les attaques supply chain frappent maintenant l’écosystème MCP avec la même efficacité dévastatrice que chez SolarWinds ou XZ Utils.
Les attaques sur la chaîne d’approvisionnement dans le contexte MCP ciblent les dépendances, plugins et bibliothèques qui composent les serveurs MCP. Une dépendance compromise peut altérer le comportement des agents ou introduire des portes dérobées au niveau exécution sans que le code de l’agent lui-même soit touché.
Une dépendance compromise peut altérer le comportement des agents ou introduire des portes dérobées au niveau exécution sans que le code de l’agent lui-même soit touché.
Ce risque est amplifié par la jeunesse de l’écosystème MCP : les développeurs installent des packages peu vérifiés, les serveurs MCP communautaires prolifèrent sans audit, et les chaînes de confiance sont souvent inexistantes. La vague IA et encore plus Agentic et MCP ont créé un terrain fertile pour les attaquants qui exploitent la moindre faiblesse dans la supply chain.
Vecteurs d’attaque
On distingue quatre vecteurs principaux d’attaque sur la chaîne d’approvisionnement MCP :
1. Typosquatting de packages
L’attaquant publie un package avec un nom quasi-identique à un package légitime (mcp-filesytem-tools vs mcp-filesystem-tools). Le développeur distrait installe la mauvaise version.
2. Compromission d’un package légitime
L’attaquant prend le contrôle du compte d’un mainteneur et publie une mise à jour contenant un backdoor. Le package garde son nom et sa réputation et seul le code change.
3. Dependency confusion
L’attaquant publie un package public avec le même nom qu’un package interne. Le gestionnaire de packages résout vers la version publique malveillante.
4. Dépendance transitive compromise
Le serveur MCP dépend de A, qui dépend de B, qui est compromis. Le développeur n’a jamais audité B car il ne sait même pas qu’il en dépend.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui (PRIMAIRE) | Le package malveillant usurpe l’identité d’un package légitime. Le développeur croit installer un composant de confiance. |
| Tampering (Falsification) | Oui | Les dépendances compromises altèrent le comportement de l’agent. Le code backdooré s’exécute avec les mêmes permissions que le code légitime. |
| Repudiation (Répudiation) | Oui | Les actions du backdoor sont attribuées au serveur MCP légitime. Le forensic doit identifier quelle dépendance, parmi des dizaines, contient le code malveillant. |
| Information Disclosure (Divulgation d’informations) | Oui | Les packages backdoorés exfiltrent des données : credentials, contexte MCP, données utilisateur. L’exfiltration est souvent silencieuse et persistante. |
| Denial of Service (Déni de service) | Oui | Des dépendances corrompues peuvent crasher le stack MCP ou dégrader les performances de manière intermittente, rendant le diagnostic difficile. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Le code backdooré s’exécute avec les permissions complètes du serveur MCP : accès fichiers, réseau, base de données, APIs. |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Exfiltration silencieuse de tous les contextes MCP qui transitent par le serveur compromis. Credentials, données utilisateur, code source, tout est accessible au backdoor. |
| Intégrité | Critique | Modification du comportement de l'agent à grande échelle. Le backdoor peut altérer les résultats des outils, injecter des instructions dans le contexte, ou modifier les données stockées. |
| Disponibilité | Élevé | Une dépendance corrompue peut provoquer des crashs intermittents difficiles à diagnostiquer. La mise à jour forcée (fix) peut aussi casser des dépendances cascadées. |
| Réputation | Sévère | La compromission de tous les clients utilisant un serveur MCP backdooré génère un incident de grande ampleur. La confiance dans l'écosystème MCP tout entier est ébranlée. |
Recommandations de mitigation
Je pars du principe que la confiance aveugle dans les registres publics est le problème numéro un. Voici les quatre réflexes à adopter.
1. Fixer les versions et vérifier les hashes
Fixer chaque dépendance en version exacte (==1.2.3 en Python, version exacte dans package-lock.json), sans jamais utiliser les opérateurs ^ ou ~ qui autorisent des mises à jour silencieuses. Associer ça à une vérification d’intégrité cryptographique un npm ci (et non npm install) utilise le lockfile et vérifie les hashes, pip supporte --require-hashes. Si le hash ne correspond pas, l’installation échoue. C’est simple, c’est gratuit, et ça bloque les substitutions de packages en transit.
2. Scanner les dépendances transitives en CI
Ne pas se contenter d’auditer les dépendances directes. Intégrer un outil SCA (Snyk, Dependabot, OWASP Dependency-Track) dans le pipeline CI pour analyser l’arbre complet des dépendances. La backdoor se cache presque toujours dans une dépendance de niveau 3 ou 4, que personne n’a auditée manuellement. L’alerte est bloquante en cas de CVE HIGH ou CRITICAL, le build ne passe pas.
3. Mirrorer les packages critiques dans un registre privé
Pour les serveurs MCP en production, ne jamais consommer les registres publics directement. Configurer Artifactory, Nexus ou GitHub Packages comme proxy : les packages sont téléchargés une fois, scannés, puis mis à disposition en interne. Si le package public est backdooré post-installation (comme dans l’attaque XZ), la production n’est pas exposée aux nouvelles versions non approuvées.
4. Construire un AIBOM
Un agent IA n’est pas si différent d’un logiciel classique : je lui applique la même rigueur qu’à un composant critique. Générer un AIBOM (AI Bill of Materials) ( une liste exhaustive de tous les composants IA, modèles, plugins et dépendances MCP ) à chaque build. Ça permet de savoir en moins de 5 minutes si vous etes exposé quand une nouvelle CVE est publiée, et de répondre à la question “est-ce qu’on utilise ce package quelque part ?” Pour en savoir plus sur l’AIBOM, je vous renvoie vers OWASP AIBOM.
Quelques références pour aller plus loin
À retenir
