O que o MDM não consegue proteger nos computadores dos programadores (e o que fazer a esse respeito)

A Gestão de Dispositivos Móveis (MDM) é um tipo de software utilizado pelas organizações para proteger, gerir e monitorizar os dispositivos móveis dos seus colaboradores. Ferramentas como Jamf, Kandji e Microsoft Intune proporcionam às equipas de TI visibilidade e controlo sobre todas as aplicações autorizadas em toda a frota. No que diz respeito a estruturas de conformidade como SOC 2 ou ISO 27001, o MDM é frequentemente um componente essencial para demonstrar o controlo dos dispositivos e garantir a segurança dos dados. Se o seu MDM já estiver implementado, parabéns, resolveu o desafio de segurança BYOD de 2012.

O problema é que a superfície de ataque dos programadores modernos ultrapassou, discretamente, o que o MDM foi concebido para gerir. Quando os computadores dos programadores são comprometidos, o ponto de entrada raramente é o sistema operativo ou qualquer elemento implementado pela equipa de TI. Recentemente, uma extensão maliciosa do VS Code instalada no dispositivo de um programador permitiu que um atacante invadisse o GitHub, expondo milhares de repositórios internos. Antes disso, o worm npm Mini Shai-Hulud comprometeu mais de 160 pacotes, incluindo o Mistral e o TanStack, roubando credenciais das máquinas dos programadores. Os dispositivos dos programadores são o alvo número um dos atacantes e, no entanto, o MDM continua sem perceber nada. 

Este artigo irá abordar quais são os pontos cegos do MDM, o que o EDR também não consegue detetar e como garantir que os dispositivos dos seus programadores estão realmente protegidos.

Como funciona o MDM e quais são os seus limites

O MDM opera ao nível do sistema operativo e das aplicações. Na prática, isso significa instalar atualizações do sistema operativo, aplicar políticas de palavras-passe, gerir certificados, aplicar encriptação de disco, manter um inventário das aplicações instaladas e ter sempre à disposição a opção de apagamento remoto para dispositivos perdidos ou roubados. No caso de aplicações implementadas através de mecanismos padrão do sistema operativo, como a App Store, implementações de software empresarial e ficheiros binários assinados instalados através de uma consola de gestão, o MDM funciona bem.

Os pontos cegos abaixo têm todos a mesma causa subjacente. Gestores de pacotes como o npm e o pip são ferramentas do espaço do utilizador. Eles descarregam software de registos com os quais o MDM não tem qualquer relação, para diretórios de projeto sobre os quais o MDM não tem visibilidade, acionados por comandos executados no shell de um programador. O mesmo se aplica a extensões de IDE instaladas através de uma loja online, plug-ins de navegador e ferramentas de IA. Nenhum destes passa pelos mecanismos de instalação ao nível do sistema operativo que o MDM monitoriza.

O que falta ao MDM 

Registos de pacotes 

O MDM sabe quais as aplicações que o departamento de TI aprovou e implementou, mas não tem visibilidade sobre o que um programador obtém de um registo de pacotes. Isto é importante porque os pacotes executam código no momento da instalação, através de ganchos de ciclo de vida, antes que as suas ferramentas de segurança tenham qualquer oportunidade de reagir. Quando um pacote malicioso executa a sua carga útil, pode já ter roubado credenciais da máquina do programador. O worm Mini Shai-Hulud funcionava exatamente assim, roubando silenciosamente tokens do npm e do GitHub e, em seguida, utilizando-os para publicar versões maliciosas do pacote seguinte na cadeia.

As ferramentas de programação baseadas em IA trouxeram uma nova reviravolta a esta situação. Os modelos de IA inventam nomes de pacotes, e os atacantes registam-nos antes que alguém se aperceba. Um programador pede a uma ferramenta de programação baseada em IA para adicionar uma dependência; a ferramenta sugere com toda a confiança um pacote que não existe, e um atacante já reivindicou esse nome no npm com uma carga maliciosa no seu interior. O MDM não deteta a instalação, seja qual for o caso. 

Extensões do navegador

Embora grande parte do trabalho de um programador se realize no navegador, a maioria das equipas de segurança não se preocupa o suficiente com isso. O GitHub, as consolas na nuvem, os painéis de CI/CD e as ferramentas internas ficam abertos e autenticados durante todo o dia. As extensões do navegador funcionam nesse 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 disto. 

