Estações de trabalho de desenvolvedores se tornaram o alvo com maior ROI em ataques à Supply chain de software, e o problema está acelerando.
“Há uma métrica chave que me preocupa: nos últimos três meses, tivemos sete vezes mais vulnerabilidades em nossa Supply chain em comparação com os três meses anteriores”, diz Gavin Williams, Gerente de Engenharia no provedor da plataforma de procurement de IA Omnea.
“Estamos vendo cada vez mais problemas e questões em todos os registros, com mais ataques à Supply chain, mas também mais problemas sendo detectados por ferramentas de IA. É muito fácil para os desenvolvedores instalarem um pacote vulnerável ou algo que tenha sido comprometido”.
A indústria passou anos antecipando a segurança para o pipeline. No entanto, a própria superfície de ataque se deslocou ainda mais para a esquerda do que o pipeline, indo para as próprias máquinas.
Somente no ano passado, os atacantes entraram por diferentes portas: a recente violação do GitHub via uma extensão maliciosa do VS Code, Trivy via uma ferramenta de segurança, TanStack (mini Shai-Hulud) através de um gerenciador de pacotes, ataques do TeamPCP através de pacotes maliciosos, mas todos compartilham um fator chave. Eles estão visando o dispositivo do desenvolvedor. E está funcionando.
Mas por quê?
Gosto de pensar da seguinte forma: a maioria dos edifícios comerciais tem a porta da frente trancada com fechaduras, câmeras e afins. Mas também há uma entrada de funcionários nos fundos com uma porta corta-fogo aberta, porque as pessoas estão entrando e saindo o dia todo com entregas. Essa entrada de funcionários leva diretamente ao escritório com as chaves de todas as salas, que é efetivamente a estação de trabalho do desenvolvedor.
Até agora, as organizações e suas equipes de segurança não consideravam isso um risco de segurança porque “é apenas para eles”. É uma espécie de crença cega de que ninguém se incomodará porque não é para eles.
Mas se você é um atacante, literalmente não importa para quem a porta (ou, neste caso, o dispositivo) é destinada, faz sentido ir onde o atrito é o menor.
A lacuna entre o que o EDR vê e o que os desenvolvedores realmente instalam
Uma das principais razões para os ataques à Supply chain, segundo James Berthoty, fundador e analista da Latio, é que os endpoints de desenvolvedores ficam em grande parte sem monitoramento, pois as ferramentas tradicionais de detecção e gerenciamento não funcionam bem para seus casos de uso.
“As ferramentas EDR não são granulares, elas se concentram principalmente nos aplicativos ou programas instalados, em vez dos pacotes internos desse aplicativo permitido,” diz Walid Mahmoud, líder de DevSecOps no setor público do Reino Unido.
O EDR monitora atividades maliciosas no nível do aplicativo. Mas as organizações não conseguem ver o que está acontecendo dentro das ferramentas que os desenvolvedores usam diariamente, como os pacotes npm, as extensões IDE, os plugins do Chrome, as habilidades do Cursor.
Isso é importante, porque o problema começa antes mesmo de uma única linha de código ser escrita.
“Não se trata de pessoas implantando código inseguro em produção. Trata-se de, já na instalação, terem suas credenciais do GitHub expostas,” diz Gavin, da Omnea.
Por exemplo, um pacote malicioso pode executar um script pós-instalação e exfiltrar credenciais no momento em que um desenvolvedor o instala.
E, claro, seria um erro não mencionar como está se tornando trivialmente fácil criar malware graças aos LLMs. Steeven George, chefe de segurança de produto da Raisin, diz que esta era uma área que estava criando um “ponto cego” para sua organização, e ele não é o único.
Walid, do setor público do Reino Unido, explica o que a introdução da IA está fazendo: “Muitas pessoas estão vivendo no terminal agora, e estão instalando muitos arquivos markdown e outras coisas. No entanto, naturalmente, sem quaisquer processos verificados, não há nada que os impeça de baixar coisas que viram no Reddit ou no X. Isso pode fazer parte de uma campanha de malware para fazer com que as pessoas o baixem. E então - o resto é história.”
Parte do problema é que nenhuma equipe única é responsável pela interseção onde as máquinas de desenvolvedores estão, onde AppSec, segurança de endpoint, identidade e risco da supply chain se unem. E assim, tem sido mais fácil usar ferramentas como EDR e MDM para preencher o vazio sem realmente proteger as organizações dessas ameaças crescentes. Mas está ficando claro que isso não é mais viável. A desvantagem é estar no lado receptor de um ataque significativo à Supply chain (Essa é uma desvantagem considerável).
Como as equipes estão protegendo as máquinas de desenvolvedores contra ataques à Supply chain
Chris Holman, líder da equipe de engenheiros DevSecOps na empresa de cibersegurança Glasswall, implementou o Aikido Safe Chain em toda a infraestrutura da empresa.
“Qualquer pipeline de produção que toque em pacotes suportados agora é escaneado com o Safe Chain para garantir que não estamos instalando nada comprometido.”
Walid fez o mesmo em todo o departamento do setor público do Reino Unido.
“Adicionou uma etapa de validação que normalmente temos em nosso ciclo de vida de desenvolvimento de software, mas essa etapa de validação agora é local. Assim, temos um pouco mais de confiança de que os desenvolvedores têm algum tipo de barreira de proteção em sua máquina local que os questionará antes de instalarem algo.”
Mas os pacotes são apenas um ponto de entrada; a equipe de Gavin já estava usando o Safe Chain quando ele disse que perceberam a necessidade de uma visibilidade mais ampla em todo o dispositivo do desenvolvedor.
“Estávamos usando o Safe Chain até agora, mas ter uma maneira mais abrangente de gerenciar os dispositivos de todos e realmente verificar se as coisas não estão sendo instaladas de forma insegura será um verdadeiro divisor de águas,” disse Gavin.
Foi isso que levou várias dessas equipes ao Device Protection da Aikido, que estende o mesmo princípio além dos registros de pacotes para extensões IDE, plugins de navegador e ferramentas de IA.
Walid descreve-o como uma “versão aprimorada do Safe Chain”. Ele diz: “Nos dá a telemetria para saber o que os desenvolvedores estão usando ou o que tentaram instalar — nos dando mais contexto sobre quem é suscetível a um ataque”.
A equipe de Kristina na Cognism está planejando implementá-lo por razões semelhantes. “Nenhuma outra ferramenta atualmente tem esse tipo de cobertura. As ferramentas EDR não apresentam pacotes instalados nas máquinas de desenvolvedores, e as vulnerabilidades em extensões do Chrome não são cobertas por outros fornecedores. Definitivamente preencheremos essa lacuna.”
Steeven já o testou. “Estou muito feliz em ver a visão geral completa das extensões de navegador, extensões do Cursor e todos os registros de pacotes. Isso nos dá um modelo de ameaças geral para todas as nossas máquinas de desenvolvedores.”
Todas as equipes com quem falamos encontraram a mesma lacuna
O padrão nessas conversas foi consistente, entre líderes de segurança e engenharia de diferentes empresas, em diferentes setores, todos identificando independentemente a mesma lacuna. As máquinas de desenvolvedores ficam nas lacunas das ferramentas existentes, e os atacantes descobriram isso.
As equipes que já estão abordando isso começaram com controles em nível de pacote e agora estão expandindo para visibilidade total do dispositivo. Aquelas que ainda não começaram provavelmente estão executando a mesma configuração de EDR e MDM que não detectou todos os ataques mencionados neste artigo.
Descubra como o Device Protection funciona aqui ou experimente aqui.
