O que o MDM não consegue proteger em máquinas de desenvolvedores (e o que fazer a respeito)

O Gerenciamento de Dispositivos Móveis (MDM) é um tipo de software usado por organizações para proteger, gerenciar e monitorar os dispositivos móveis de seus funcionários. Ferramentas como Jamf, Kandji e Microsoft Intune dão às equipes de TI visibilidade e controle sobre cada aplicativo autorizado em toda a frota. Para frameworks de conformidade como SOC 2 ou ISO 27001, o MDM é frequentemente um componente central de como você demonstra controle de dispositivos e garante a segurança dos dados. Se o seu MDM estiver implantado, parabéns, você resolveu o desafio de segurança BYOD de 2012.

O problema é que a superfície de ataque do desenvolvedor moderno superou silenciosamente o que o MDM foi projetado para lidar. Quando as máquinas de desenvolvedores são comprometidas, o ponto de entrada raramente é o sistema operacional ou algo implantado pela TI. Recentemente, uma extensão maliciosa do VS Code instalada no dispositivo de um desenvolvedor permitiu que um invasor violasse o GitHub, expondo milhares de repositórios internos. Antes disso, o worm npm Mini Shai-Hulud comprometeu mais de 160 pacotes, incluindo Mistral e TanStack, ao roubar credenciais de máquinas de desenvolvedores. Dispositivos de desenvolvedores são o alvo número um para invasores, e o MDM ainda não está ciente. 

Este post abordará onde estão os pontos cegos do MDM, o que o EDR também não detecta e como garantir que seus dispositivos de desenvolvedores estejam realmente protegidos.

Como o MDM funciona e onde ele para

O MDM opera na camada de sistema operacional e de aplicativos. Na prática, isso significa enviar atualizações de sistema operacional, aplicar políticas de senha, gerenciar certificados, impor criptografia de disco, manter um inventário de aplicativos instalados e ter uma opção de limpeza remota para dispositivos perdidos ou roubados. Para aplicativos implantados através de mecanismos padrão do sistema operacional, como a App Store, implantações de software corporativo e binários assinados enviados por meio de um console de gerenciamento, o MDM funciona bem.

Os pontos cegos abaixo compartilham a mesma causa raiz. Gerenciadores de pacotes como npm e pip são ferramentas de espaço de usuário. Eles puxam software de registros com os quais o MDM não tem relacionamento, para diretórios de projeto nos quais o MDM não tem visibilidade, acionados por comandos executados no shell de um desenvolvedor. O mesmo se aplica a extensões de IDE instaladas através de um marketplace, plugins de navegador e ferramentas de IA. Nenhum desses passa pelos mecanismos de instalação em nível de sistema operacional que o MDM monitora.

O que o MDM não detecta 

Registros de pacotes 

O MDM sabe quais aplicativos a TI aprovou e implantou, mas não tem visibilidade sobre o que um desenvolvedor puxa de um registro de pacotes. Isso é importante porque os pacotes executam código no momento da instalação através de hooks de ciclo de vida antes que suas ferramentas de segurança tenham qualquer chance de reagir. Quando um pacote malicioso executa sua carga útil, ele já pode ter extraído credenciais da máquina do desenvolvedor. O worm Mini Shai-Hulud funcionou exatamente dessa forma, roubando silenciosamente tokens npm e GitHub, e então usando-os para publicar versões maliciosas do próximo pacote na cadeia.

Ferramentas de codificação de IA adicionaram uma nova reviravolta a isso. Modelos de IA alucinam nomes de pacotes, e invasores os registram antes que alguém perceba. Um desenvolvedor pede a uma ferramenta de codificação de IA para adicionar uma dependência, a ferramenta sugere com confiança um pacote que não existe, e um invasor já reivindicou esse nome no npm com uma carga útil maliciosa dentro. O MDM não detecta a instalação de qualquer forma. 

Extensões de navegador

Embora grande parte do trabalho de um desenvolvedor resida no navegador, a maioria das equipes de segurança não está suficientemente preocupada com isso. GitHub, consoles Cloud, dashboards de CI/CD e ferramentas internas ficam abertos e autenticados o dia todo. Extensões de navegador ficam sobre esse ambiente com permissões que a maioria das pessoas concede sem pensar duas vezes. Uma extensão com acesso a todos os sites pode ler tudo o que o navegador carrega, incluindo sessões autenticadas e qualquer coisa que passe pela página em trânsito. O MDM não tem visibilidade sobre nada disso. 