A violação de segurança da Vercel no início deste ano demonstrou a rapidez com que isto se torna um problema. Um funcionário da Vercel instalou uma extensão do Chrome e concedeu-lhe acesso OAuth ao seu Google Workspace. Quando o dispositivo de um funcionário da Context.ai foi posteriormente comprometido por um infostealer, o atacante encontrou o token OAuth armazenado e utilizou-o para aceder aos sistemas internos da Vercel. O MDM não poderia ter sinalizado esta extensão maliciosa porque foi instalada pelo programador, e não pela equipa de TI, e o que ela fez com as permissões que lhe foram concedidas era completamente invisível para o MDM.

O que torna as extensões do navegador particularmente difíceis de gerir é o facto de serem atualizadas silenciosamente. Uma extensão que estava limpa no momento da instalação pode receber uma atualização maliciosa da noite para o dia, e todos os utilizadores com a atualização automática ativada recebem-na automaticamente. A violação da Cyberhaven em 2024 seguiu exatamente esse padrão. Um ataque de phishing a uma conta de programador levou à distribuição de uma atualização maliciosa a todos os utilizadores, que permaneceu ativa durante 24 horas antes de alguém a detetar.

Extensões de IDE

De todo o software que um programador instala, um plugin do VS Code é o que mais se aproxima das joias da coroa. Funciona diretamente dentro do ambiente de desenvolvimento, com maior visibilidade sobre o que o programador está a fazer do que praticamente qualquer outra coisa no computador. Tal como as extensões do navegador, as extensões do IDE são instaladas pelos próprios programadores, atualizam-se silenciosamente e não estão de todo no campo de visão do MDM. A diferença é que as extensões do IDE têm acesso ao código-fonte e às credenciais.

A violação do GitHub tornou isto evidente. O ponto de entrada foi a extensão Nx Console para o VS Code, uma extensão de um editor verificado com 2,2 milhões de instalações, que ficou comprometida durante apenas 18 minutos no Visual Studio Marketplace. O VS Code verifica se há atualizações de extensões sempre que o editor interage com a galeria, abre a barra lateral, faz uma pesquisa no marketplace ou obtém metadados em segundo plano; assim, a versão maliciosa chegou automaticamente aos programadores que tinham o editor aberto durante esses 18 minutos, sem qualquer aviso ou notificação. 3.800 repositórios internos do GitHub ficaram expostos. O MDM não teve qualquer papel na deteção de nada disso.

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

As ferramentas de programação baseadas em IA são hoje parte integrante do dia-a-dia dos programadores. O Cursor, o GitHub Copilot, o Claude Code e o Windsurf executam ações, muitas vezes sem que um ser humano verifique o que é instalado ou para onde vão os dados. As equipas de segurança que dependem de sistemas de gestão de dispositivos móveis (MDM) estão, em grande parte, a agir às cegas em relação a tudo isto.

Os servidores MCP vão ainda mais longe, ao permitirem que os assistentes de IA interajam com serviços externos. E, tal como qualquer dependência, podem ser comprometidos. Em setembro de 2025, o pacote npm «postmark-mcp» tornou-se o primeiro servidor MCP malicioso confirmado em circulação. Este enviava silenciosamente uma cópia oculta de todos os e-mails enviados para um endereço controlado pelo atacante. O servidor MCP teve quinze versões limpas antes de a porta traseira ter surgido na décima sexta.

Trata-se de uma nova superfície de ataque, e a maioria das equipas de segurança ainda não a está a monitorizar.

E quanto ao EDR? 

Quando as equipas de segurança percebem que o MDM não é suficiente, a Detecção e Resposta em Terminais (EDR) é normalmente a solução a que recorrem em seguida. Ferramentas como CrowdStrike SentinelOne comportamentos anómalos de processos, alterações suspeitas no sistema de ficheiros e chamadas de comando e controlo. Se houver malware a ser executado ativamente numa máquina, o EDR tem boas hipóteses de o detetar.

O problema é que o EDR entra em ação após a execução. Quando chega a altura de detetar algo, um gancho malicioso pós-instalação já foi executado, as credenciais já foram roubadas e, no caso do Mini Shai-Hulud, os tokens roubados já estavam a ser utilizados para publicar a próxima vaga de pacotes comprometidos. O EDR não deteta o comando «npm install». O que vê é um processo que se assemelha a uma atividade normal de desenvolvimento. Nessa altura, já é tarde demais.

