Ce que le MDM ne peut pas protéger sur les machines des développeurs (et comment y remédier)

La gestion des appareils mobiles (MDM) désigne un type de logiciel utilisé par les entreprises pour sécuriser, gérer et surveiller les appareils mobiles de leurs employés. Des outils tels que Jamf, Kandji et Microsoft Intune offrent aux équipes informatiques une visibilité et un contrôle sur toutes les applications autorisées au sein du parc. Pour les référentiels de conformité tels que SOC 2 ou ISO 27001, le MDM est souvent un élément central permettant de démontrer le contrôle des appareils et de garantir la sécurité des données. Si votre solution MDM est déployée, félicitations, vous avez relevé le défi de sécurité lié au BYOD de 2012.

Le problème, c'est que la surface d'attaque des développeurs d'aujourd'hui a discrètement dépassé ce pour quoi les solutions MDM avaient été conçues. Lorsque les machines des développeurs sont compromises, le point d'entrée est rarement le système d'exploitation ou un élément déployé par le service informatique. Récemment, une extension VS Code malveillante installée sur l'appareil d'un développeur a permis à un attaquant de s'introduire dans GitHub, exposant ainsi des milliers de dépôts internes. Avant cela, le ver npm Mini Shai-Hulud avait compromis plus de 160 paquets, dont Mistral et TanStack, en volant les identifiants des machines des développeurs. Les appareils des développeurs sont la cible numéro un des attaquants, et pourtant, le MDM n'en a pas conscience. 

Cet article va vous expliquer où se situent les lacunes du MDM, ce que l'EDR ne détecte pas non plus, et comment vous assurer que les appareils de vos développeurs sont réellement protégés.

Comment fonctionne la gestion des appareils mobiles (MDM) et quelles sont ses limites

La gestion des appareils mobiles (MDM) intervient au niveau du système d'exploitation et des applications. Concrètement, cela implique de déployer les mises à jour du système d'exploitation, d'appliquer les politiques de mot de passe, de gérer les certificats, d'imposer le chiffrement des disques, de tenir à jour un inventaire des applications installées et de disposer d'une option d'effacement à distance en cas de perte ou de vol d'un appareil. La MDM fonctionne bien pour les applications déployées via les mécanismes standard du système d'exploitation, comme l'App Store, les déploiements de logiciels d'entreprise et les binaires signés distribués via une console de gestion.

Les lacunes mentionnées ci-dessous ont toutes la même cause profonde. Les gestionnaires de paquets tels que npm et pip sont des outils fonctionnant dans l'espace utilisateur. Ils récupèrent des logiciels à partir de registres avec lesquels le MDM n'a aucun lien, pour les placer dans des répertoires de projet sur lesquels le MDM n'a aucune visibilité, et ce à la suite de commandes exécutées dans le terminal d'un développeur. Il en va de même pour les extensions d'IDE installées via une boutique en ligne, les plugins de navigateur et les outils d'IA. Aucun de ces éléments ne passe par les mécanismes d'installation au niveau du système d'exploitation que le MDM surveille.

Ce qui manque au MDM 

Registres de paquets 

Le MDM sait quelles applications le service informatique a approuvées et déployées, mais il n'a aucune visibilité sur ce qu'un développeur récupère depuis un registre de paquets. C'est important, car les paquets exécutent du code au moment de l'installation via des hooks de cycle de vie avant même que vos outils de sécurité n'aient eu le temps de réagir. Au moment où un paquet malveillant a exécuté sa charge utile, il a peut-être déjà récupéré les identifiants de la machine du développeur. Le ver Mini Shai-Hulud fonctionnait exactement de cette manière, en récupérant silencieusement les jetons npm et GitHub, puis en les utilisant pour publier des versions malveillantes du paquet suivant dans la chaîne.

Les outils de codage basés sur l'IA ont apporté une nouvelle dimension à ce problème. Les modèles d'IA inventent de faux noms de paquets, et les pirates les enregistrent avant que quiconque ne s'en aperçoive. Un développeur demande à un outil de codage basé sur l'IA d'ajouter une dépendance ; l'outil lui suggère alors avec assurance un paquet qui n'existe pas, alors qu'un pirate a déjà revendiqué ce nom sur npm en y intégrant une charge malveillante. Dans tous les cas, MDM ne détecte pas l'installation. 

Extensions de navigateur

Même si une grande partie du travail des développeurs se déroule dans le navigateur, la plupart des équipes de sécurité ne s’en préoccupent pas suffisamment. GitHub, cloud , les tableaux de bord CI/CD et les outils internes restent ouverts et authentifiés toute la journée. Les extensions de navigateur s'ajoutent à cet environnement avec des autorisations que la plupart des gens accordent sans y réfléchir à deux fois. Une extension ayant accès à tous les sites peut lire tout ce que le navigateur charge, y compris les sessions authentifiées et tout ce qui transite par la page. Le MDM n'a aucune visibilité sur tout cela. 

