Lo que el MDM no puede proteger en los equipos de los desarrolladores (y qué hacer al respecto)

La gestión de dispositivos móviles (MDM) es un tipo de software que utilizan las organizaciones para proteger, gestionar y supervisar los dispositivos móviles de sus empleados. Herramientas como Jamf, Kandji y Microsoft Intune proporcionan a los equipos de TI visibilidad y control sobre todas las aplicaciones autorizadas en toda la flota. En el caso de marcos de cumplimiento como SOC 2 o ISO 27001, el MDM suele ser un componente fundamental para demostrar el control de los dispositivos y garantizar la seguridad de los datos. Si ya tienes implementado tu MDM, enhorabuena, has resuelto el reto de seguridad del BYOD de 2012.

El problema es que la superficie de ataque de los desarrolladores actuales ha superado silenciosamente los límites para los que se diseñó la gestión de dispositivos móviles (MDM). Cuando los equipos de los desarrolladores se ven comprometidos, el punto de entrada rara vez es el sistema operativo o cualquier elemento implementado por el departamento de TI. Recientemente, una extensión maliciosa de VS Code instalada en el dispositivo de un desarrollador permitió a un atacante infiltrarse en GitHub, dejando al descubierto miles de repositorios internos. Antes de eso, el gusano npm Mini Shai-Hulud comprometió más de 160 paquetes, incluidos Mistral y TanStack, al robar credenciales de los equipos de los desarrolladores. Los dispositivos de los desarrolladores son el objetivo número uno de los atacantes y, sin embargo, el MDM no se da cuenta. 

En este artículo se analizará dónde están los puntos ciegos de MDM, qué es lo que también pasa por alto el EDR y cómo asegurarse de que los dispositivos de los desarrolladores estén realmente protegidos.

Cómo funciona la gestión de dispositivos móviles (MDM) y cuáles son sus límites

El MDM opera a nivel del sistema operativo y de las aplicaciones. En la práctica, esto implica instalar actualizaciones del sistema operativo, aplicar políticas de contraseñas, gestionar certificados, aplicar el cifrado de disco, mantener un inventario de las aplicaciones instaladas y disponer de una opción de borrado remoto en caso de pérdida o robo de los dispositivos. El MDM funciona bien con aplicaciones implementadas a través de mecanismos estándar del sistema operativo, como la App Store, implementaciones de software empresarial y binarios firmados instalados mediante una consola de gestión.

Todos los puntos ciegos que se mencionan a continuación comparten la misma causa fundamental. Los gestores de paquetes como npm y pip son herramientas del espacio de usuario. Descargan software de registros con los que el MDM no tiene relación alguna, lo instalan en directorios de proyecto sobre los que el MDM no tiene visibilidad, y todo ello se activa mediante comandos que se ejecutan en el shell del desarrollador. Lo mismo ocurre con las extensiones de IDE instaladas a través de un mercado de aplicaciones, los complementos de navegador y las herramientas de IA. Ninguna de estas herramientas pasa por los mecanismos de instalación a nivel del sistema operativo que supervisa el MDM.

Lo que se echa en falta en el MDM 

Registros de paquetes 

MDM sabe qué aplicaciones ha aprobado e implementado el departamento de TI, pero no tiene visibilidad sobre lo que un desarrollador descarga de un registro de paquetes. Esto es importante porque los paquetes ejecutan código en el momento de la instalación a través de «hooks» del ciclo de vida antes de que tus herramientas de seguridad tengan oportunidad de reaccionar. Para cuando un paquete malicioso ha ejecutado su carga útil, es posible que ya haya robado las credenciales del equipo del desarrollador. El gusano Mini Shai-Hulud funcionaba exactamente así, robando silenciosamente tokens de npm y GitHub, y utilizándolos luego para publicar versiones maliciosas del siguiente paquete de la cadena.

Las herramientas de programación basadas en IA han dado un nuevo giro a esta situación. Los modelos de IA inventan nombres de paquetes, y los atacantes los registran antes de que nadie se dé cuenta. Un desarrollador le pide a una herramienta de programación basada en IA que añada una dependencia; la herramienta sugiere con total seguridad un paquete que no existe, y un atacante ya se ha apropiado de ese nombre en npm con una carga maliciosa en su interior. En cualquier caso, MDM no detecta la instalación. 

Extensiones para el navegador

Aunque gran parte del trabajo de un desarrollador se lleva a cabo en el navegador, la mayoría de los equipos de seguridad no le prestan la atención que debería. GitHub, las consolas en la nube, los paneles de CI/CD y las herramientas internas permanecen abiertos y autenticados durante todo el día. Las extensiones del navegador se superponen a ese entorno con permisos que la mayoría de la gente concede sin pensarlo dos veces. Una extensión con acceso a todos los sitios puede leer todo lo que carga el navegador, incluidas las sesiones autenticadas y cualquier dato que pase por la página en tránsito. MDM no tiene visibilidad sobre nada de esto. 

