Lo que MDM no puede proteger en máquinas de desarrolladores (y qué hacer al respecto)

La Gestión de Dispositivos Móviles (MDM) es un tipo de software utilizado por las organizaciones para proteger, gestionar y monitorizar los dispositivos móviles de sus empleados. Herramientas como Jamf, Kandji y Microsoft Intune proporcionan a los equipos de TI visibilidad y control sobre cada aplicación autorizada en toda la flota. Para marcos de cumplimiento como SOC 2 o ISO 27001, MDM es a menudo un componente central de cómo se demuestra el control de dispositivos y se garantiza la seguridad de los datos. Si tu MDM está implementado, enhorabuena, has resuelto el desafío de seguridad BYOD de 2012.

El problema es que la superficie de ataque del desarrollador moderno ha superado discretamente lo que MDM fue diseñado para manejar. Cuando las máquinas de los desarrolladores se ven comprometidas, el punto de entrada rara vez es el sistema operativo o cualquier cosa implementada por TI. Recientemente, una extensión maliciosa de VS Code instalada en el dispositivo de un desarrollador permitió a un atacante vulnerar GitHub, exponiendo miles de repositorios internos. Antes de eso, el gusano npm Mini Shai-Hulud comprometió más de 160 paquetes, incluyendo Mistral y TanStack, al robar credenciales de máquinas de desarrolladores. Los dispositivos de los desarrolladores son el objetivo número uno para los atacantes, y sin embargo, MDM no se entera. 

Esta publicación cubrirá dónde están los puntos ciegos de MDM, lo que EDR también pasa por alto, y cómo asegurarse de que sus dispositivos de desarrollador estén realmente protegidos.

Cómo funciona MDM y dónde se detiene

MDM opera en la capa del sistema operativo (SO) y de las aplicaciones. En la práctica, esto implica la distribución de actualizaciones del SO, la aplicación de políticas de contraseñas, la gestión de certificados, la imposición del cifrado de disco, el mantenimiento de un inventario de aplicaciones instaladas y la disponibilidad de una opción de borrado remoto para dispositivos perdidos o robados. Para las aplicaciones desplegadas a través de mecanismos estándar del SO, como la App Store, las implementaciones de software empresarial y los binarios firmados distribuidos mediante una consola de gestión, MDM funciona correctamente.

Los puntos ciegos que se describen a continuación comparten la misma causa raíz. Los gestores de paquetes como npm y pip son herramientas de espacio de usuario. Extraen software de registros con los que MDM no tiene relación, hacia directorios de proyectos en los que MDM no tiene visibilidad, activados por comandos que se ejecutan en el shell de un desarrollador. Lo mismo ocurre con las extensiones de IDE instaladas a través de un marketplace, los plugins de navegador y las herramientas de IA. Ninguno de estos pasa por los mecanismos de instalación a nivel de SO que MDM monitoriza.

Lo que MDM no detecta 

Registros de paquetes 

MDM sabe qué aplicaciones ha aprobado y desplegado el departamento de TI, pero no tiene visibilidad sobre lo que un desarrollador extrae 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 de ciclo de vida antes de que sus herramientas de seguridad tengan la oportunidad de reaccionar. Para cuando un paquete malicioso ha ejecutado su payload, es posible que ya haya extraído credenciales de la máquina del desarrollador. El gusano Mini Shai-Hulud funcionó exactamente de esta manera, extrayendo silenciosamente tokens de npm y GitHub, y luego utilizándolos para publicar versiones maliciosas del siguiente paquete en la cadena.

Las herramientas de codificación de IA han añadido un nuevo giro a esto. Los modelos de IA alucinan nombres de paquetes, y los atacantes los registran antes de que nadie se dé cuenta. Un desarrollador pide a una herramienta de codificación de IA que añada una dependencia, la herramienta sugiere con confianza un paquete que no existe, y un atacante ya ha reclamado ese nombre en npm con un payload malicioso en su interior. MDM no detecta la instalación de cualquier manera. 

Extensiones de navegador