La faille de sécurité survenue chez Vercel en début d'année a montré à quelle vitesse cela peut devenir un problème. Un employé de Vercel a installé une extension Chrome et lui a accordé un accès OAuth à son Google Workspace. Lorsque l'appareil d'un employé de Context.ai a ensuite été compromis par un logiciel de vol d'informations, l'attaquant a trouvé le jeton OAuth stocké et l'a utilisé pour accéder aux systèmes internes de Vercel. Le MDM n'aurait pas pu signaler cette extension malveillante, car elle avait été installée par le développeur et non par le service informatique, et ce qu'elle faisait avec les autorisations qui lui avaient été accordées était totalement invisible pour le MDM.

Ce qui rend les extensions de navigateur particulièrement difficiles à gérer, c'est qu'elles se mettent à jour en silence. Une extension qui était inoffensive au moment de son installation peut recevoir une mise à jour malveillante du jour au lendemain, et tous les utilisateurs ayant activé la mise à jour automatique la reçoivent automatiquement. La faille de sécurité de Cyberhaven en 2024 a suivi exactement ce schéma. Une attaque par hameçonnage visant un compte de développeur a conduit à la diffusion d'une mise à jour malveillante à tous les utilisateurs, qui est restée active pendant 24 heures avant que quiconque ne s'en aperçoive.

Extensions IDE

De tous les logiciels qu'un développeur installe, c'est le plugin VS Code qui se trouve le plus près des « joyaux de la couronne ». Il s'exécute directement au sein de l'environnement de développement et offre une visibilité sur les activités du développeur bien supérieure à celle de presque tout autre élément présent sur la machine. À l'instar des extensions de navigateur, les extensions d'IDE sont installées par les développeurs eux-mêmes, se mettent à jour en arrière-plan et échappent totalement au champ de vision des solutions de gestion des appareils mobiles (MDM). La différence réside dans le fait que les extensions d'IDE ont accès au code source et aux identifiants de connexion.

La faille de sécurité sur GitHub l'a clairement démontré. Le point d'entrée était l'extension Nx Console pour VS Code, une extension provenant d'un éditeur certifié comptant 2,2 millions d'installations, qui a été compromise pendant seulement 18 minutes sur le Visual Studio Marketplace. VS Code vérifie les mises à jour des extensions chaque fois que l'éditeur interagit avec la galerie, ouvre la barre latérale, effectue une recherche sur le Marketplace ou récupère des métadonnées en arrière-plan. La version malveillante a donc automatiquement atteint les développeurs dont l'éditeur était ouvert pendant ces 18 minutes, sans notification ni avertissement. 3 800 dépôts internes de GitHub ont été exposés. Le MDM n'a joué aucun rôle dans la détection de cet incident.

Outils d'IA, serveurs MCP et agents de codage

Les outils de codage basés sur l'IA font désormais partie intégrante du quotidien des développeurs. Cursor, GitHub Copilot, Claude Code et Windsurf agissent souvent sans qu'un humain ne vérifie ce qui est installé ou où vont les données. Les équipes de sécurité qui s'appuient sur les solutions MDM avancent en grande partie à l'aveuglette sur tous ces aspects.

Les serveurs MCP vont encore plus loin en permettant aux assistants IA d'interagir avec des services externes. Et comme toute dépendance, ils peuvent être compromis. En septembre 2025, le paquet npm « postmark-mcp » est devenu le premier serveur MCP malveillant confirmé en circulation. Il envoyait en copie cachée, à l'insu de l'utilisateur, chaque e-mail sortant vers une adresse contrôlée par un pirate. Le serveur MCP avait connu quinze versions saines avant que la porte dérobée n'apparaisse dans la seizième.

Il s'agit d'une toute nouvelle surface d'attaque, et la plupart des équipes de sécurité ne la surveillent pas encore.

Et l'EDR, alors ? 

Lorsque les équipes de sécurité se rendent compte que la gestion des appareils mobiles (MDM) ne suffit pas, elles se tournent généralement vers les solutions de détection et de réponse sur les terminaux (EDR). Des outils tels que CrowdStrike SentinelOne les comportements anormaux des processus, les modifications suspectes du système de fichiers et les communications de commande et de contrôle. Si un logiciel malveillant est en cours d'exécution sur une machine, l'EDR a de bonnes chances de le détecter.

Le problème, c'est que l'EDR intervient après l'exécution. Au moment où il détecte quelque chose, un hook malveillant post-installation s'est déjà exécuté, les identifiants ont déjà été récupérés et, dans le cas de Mini Shai-Hulud, les jetons volés étaient déjà utilisés pour publier la vague suivante de paquets compromis. L'EDR ne voit pas la commande « npm install ». Il détecte un processus qui ressemble à une activité de développement normale. À ce stade, il est déjà trop tard.