La filtración de datos de Vercel a principios de este año puso de manifiesto lo rápido que esto se convierte en un problema. Un empleado de Vercel instaló una extensión de Chrome y le concedió acceso OAuth a su Google Workspace. Cuando el dispositivo de un empleado de Context.ai fue posteriormente comprometido por un programa de robo de información, el atacante encontró el token OAuth almacenado y lo utilizó para acceder a los sistemas internos de Vercel. El MDM no pudo detectar esta extensión maliciosa porque la instaló el desarrollador, no el departamento de TI, y lo que hacía con los permisos que se le habían concedido era completamente invisible para el MDM.

Lo que hace que las extensiones de navegador sean especialmente difíciles de gestionar es que se actualizan de forma silenciosa. Una extensión que estaba limpia en el momento de la instalación puede recibir una actualización maliciosa de la noche a la mañana, y todos los usuarios que tengan activada la actualización automática la reciben automáticamente. La filtración de Cyberhaven en 2024 siguió exactamente ese patrón. Un ataque de phishing contra una cuenta de desarrollador provocó que se distribuyera una actualización maliciosa a todos los usuarios, que estuvo activa durante 24 horas antes de que nadie se diera cuenta.

Extensiones del IDE

De todo el software que instala un desarrollador, un complemento de VS Code es lo más parecido a las joyas de la corona. Se ejecuta directamente dentro del entorno de desarrollo y ofrece una visión más clara de lo que hace el desarrollador que casi cualquier otro elemento del equipo. Al igual que las extensiones de navegador, las extensiones del IDE las instalan los propios desarrolladores, se actualizan de forma silenciosa y quedan fuera del campo de visión de los sistemas de gestión de dispositivos móviles (MDM). La diferencia es que las extensiones del IDE pueden acceder al código fuente y a las credenciales.

La filtración de GitHub lo dejó claro. El punto de entrada fue la extensión Nx Console para VS Code, una extensión de un editor verificado con 2,2 millones de instalaciones que estuvo comprometida durante tan solo 18 minutos en Visual Studio Marketplace. VS Code comprueba si hay actualizaciones de extensiones cada vez que el editor interactúa con la galería, abre la barra lateral, realiza una búsqueda en el marketplace o recupera metadatos en segundo plano, por lo que la versión maliciosa llegó automáticamente a los desarrolladores que tenían el editor abierto durante esos 18 minutos, sin ningún aviso ni advertencia. Quedaron expuestos 3.800 repositorios internos de GitHub. MDM no participó en la detección de nada de esto.

Herramientas de IA, servidores MCP y agentes de programación

Las herramientas de programación basadas en IA se han convertido en un elemento habitual del trabajo de los desarrolladores. Cursor, GitHub Copilot, Claude Code y Windsurf realizan acciones, a menudo sin que un humano revise qué se instala o adónde van a parar los datos. Los equipos de seguridad que dependen de la gestión de dispositivos móviles (MDM) están, en gran medida, trabajando a ciegas en todo esto.

Los servidores MCP amplían aún más esta capacidad al permitir que los asistentes de IA interactúen con servicios externos. Y, como cualquier otra dependencia, pueden verse comprometidos. En septiembre de 2025, el paquete npm «postmark-mcp» se convirtió en el primer servidor MCP malicioso confirmado en circulación. Enviaba silenciosamente una copia oculta de todos los correos electrónicos salientes a una dirección controlada por el atacante. El servidor MCP tuvo quince versiones limpias antes de que la puerta trasera apareciera en la decimosexta.

Se trata de una superficie de ataque totalmente nueva, y la mayoría de los equipos de seguridad aún no la tienen en cuenta.

¿Y qué hay de EDR? 

Cuando los equipos de seguridad se dan cuenta de que la gestión de dispositivos móviles (MDM) no es suficiente, lo siguiente a lo que suelen recurrir es a la detección y respuesta en endpoints (EDR). Herramientas como CrowdStrike SentinelOne el comportamiento anómalo de los procesos, los cambios sospechosos en el sistema de archivos y las comunicaciones de comando y control. Si hay malware ejecutándose activamente en un equipo, la EDR tiene muchas posibilidades de detectarlo.

El problema es que el EDR entra en acción tras la ejecución. Para cuando tiene algo que detectar, un gancho malicioso posterior a la instalación ya se ha ejecutado, las credenciales ya han sido sustraídas y, en el caso de Mini Shai-Hulud, los tokens robados ya se estaban utilizando para publicar la siguiente oleada de paquetes comprometidos. El EDR no detecta el comando «npm install». Lo que ve es un proceso que parece una actividad de desarrollo normal. Para entonces, ya es demasiado tarde.