Aunque gran parte del trabajo de un desarrollador se realiza en el navegador, la mayoría de los equipos de seguridad no se preocupan lo suficiente por ello. GitHub, las consolas cloud, los paneles de CI/CD y las herramientas internas permanecen abiertos y autenticados todo el día. Las extensiones de navegador se sitúan sobre 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 cosa que pase por la página en tránsito. MDM no tiene visibilidad sobre nada de esto. 

La brecha de Vercel a principios de este año demostró 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 comprometido posteriormente por un infostealer, el atacante encontró el token OAuth almacenado y lo utilizó para acceder a los sistemas internos de Vercel. MDM no podría haber marcado esta extensión maliciosa porque fue instalada por el desarrollador, no por TI, y lo que hizo con los permisos que se le concedieron fue completamente invisible para MDM.

Lo que hace que las extensiones de navegador sean particularmente difíciles de gestionar es que se actualizan silenciosamente. 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 cada usuario con la auto-actualización habilitada la obtiene automáticamente. La brecha de Cyberhaven en 2024 siguió exactamente ese patrón. Un ataque de phishing a una cuenta de desarrollador provocó que se distribuyera una actualización maliciosa a todos los usuarios, activa durante 24 horas antes de que alguien la detectara.

Extensiones de IDE

De todo el software que instala un desarrollador, un plugin de VS Code es lo que más cerca está de las joyas de la corona. Se ejecuta directamente dentro del entorno de desarrollo, con más visibilidad sobre lo que hace un desarrollador que casi cualquier otra cosa en la máquina. Al igual que las extensiones de navegador, las extensiones de IDE son instaladas por los propios desarrolladores, se actualizan silenciosamente y no están en el campo de visión de MDM. La diferencia es que las extensiones de IDE pueden ver el código fuente y las credenciales.

La brecha de GitHub lo hizo evidente. El punto de entrada fue la extensión Nx Console de VS Code, una extensión de editor verificado con 2,2 millones de instalaciones que fue comprometida durante solo 18 minutos en el Visual Studio Marketplace. VS Code comprueba las actualizaciones de extensiones cada vez que el editor realiza una interacción con la galería, abre la barra lateral, busca en el marketplace o recupera metadatos en segundo plano, por lo que la versión maliciosa llegó automáticamente a los desarrolladores con el editor abierto durante esos 18 minutos, sin avisos ni advertencias. 3.800 de los repositorios internos de GitHub quedaron expuestos. MDM no tuvo ninguna participación en la detección de nada de esto.

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

Las herramientas de codificación de IA son ahora una parte estándar de cómo trabajan los desarrolladores. Cursor, GitHub Copilot, Claude Code y Windsurf realizan acciones, a menudo sin que un humano revise lo que se instala o dónde van los datos. Los equipos de seguridad que dependen de MDM están, en gran medida, a ciegas en todo esto.

Los servidores MCP amplían esto aún más al dar a los asistentes de IA la capacidad de interactuar con servicios externos. Y como cualquier dependencia, pueden ser comprometidos. En septiembre de 2025, el paquete npm postmark-mcp se convirtió en el primer servidor MCP malicioso confirmado en la naturaleza. Copiaba silenciosamente cada correo electrónico saliente a una dirección controlada por el atacante. El servidor MCP tenía quince versiones limpias antes de que la puerta trasera apareciera en la decimosexta.

Esta es una superficie de ataque completamente nueva, y la mayoría de los equipos de seguridad aún no la están rastreando.

¿Qué hay de EDR? 

Cuando los equipos de seguridad se dan cuenta de que MDM no es suficiente, la Detección y Respuesta de Endpoints (EDR) suele ser lo siguiente a lo que recurren. Herramientas como CrowdStrike y SentinelOne vigilan el comportamiento anómalo de los procesos, los cambios sospechosos en el sistema de archivos y las devoluciones de llamada de comando y control. Si el malware se está ejecutando activamente en una máquina, EDR tiene una probabilidad razonable de detectarlo.