Como colmatar as lacunas

O MDM e o EDR tradicional não vão desaparecer, nem devem. O objetivo é adicionar camadas de controlo que abranjam a superfície de ataque específica dos programadores, para a qual nunca foram concebidos.

Exigir uma idade mínima para a aquisição do pacote

Os novos pacotes representam um risco elevado. Uma política de idade mínima de 48 horas bloqueia o typosquatting no próprio dia e as campanhas de malware de rápida propagação antes de estas chegarem aos seus programadores. Tanto a campanha Mini Shai-Hulud como o ataque à Axios distribuíram as suas cargas maliciosas através de pacotes publicados poucas horas após a violação. Uma política de idade mínima de 48 horas teria bloqueado ambos antes de chegarem a uma única máquina de um programador. Vale a pena notar que isto se aplica ao npm e aos pacotes de dependências de software em geral. Não ajuda com extensões de atualização automática, o que é um problema diferente.

Bloquear scripts pós-instalação por predefinição

A maioria das equipas configura --ignorar-scripts no seu processo para impedir que os ganchos pós-instalação sejam executados automaticamente. São poucos os que aplicam essa configuração padrão aos computadores dos programadores. O worm Mini Shai-Hulud disseminou a sua carga maliciosa através de um gancho pós-instalação. Se o ambiente local de um programador executar scripts de instalação por predefinição, é aí que reside o risco. Pode definir ignore-scripts=true a nível global .npmrc , mas é difícil aplicá-lo de forma consistente em toda a equipa sem o apoio de ferramentas.

Verificar extensões do navegador e do IDE

A maioria das equipas de segurança não faz ideia de quais as extensões do VS Code ou os plugins de navegador que estão instalados nos computadores dos seus programadores. É necessário ter uma visão clara do que está instalado, por quem e se foi atualizado recentemente. As violações de segurança do GitHub e da Vercel começaram ambas com extensões que ninguém estava a monitorizar. O objetivo é manter uma lista de extensões aprovadas e garantir a sua aplicação de forma centralizada, mas isso não é algo que se possa fazer manualmente em grande escala.

Monitorizar o que as ferramentas de programação com IA instalam

Os programadores estão a utilizar o Cursor, o Claude Code, o Copilot e uma lista cada vez maior de servidores MCP, muitas vezes sem que as equipas de segurança tenham conhecimento. A IA oculta é uma realidade. Não é possível controlar o que não se vê, e as ferramentas de IA que instalam pacotes de forma autónoma, sem revisão humana, constituem uma parte ativa da sua superfície de ataque.

Utilizar ferramentas específicas para pontos de extremidade de desenvolvimento

As medidas de controlo acima referidas são difíceis de aplicar de forma consistente em grande escala ou não abrangem toda a superfície de ataque. As ferramentas dedicadas aos terminais dos programadores são concebidas especificamente para monitorizar a instalação de pacotes, a atividade das extensões e o comportamento das ferramentas de IA ao nível do dispositivo em todas as máquinas da frota.

Proteção Aikido é implementado através do seu MDM existente e abrange registos de pacotes, extensões de IDE, plug-ins de navegador e mercados de ferramentas de IA. Quando um programador executa npm i axios e, como a versão mais recente foi publicada há uma hora, a Proteção de Dispositivos recorre à versão mais recente que cumpre a política de idade mínima de 48 horas. As instalações seguras são realizadas sem interrupção. As maliciosas são bloqueadas antes de chegarem ao dispositivo.

É baseado no Aikido , que analisa mais de 100 000 projetos suspeitos por dia. Se quiser começar sem uma implementação completa, o Safe Chain é o ponto de partida de código aberto. Se o estivesse a utilizar durante os ataques Shai-Hulud, TeamPCP e Axios, estaria protegido.

O MDM é necessário, mas não suficiente

Isto não é um argumento a favor da substituição do MDM. Ele cumpre a função para a qual foi concebido e, no que diz respeito à conformidade dos dispositivos, à gestão de certificados e à demonstração de controlo aos auditores, continua a ser a ferramenta adequada. No entanto, os computadores dos programadores tornaram-se, discretamente, uma categoria diferente de terminais, com uma superfície de ataque que não existia quando o MDM foi concebido.

A questão que a maioria das equipas de segurança deveria colocar é o que acontece entre a política de MDM e a instalação do pacote.

‍