Comment combler les lacunes

Le MDM et l'EDR traditionnel ne sont pas près de disparaître, et c'est très bien ainsi. L'objectif est d'y ajouter des mesures de contrôle supplémentaires qui couvrent la surface d'attaque spécifique aux développeurs, pour laquelle ces solutions n'ont jamais été conçues.

Imposer un âge minimum pour l'achat de ce produit

Les nouveaux paquets présentent un risque élevé. Une politique imposant un délai minimum de 48 heures permet de bloquer le typosquatting le jour même et les campagnes de logiciels malveillants à propagation rapide avant qu’elles n’atteignent vos développeurs. La campagne Mini Shai-Hulud et l’attaque contre Axios ont toutes deux diffusé leurs charges utiles via des paquets publiés quelques heures seulement après la compromission. Une politique d'âge minimum de 48 heures aurait bloqué ces deux incidents avant qu'ils n'atteignent la moindre machine de développeur. Il convient de noter que cela s'applique à npm et aux paquets de dépendances logicielles en général. Cela ne résout pas le problème des extensions à mise à jour automatique, qui est d'une autre nature.

Bloquer les scripts post-installation par défaut

La plupart des équipes configurent --ignorer-les-scripts dans leur pipeline pour empêcher l'exécution automatique des hooks post-installation. Rares sont ceux qui appliquent ce même paramètre par défaut aux machines des développeurs. Le ver Mini Shai-Hulud a diffusé sa charge utile via un hook post-installation. Si l'environnement local d'un développeur exécute des scripts d'installation par défaut, c'est là que réside le risque. Vous pouvez configurer ignore-scripts=true à l'échelle mondiale .npmrc fichier, mais il est difficile de le faire respecter de manière cohérente au sein de toute une équipe sans outils adaptés.

Vérifier les extensions de navigateur et d'IDE

La plupart des équipes de sécurité n'ont aucune idée des extensions VS Code ou des modules complémentaires de navigateur installés sur les postes de leurs développeurs. Vous devez savoir ce qui est installé, par qui, et si ces éléments ont été mis à jour récemment. Les violations de sécurité sur GitHub et Vercel ont toutes deux commencé par des extensions que personne ne surveillait. L'objectif est de tenir à jour une liste d'extensions approuvées et de la faire respecter de manière centralisée, mais ce n'est pas quelque chose que l'on peut faire manuellement à grande échelle.

Surveiller les outils de codage basés sur l'IA qui sont installés

Les développeurs utilisent Cursor, Claude Code, Copilot et une liste croissante de serveurs MCP, souvent à l'insu des équipes de sécurité. L'IA fantôme est bien réelle. On ne peut pas contrôler ce qu'on ne voit pas, et les outils d'IA qui installent des paquets de manière autonome, sans intervention humaine, constituent une partie active de votre surface d'attaque.

Utiliser des outils dédiés aux points de terminaison pour développeurs

Les mesures de contrôle mentionnées ci-dessus sont soit difficiles à appliquer de manière cohérente à grande échelle, soit elles ne couvrent pas l'ensemble de la surface d'attaque. Les outils dédiés aux terminaux des développeurs sont spécialement conçus pour surveiller les installations de paquets, l'activité des extensions et le comportement des outils d'IA au niveau des appareils, sur chaque machine du parc.

Protection Aikido s'intègre à votre solution MDM existante et prend en charge les registres de paquets, les extensions IDE, les plugins de navigateur et les boutiques d'outils d'IA. Lorsqu'un développeur exécute npm install axios et comme la dernière version a été publiée il y a une heure, la protection des appareils revient à la version la plus récente qui respecte la règle d'ancienneté minimale de 48 heures. Les installations sûres se déroulent sans interruption. Les installations malveillantes sont bloquées avant même d'atteindre l'appareil.

Il s'appuie sur Aikido , qui analyse plus de 100 000 projets suspects chaque jour. Si vous souhaitez vous lancer sans procéder à un déploiement complet, Safe Chain constitue le point de départ idéal en open source. Si vous l'utilisiez lors des attaques Shai-Hulud, TeamPCP et Axios, vous étiez protégé.

La gestion des appareils mobiles (MDM) est nécessaire, mais pas suffisante

Il ne s'agit pas ici de préconiser le remplacement du MDM. Ce système remplit parfaitement sa mission, et pour la conformité des appareils, la gestion des certificats et la démonstration de la maîtrise des processus auprès de vos auditeurs, il reste l'outil idéal. Cependant, les machines des développeurs sont discrètement devenues une catégorie distincte de terminaux, avec une surface d'exposition aux menaces qui n'existait pas lorsque le MDM a été conçu.

La question que la plupart des équipes de sécurité devraient se poser est la suivante : que se passe-t-il entre la mise en place de la politique MDM et l'installation du package ?

‍