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

Le Mobile Device Management (MDM) est un type de logiciel utilisé par les organisations pour sécuriser, gérer et surveiller les appareils mobiles de leurs employés. Des outils comme Jamf, Kandji et Microsoft Intune offrent aux équipes informatiques une visibilité et un contrôle sur chaque application autorisée au sein du parc d'appareils. Pour les cadres de conformité comme SOC 2 ou ISO 27001, le MDM est souvent un composant essentiel pour démontrer le contrôle des appareils et assurer la sécurité des données. Si votre MDM est déployé, félicitations, vous avez résolu le défi de sécurité BYOD de 2012.

Le problème est que la surface d'attaque moderne des développeurs a discrètement dépassé ce que le MDM était conçu pour gérer. Lorsque les machines de développeurs sont compromises, le point d'entrée est rarement le système d'exploitation ou quoi que ce soit déployé par l'IT. Récemment, une extension VS Code malveillante installée sur l'appareil d'un développeur a permis à un attaquant de compromettre GitHub, exposant des milliers de dépôts internes. Avant cela, le ver npm Mini Shai-Hulud a compromis plus de 160 paquets, y compris Mistral et TanStack, en dérobant des identifiants sur les machines de développeurs. Les appareils de développeurs sont la cible numéro un des attaquants, et pourtant le MDM n'en sait rien. 

Cet article couvrira les angles morts du MDM, ce que l'EDR manque également, et comment s'assurer que vos appareils de développeurs sont réellement protégés.

Comment fonctionne le MDM, et où il s'arrête

Le MDM opère au niveau du système d'exploitation (OS) et de la couche applicative. En pratique, cela signifie pousser des mises à jour d'OS, appliquer des politiques de mots de passe, gérer des certificats, imposer le chiffrement de disque, maintenir un inventaire des applications installées et conserver une option d'effacement à distance en cas de perte ou de vol d'appareils. Pour les applications déployées via des mécanismes d'OS standard comme l'App Store, les déploiements de logiciels d'entreprise et les binaires signés poussés via une console de gestion, le MDM fonctionne bien.

Les angles morts ci-dessous partagent tous la même cause racine. Les gestionnaires de paquets comme npm et pip sont des outils en espace utilisateur. Ils téléchargent des logiciels depuis des registres avec lesquels le MDM n'a aucune relation, vers des répertoires de projets dans lesquels le MDM n'a aucune visibilité, déclenchés par des commandes exécutées dans le shell d'un développeur. Il en va de même pour les extensions d'IDE installées via une marketplace, les plugins de navigateur et les outils d'IA. Aucun de ceux-ci ne passe par les mécanismes d'installation au niveau de l'OS que le MDM surveille.

Ce que le MDM manque 

Registres de paquets 

Le MDM sait quelles applications l'IT a approuvées et déployées, mais il n'a aucune visibilité sur ce qu'un développeur télécharge 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 que vos outils de sécurité n'aient la moindre chance de réagir. Au moment où un paquet malveillant a exécuté sa charge utile, il peut avoir déjà dérobé des identifiants de la machine du développeur. Le ver Mini Shai-Hulud a fonctionné exactement de cette manière, dérobant silencieusement des jetons npm et GitHub, puis les utilisant pour publier des versions malveillantes du paquet suivant dans la chaîne.

Les outils de codage basés sur l'IA ont ajouté une nouvelle dimension à cela. Les modèles d'IA hallucinent des noms de paquets, et les attaquants les enregistrent avant que quiconque ne s'en aperçoive. Un développeur demande à un outil de codage IA d'ajouter une dépendance, l'outil suggère avec confiance un paquet qui n'existe pas, et un attaquant a déjà revendiqué ce nom sur npm avec une charge utile malveillante à l'intérieur. Le MDM manque l'installation dans tous les cas. 

Extensions de navigateur

Même si une grande partie du travail d'un développeur se déroule dans le navigateur, la plupart des équipes de sécurité ne s'en préoccupent pas suffisamment. GitHub, les consoles cloud, les tableaux de bord CI/CD et les outils internes restent tous ouverts et authentifiés toute la journée. Les extensions de navigateur se superposent à cet environnement avec des permissions 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 violation de données de Vercel plus tôt cette 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. Lorsqu'un appareil d'un employé de Context.ai a ensuite été compromis par un infostealer, 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 a été installée par le développeur, et non par l'IT, et ce qu'elle a fait avec les permissions qui lui ont été accordées était complètement invisible pour le MDM.

Ce qui rend les extensions de navigateur particulièrement difficiles à gérer, c'est qu'elles se mettent à jour silencieusement. Une extension qui était propre à l'installation peut recevoir une mise à jour malveillante du jour au lendemain, et chaque utilisateur ayant activé la mise à jour automatique la reçoit automatiquement. La violation de données de Cyberhaven en 2024 a suivi exactement ce schéma. Une attaque de phishing sur un compte développeur a conduit à la diffusion d'une mise à jour malveillante à tous les utilisateurs, active pendant 24 heures avant que quiconque ne la détecte.

Extensions d'IDE

De tous les logiciels qu'un développeur installe, un plugin VS Code se trouve le plus proche des joyaux de la couronne. Il s'exécute directement dans l'environnement de développement, avec plus de visibilité sur ce qu'un développeur fait que presque tout autre élément sur la machine. Comme les extensions de navigateur, les extensions d'IDE sont installées par les développeurs eux-mêmes, se mettent à jour silencieusement et ne sont nulle part dans le champ de vision du MDM. La différence est que les extensions d'IDE peuvent voir le code source et les identifiants.