A violação da Vercel no início deste ano mostrou o quão rapidamente isso se torna um problema. Um funcionário da Vercel instalou uma extensão do Chrome e concedeu a ela acesso OAuth ao seu Google Workspace. Quando o dispositivo de um funcionário da Context.ai foi posteriormente comprometido por um infostealer, o invasor encontrou o token OAuth armazenado e o usou para acessar os sistemas internos da Vercel. O MDM não poderia ter sinalizado esta extensão maliciosa porque ela foi instalada pelo desenvolvedor, não pela TI, e o que ela fez com as permissões concedidas era completamente invisível para o MDM.

O que torna as extensões de navegador particularmente difíceis de gerenciar é que elas se atualizam silenciosamente. Uma extensão que estava limpa na instalação pode receber uma atualização maliciosa durante a noite, e todo usuário com atualização automática habilitada a recebe automaticamente. A violação da Cyberhaven em 2024 seguiu exatamente esse padrão. Um ataque de phishing a uma conta de desenvolvedor levou a uma atualização maliciosa sendo enviada a todos os usuários, ativa por 24 horas antes que alguém a detectasse.

Extensões de IDE

De todo o software que um desenvolvedor instala, um plugin do VS Code está mais próximo dos ativos mais valiosos. Ele é executado diretamente dentro do ambiente de desenvolvimento, com mais visibilidade sobre o que um desenvolvedor está fazendo do que quase qualquer outra coisa na máquina. Assim como as extensões de navegador, as extensões de IDE são instaladas pelos próprios desenvolvedores, atualizam-se silenciosamente e não estão no campo de visão do MDM. A diferença é que as extensões de IDE podem ver código-fonte e credenciais.

A violação do GitHub tornou isso concreto. O ponto de entrada foi a extensão Nx Console VS Code, uma extensão de editor verificado com 2,2 milhões de instalações que foi comprometida por apenas 18 minutos no Visual Studio Marketplace. O VS Code verifica atualizações de extensão toda vez que o editor interage com a galeria, abre a barra lateral, faz uma busca no marketplace ou busca metadados em segundo plano, então a versão maliciosa atingiu os desenvolvedores com o editor aberto durante esses 18 minutos automaticamente, sem aviso ou prompt. 3.800 dos repositórios internos do GitHub foram expostos. O MDM não teve participação na detecção de nada disso.

Ferramentas de IA, servidores MCP e agentes de codificação

Ferramentas de codificação de IA são agora uma parte padrão de como os desenvolvedores trabalham. Cursor, GitHub Copilot, Claude Code e Windsurf executam ações, muitas vezes sem revisão humana sobre o que é instalado ou para onde os dados vão. Equipes de segurança que dependem de MDM estão, em grande parte, agindo às cegas em relação a tudo isso.

Servidores MCP estendem isso ainda mais, dando aos assistentes de IA a capacidade de interagir com serviços externos. E, como qualquer dependência, eles podem ser comprometidos. Em setembro de 2025, o pacote npm postmark-mcp tornou-se o primeiro servidor MCP malicioso confirmado em atividade. Ele copiou silenciosamente, com cópia oculta, todos os e-mails enviados para um endereço controlado por um atacante. O servidor MCP teve quinze versões limpas antes que o backdoor aparecesse na décima sexta.

Esta é uma superfície de ataque totalmente nova, e a maioria das equipes de segurança ainda não está monitorando-a.

E o EDR? 

Quando as equipes de segurança percebem que o MDM não é suficiente, Endpoint Detection and Response (EDR) é geralmente a próxima solução que buscam. Ferramentas como CrowdStrike e SentinelOne monitoram comportamentos de processo anômalos, alterações suspeitas no sistema de arquivos e callbacks de comando e controle. Se um malware estiver em execução ativa em uma máquina, o EDR tem uma chance razoável de detectá-lo.

O problema é que o EDR opera após a execução. Quando ele tem algo para detectar, um hook de pós-instalação malicioso já foi executado, credenciais já foram coletadas e, no caso do Mini Shai-Hulud, tokens roubados já estavam sendo usados para publicar a próxima onda de pacotes comprometidos. O EDR não vê um `npm install`. Ele vê um processo que parece uma atividade de desenvolvimento normal. Até lá, é tarde demais.