El problema es que EDR opera después de la ejecución. Para cuando tiene algo que detectar, un hook de postinstalación malicioso ya se ha ejecutado, las credenciales ya han sido extraídas, y en el caso de Mini Shai-Hulud, los tokens robados ya estaban siendo utilizados para publicar la siguiente oleada de paquetes comprometidos. EDR no ve la instalación de npm. Ve un proceso que parece una actividad de desarrollo normal. Para entonces, ya es demasiado tarde.

Cómo cubrir las brechas

MDM y EDR tradicional no van a desaparecer, y no deberían hacerlo. El objetivo es superponer controles que cubran la superficie de ataque específica del desarrollador para la que nunca fueron diseñados.

Imponer una antigüedad mínima de los paquetes

Los paquetes nuevos son de 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 sus desarrolladores. Tanto la campaña Mini Shai-Hulud como el ataque Axios entregaron sus cargas útiles a través de paquetes publicados a las pocas horas de la vulneración. Una política de antigüedad mínima de 48 horas habría bloqueado ambos antes de que llegaran a una sola máquina de desarrollador. Cabe señalar que esto se aplica a npm y a los paquetes de dependencias de software generales. No ayuda con las extensiones de actualización automática, lo cual es un problema diferente.

Bloquear scripts postinstall por defecto

La mayoría de los equipos configuran --ignore-scripts en su pipeline para evitar que los hooks postinstall se ejecuten automáticamente. Menos equipos aplican la misma configuración por defecto a las máquinas de los desarrolladores. El gusano Mini Shai-Hulud entregó su carga útil a través de un hook postinstall. Si el entorno local de un desarrollador ejecuta scripts de instalación por defecto, ahí es donde reside la exposición. Puede configurar ignore-scripts=true en un archivo global .npmrc pero aplicarlo de forma consistente en todo un equipo sin herramientas es difícil.

Auditar extensiones de navegador e IDE

La mayoría de los equipos de seguridad no tienen ni idea de qué extensiones de VS Code o plugins de navegador están instalados en su flota de desarrolladores. Necesita visibilidad sobre qué está instalado, por quién y si se ha actualizado recientemente. Las brechas de GitHub y Vercel comenzaron con extensiones que nadie estaba monitorizando. Mantener una lista aprobada y aplicarla de forma centralizada es el objetivo, pero no es algo que se pueda hacer manualmente a escala.

Monitorizar lo que instalan las herramientas de codificación de IA

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

Utilizar herramientas dedicadas para endpoints de desarrollador

Los controles anteriores son difíciles de aplicar de forma consistente a escala o no cubren toda la superficie de ataque. Las herramientas dedicadas para endpoints de desarrollador están diseñadas específicamente para monitorizar las instalaciones de paquetes, la actividad de las extensiones y el comportamiento de las herramientas de IA a nivel de dispositivo en cada máquina de la flota.

Aikido Device Protection se despliega a través de su MDM existente y cubre registros de paquetes, extensiones de IDE, plugins de navegador y marketplaces de herramientas de IA. Cuando un desarrollador ejecuta npm i axios y la última versión se publicó hace una hora, Device Protection recurre a la versión más reciente que cumple con una política de antigüedad mínima de 48 horas. Las instalaciones seguras se realizan sin interrupción. Las maliciosas se bloquean antes de que lleguen a la máquina.

Está construido sobre Aikido Intel, que analiza más de 100.000 proyectos sospechosos al día. Si desea empezar sin un despliegue completo, Safe Chain es el punto de partida de código abierto. Si lo estaba ejecutando durante los ataques de Shai-Hulud, TeamPCP y Axios, estaba protegido.

MDM es necesario, no suficiente

Esto no es un argumento para reemplazar MDM. Hace lo que fue diseñado para hacer, y para la conformidad de dispositivos, la gestión de certificados y la demostración de control a sus auditores, sigue siendo la herramienta adecuada. Pero las máquinas de los desarrolladores se han convertido silenciosamente en una categoría diferente de endpoint, con una superficie de amenaza que no existía cuando se diseñó MDM.

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