Cómo subsanar las deficiencias

Las soluciones de gestión de dispositivos móviles (MDM) y los sistemas tradicionales de detección y respuesta ante amenazas (EDR) no van a desaparecer, ni deberían hacerlo. El objetivo es añadirles controles adicionales que cubran la superficie de ataque específica de los desarrolladores, para la que nunca fueron diseñados.

Establecer una edad mínima para la compra de paquetes

Los paquetes nuevos entrañan un alto riesgo. Una política de antigüedad mínima de 48 horas bloquea el typosquatting del mismo día y las campañas de malware de rápida propagación antes de que lleguen a tus desarrolladores. Tanto la campaña Mini Shai-Hulud como el ataque a Axios distribuyeron sus cargas maliciosas a través de paquetes publicados pocas horas después de que se produjera la vulneración. Una política de antigüedad mínima de 48 horas habría bloqueado ambos antes de que llegaran a un solo equipo de desarrollador. Cabe señalar que esto se aplica a npm y a los paquetes de dependencias de software en general. No sirve de ayuda con las extensiones de actualización automática, lo cual es un problema distinto.

Bloquear los scripts de posinstalación de forma predeterminada

La mayoría de los equipos configuran --ignorar-scripts en su proceso para impedir que los ganchos de postinstalación se ejecuten automáticamente. Son menos los que aplican la misma configuración predeterminada a los equipos de los desarrolladores. El gusano Mini Shai-Hulud distribuyó su carga útil a través de un gancho de postinstalación. Si el entorno local de un desarrollador ejecuta scripts de instalación de forma predeterminada, ahí es donde reside el riesgo. Se puede configurar ignore-scripts=true a nivel mundial .npmrc archivo, pero resulta difícil garantizar su cumplimiento de forma coherente en todo el equipo sin herramientas adecuadas.

Revisar las extensiones del navegador y del IDE

La mayoría de los equipos de seguridad no tienen ni idea de qué extensiones de VS Code o complementos de navegador están instalados en sus equipos de desarrollo. Es necesario saber qué está instalado, quién lo ha instalado y si se ha actualizado recientemente. Las brechas de seguridad de GitHub y Vercel se originaron en extensiones que nadie supervisaba. El objetivo es mantener una lista de extensiones aprobadas y garantizar su cumplimiento de forma centralizada, pero no es algo que se pueda hacer manualmente a gran escala.

Controla qué herramientas de programación basadas en IA se instalan

Los desarrolladores están utilizando Cursor, Claude Code, Copilot y una lista cada vez mayor de servidores MCP, a menudo sin que los equipos de seguridad lo sepan. La IA en la sombra es una realidad. No se puede controlar lo que no se ve, y las herramientas de IA que instalan paquetes de forma autónoma sin revisión humana constituyen una parte activa de tu superficie de ataque.

Utiliza herramientas específicas para puntos de conexión de desarrolladores

Las medidas de control mencionadas anteriormente resultan difíciles de aplicar de forma coherente a gran escala o no cubren toda la superficie de ataque. Las herramientas específicas para terminales de desarrolladores se han diseñado expresamente para supervisar la instalación de paquetes, la actividad de las extensiones y el comportamiento de las herramientas de IA a nivel de dispositivo en todos los equipos del parque informático.

Protección de los equipos de aikido se implementa a través de tu MDM actual y abarca registros de paquetes, extensiones de IDE, complementos de navegador y mercados de herramientas de IA. Cuando un desarrollador ejecuta npm i axios y, dado que la última versión se publicó hace una hora, Device Protection recurre a la versión más reciente que cumple con la política de antigüedad mínima de 48 horas. Las instalaciones seguras se llevan a cabo sin interrupciones. Las maliciosas se bloquean antes de que lleguen al equipo.

Se basa en Aikido Intel, que analiza más de 100 000 proyectos sospechosos al día. Si quieres empezar sin una implementación completa, Safe Chain es el punto de partida de código abierto. Si lo tenías en funcionamiento durante los ataques de Shai-Hulud, TeamPCP y Axios, estabas protegido.

La gestión de dispositivos móviles (MDM) es necesaria, pero no suficiente

Esto no es un argumento a favor de sustituir el MDM. Cumple con su función, y para garantizar el cumplimiento normativo de los dispositivos, gestionar certificados y demostrar el control ante los auditores, sigue siendo la herramienta adecuada. Sin embargo, los equipos de los desarrolladores se han convertido, sin que nos diéramos cuenta, en una categoría diferente de terminal, con una superficie de ataque que no existía cuando se diseñó el MDM.

La pregunta que la mayoría de los equipos de seguridad deberían plantearse es qué ocurre entre la aplicación de la política de MDM y la instalación del paquete.