Como preencher as lacunas

MDM e EDR tradicionais não vão desaparecer, e nem deveriam. O objetivo é adicionar camadas de controle sobre eles que cubram a superfície de ataque específica do desenvolvedor para a qual eles nunca foram construídos.

Impor uma idade mínima para pacotes

Novos pacotes são de alto risco. Uma política de idade mínima de 48 horas bloqueia typosquatting no mesmo dia e campanhas de malware de rápida propagação antes que atinjam seus desenvolvedores. A campanha Mini Shai-Hulud e o ataque Axios entregaram suas cargas úteis através de pacotes publicados horas após o comprometimento. Uma política de idade mínima de 48 horas teria bloqueado ambos antes que atingissem uma única máquina de desenvolvedor. Vale ressaltar que isso se aplica a pacotes npm e dependências de software em geral. Não ajuda com extensões de atualização automática, o que é um problema diferente.

Bloquear scripts de pós-instalação por padrão

A maioria das equipes configura --ignore-scripts em seu pipeline para bloquear a execução automática de hooks de pós-instalação. Menos equipes aplicam o mesmo padrão às máquinas dos desenvolvedores. O worm Mini Shai-Hulud entregou sua carga útil através de um hook de pós-instalação. Se o ambiente local de um desenvolvedor executa scripts de instalação por padrão, é aí que está a exposição. Você pode definir ignore-scripts=true em um arquivo global .npmrc , mas impor isso de forma consistente em toda uma equipe sem ferramentas é difícil.

Auditar extensões de navegador e IDE

A maioria das equipes de segurança não tem ideia de quais extensões do VS Code ou plugins de navegador estão instalados em sua frota de desenvolvedores. É preciso ter visibilidade sobre o que está instalado, por quem e se foi atualizado recentemente. As violações do GitHub e da Vercel começaram com extensões que ninguém estava monitorando. Manter uma lista aprovada e aplicá-la centralmente é o objetivo, mas não é algo que se possa fazer manualmente em escala.

Monitorar o que as ferramentas de codificação de IA instalam

Desenvolvedores estão usando Cursor, Claude Code, Copilot e uma lista crescente de servidores MCP, muitas vezes sem o conhecimento das equipes de segurança. A Shadow AI é real. Não se pode governar o que não se vê, e ferramentas de IA que instalam pacotes autonomamente sem revisão humana são uma parte ativa da sua superfície de ataque.

Usar ferramentas dedicadas para endpoints de desenvolvedor

Os controles acima são difíceis de serem aplicados consistentemente em escala ou não cobrem toda a superfície de ataque. Ferramentas dedicadas para endpoints de desenvolvedor são construídas especificamente para monitorar instalações de pacotes, atividade de extensões e comportamento de ferramentas de IA no nível do dispositivo em todas as máquinas da frota.

Aikido Device Protection é implantado através do seu MDM existente e cobre registros de pacotes, extensões de IDE, plugins de navegador e marketplaces de ferramentas de IA. Quando um desenvolvedor executa npm i axios e a versão mais recente foi publicada há uma hora, a Proteção de Dispositivo reverte para a versão mais recente que satisfaz uma política de idade mínima de 48 horas. Instalações seguras prosseguem sem interrupção. As maliciosas são bloqueadas antes de chegarem à máquina.

É construído sobre Aikido Intel, que analisa mais de 100.000 projetos suspeitos por dia. Se você quiser começar sem uma implantação completa, Safe Chain é o ponto de partida de código aberto. Se você o estivesse executando durante os ataques Shai-Hulud, TeamPCP e Axios, você estaria protegido.

MDM é necessário, não suficiente

Este não é um argumento para substituir o MDM. Ele faz o que foi construído para fazer, e para conformidade de dispositivos, gerenciamento de certificados e demonstração de controle aos seus auditores, ainda é a ferramenta certa. Mas as máquinas de desenvolvedores tornaram-se silenciosamente uma categoria diferente de endpoint, com uma superfície de ameaça que não existia quando o MDM foi projetado.

A pergunta que a maioria das equipes de segurança deveria fazer é o que acontece entre a política de MDM e a instalação do pacote.

‍