La violation de données de GitHub a rendu cela concret. Le point d'entrée était l'extension VS Code Nx Console, une extension d'éditeur vérifié avec 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 d'extensions chaque fois que l'éditeur effectue une interaction avec la galerie, ouvre une barre latérale, effectue une recherche sur la marketplace, ou récupère des métadonnées en arrière-plan, de sorte que la version malveillante a atteint automatiquement les développeurs ayant l'éditeur ouvert pendant ces 18 minutes, sans aucune invite 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 tout cela.

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 travail des développeurs. Cursor, GitHub Copilot, Claude Code et Windsurf effectuent des actions, 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 le MDM naviguent en grande partie à l'aveugle sur tout cela.

Les serveurs MCP étendent cela davantage en donnant aux assistants IA la capacité 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é dans la nature. Il a silencieusement mis en copie invisible chaque e-mail sortant vers une adresse contrôlée par un attaquant. Le serveur MCP avait quinze versions saines avant que la porte dérobée n'apparaisse sur la seizième.

Il s'agit d'une surface d'attaque inédite, et la plupart des équipes de sécurité ne la suivent pas encore.

Qu'en est-il de l'EDR ? 

Lorsque les équipes de sécurité réalisent que le MDM ne suffit pas, l'Endpoint Detection and Response (EDR) est généralement la prochaine solution vers laquelle elles se tournent. Des outils comme CrowdStrike et SentinelOne surveillent les comportements de processus anormaux, les modifications suspectes du système de fichiers et les rappels de commande et contrôle. Si un malware est activement exécuté sur une machine, l'EDR a une chance raisonnable de le détecter.

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

Comment combler les lacunes

Le MDM et l'EDR traditionnel ne vont pas disparaître, et ils ne devraient pas. L'objectif est de superposer des contrôles qui couvrent la surface d'attaque spécifique aux développeurs pour laquelle ils n'ont jamais été conçus.

Appliquer un âge minimum pour les packages

Les nouveaux packages présentent un risque élevé. Une politique d'âge minimum de 48 heures bloque le typosquatting le jour même et les campagnes de malwares rapides avant qu'elles n'atteignent vos développeurs. La campagne Mini Shai-Hulud et l'attaque Axios ont toutes deux livré leurs charges utiles via des packages publiés quelques heures après le compromis. Une politique d'âge minimum de 48 heures les aurait bloquées toutes les deux avant qu'elles n'atteignent une seule machine de développeur. Il est à noter que cela s'applique aux packages npm et aux dépendances logicielles générales. Cela n'aide pas avec les extensions à mise à jour automatique, ce qui est un problème différent.

Bloquer les scripts post-installation par défaut

La plupart des équipes configurent --ignore-scripts dans leur pipeline pour empêcher l'exécution automatique des hooks de post-installation. Moins nombreuses sont celles qui appliquent le même comportement par défaut aux machines des développeurs. Le ver Mini Shai-Hulud a livré sa charge utile via un hook de post-installation. Si l'environnement local d'un développeur exécute les scripts d'installation par défaut, c'est là que se trouve l'exposition. Vous pouvez définir ignore-scripts=true dans un fichier global .npmrc fichier, mais l'appliquer de manière cohérente à toute une équipe sans outillage est difficile.

Auditer 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 plugins de navigateur installés sur l'ensemble de leur parc de développeurs. Vous avez besoin de visibilité sur ce qui est installé, par qui, et si cela a été mis à jour récemment. Les brèches de GitHub et Vercel ont toutes deux commencé par des extensions que personne ne surveillait. Maintenir une liste approuvée et l'appliquer de manière centralisée est l'objectif, mais ce n'est pas quelque chose que vous pouvez faire manuellement à grande échelle.

Surveiller ce qu'installent les outils de codage basés sur l'IA

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 une réalité. Vous ne pouvez pas gouverner ce que vous ne voyez pas, et les outils d'IA qui installent des packages de manière autonome sans examen humain sont une partie active de votre surface d'attaque.

Utiliser des outils dédiés aux endpoints de développeurs

Les contrôles ci-dessus sont soit difficiles à appliquer de manière cohérente à grande échelle, soit ils ne couvrent pas l'intégralité de la surface d'attaque. Les outils dédiés aux endpoints de développeurs sont conçus spécifiquement pour surveiller les installations de packages, l'activité des extensions et le comportement des outils d'IA au niveau de l'appareil sur chaque machine du parc.

Aikido Device Protection se déploie via votre MDM existant et couvre les registres de packages, les extensions d'IDE, les plugins de navigateur et les marketplaces d'outils d'IA. Lorsqu'un développeur exécute npm i axios et que la dernière version a été publiée il y a une heure, Device Protection revient à la version la plus récente qui satisfait une politique d'âge minimum de 48 heures. Les installations sûres se déroulent sans interruption. Les malveillantes sont bloquées avant d'atteindre la machine.

Il est basé sur Aikido Intel, qui analyse plus de 100 000 projets suspects par jour. Si vous souhaitez démarrer sans un déploiement complet, Safe Chain est le point de départ open source. Si vous l'exécutiez pendant les attaques Shai-Hulud, TeamPCP et Axios, vous étiez protégé.

Le MDM est nécessaire, mais pas suffisant

Il ne s'agit pas d'un argument pour remplacer le MDM. Il fait ce pour quoi il a été conçu, et pour la conformité des appareils, la gestion des certificats et la démonstration de contrôle à vos auditeurs, il reste l'outil approprié. Mais les machines des développeurs sont discrètement devenues une catégorie de terminaux différente, avec une surface d'attaque qui n'existait pas lors de la conception du MDM.

La question que la plupart des équipes de sécurité devraient se poser est ce qui se passe entre la politique MDM et l'installation du package.

‍