As estações de trabalho dos programadores tornaram-se o alvo com maior retorno sobre o investimento ataques à Supply chain de software ataques à Supply chain, e o problema está a agravar-se.
«Há um indicador fundamental que me preocupa: nos últimos três meses, registámos sete vezes mais vulnerabilidades na nossa cadeia de abastecimento do que nos três meses anteriores», afirma Gavin Williams, diretor de engenharia da Omnea, fornecedora de uma plataforma de aquisição baseada em IA.
«À medida que o tempo passa, estamos a assistir a um aumento dos problemas e das falhas nos registos, com mais ataques à Supply chain também com mais falhas a serem detetadas por ferramentas de IA. É muito fácil para os programadores instalarem um pacote vulnerável ou algo que tenha sido comprometido».
O setor passou anos a antecipar a segurança ao longo do ciclo de desenvolvimento. No entanto, a própria superfície de ataque deslocou-se ainda mais para a fase inicial do ciclo, chegando a atingir as próprias máquinas.
Só no último ano, os atacantes entraram por diferentes vias: a recente violação do GitHub através de uma extensão maliciosa do VS Code, Trivy uma ferramenta de segurança, o TanStack (mini Shai-Hulud) através de um gestor de pacotes, os ataques do TeamPCP através de pacotes maliciosos, mas todos têm um fator comum. Estão a visar os dispositivos dos programadores. E está a funcionar.
Mas porquê?
Gosto de pensar nisso desta forma: a maioria dos edifícios comerciais tem a porta da frente bem trancada com fechaduras, câmaras e coisas do género. Mas há também uma entrada de serviço nas traseiras, cuja porta corta-fogo fica aberta, porque há pessoas a entrar e a sair o dia todo com entregas. Essa entrada de serviço leva diretamente ao escritório onde se guardam as chaves de todas as salas, que é, na prática, a estação de trabalho do programador.
Até agora, as organizações e as suas equipas de segurança não consideravam isto um risco de segurança porque «é apenas para eles». Trata-se de uma espécie de convicção cega de que ninguém se vai interessar pelo assunto, uma vez que não lhes diz respeito.
Mas se for um invasor, não importa, literalmente, a quem se destina a porta (ou, neste caso, o dispositivo); faz sentido ir para onde a resistência é menor.
A diferença entre o que o EDR deteta e o que os programadores instalam efetivamente
Uma das principais razões para ataques à Supply chain, segundo James Berthoty, fundador e analista da Latio, é o facto de os terminais dos programadores ficarem, em grande parte, sem vigilância, uma vez que as ferramentas tradicionais de deteção e gestão não funcionam bem para os seus casos de utilização.
«As ferramentas de EDR não são detalhadas; centram-se principalmente nas aplicações ou programas instalados, em vez de nos pacotes internos dessa aplicação autorizada», afirma Walid Mahmoud, DevSecOps no setor público do Reino Unido.
O EDR monitoriza atividades maliciosas ao nível das aplicações. No entanto, as organizações não conseguem ver o que se passa no interior das ferramentas que os programadores utilizam diariamente, como os pacotes npm, as extensões de IDE, os plug-ins do Chrome e as funcionalidades do Cursor.
Isto é importante, porque o problema começa antes mesmo de se escrever uma única linha de código.
«Não se trata de as pessoas implementarem código inseguro em ambiente de produção. Trata-se de, logo na fase de instalação, as credenciais do GitHub ficarem expostas», afirma Gavin, da Omnea.
Por exemplo, um pacote malicioso pode executar um script pós-instalação e roubar credenciais no momento em que um programador o instala.
E, claro, seria um erro não referir como se está a tornar cada vez mais fácil criar malware graças aos LLMs. Steeven George, responsável pela segurança de produtos na Raisin, afirma que esta era uma área que estava a criar um «ponto cego» para a sua organização, e ele não é o único.
Walid, do setor público do Reino Unido, explica o impacto da introdução da IA: «Muitas pessoas estão agora a trabalhar no terminal e a instalar inúmeros ficheiros Markdown e outros tipos de ficheiros. No entanto, naturalmente, sem quaisquer processos de verificação, nada as impede de descarregar coisas que viram no Reddit ou no X. Estas podem fazer parte de uma campanha de malware destinada a levar as pessoas a descarregá-las. E depois... o resto é história.»
Parte do problema reside no facto de não existir uma equipa específica responsável pela área onde se encontram os computadores dos programadores, onde AppSec, a segurança de terminais, a gestão de identidades e os riscos da cadeia de abastecimento se cruzam. Por isso, tem sido mais fácil utilizar ferramentas como EDR e MDM para preencher a lacuna sem realmente proteger as organizações contra estas ameaças crescentes. Mas está a tornar-se claro que isso já não é viável. A desvantagem é ser alvo de um ataque significativo à cadeia de abastecimento (o que é uma desvantagem e tanto).
Como as equipas estão a proteger os computadores dos programadores contra ataques à Supply chain
Chris Holman, chefe da equipa DevSecOps na empresa de cibersegurança Glasswall, implementou Aikido Chain em todo o ambiente da empresa.
«Qualquer pipeline de produção que envolva pacotes compatíveis é agora analisado com o Safe Chain para garantir que não estamos a instalar nada malicioso.»
Walid fez o mesmo em todos os departamentos do setor público do Reino Unido.
«Foi adicionada uma etapa de controlo que normalmente temos no nosso ciclo de vida de desenvolvimento de software, mas essa etapa é agora local. Assim, temos um pouco mais de confiança de que os programadores dispõem de uma espécie de barreira de segurança nas suas máquinas locais que os questionará antes de instalarem algo.»
Mas os pacotes são apenas um ponto de entrada; a equipa do Gavin já utilizava o Safe Chain quando ele afirmou que se aperceberam de que precisavam de uma visibilidade mais abrangente em todo o dispositivo de desenvolvimento.
«Até agora, temos utilizado o Safe Chain, mas dispor de uma forma mais abrangente de gerir os dispositivos de todos e verificar efetivamente se não estão a ser instalados programas de forma insegura vai ser uma verdadeira revolução», afirmou Gavin.
Foi isso que levou várias dessas equipas a adotarem a Proteção de DispositivosAikido, que alarga o mesmo princípio para além dos registos de pacotes, abrangendo extensões de IDE, plug-ins de navegador e ferramentas de IA.
Walid descreve-a como uma «versão reforçada do Safe Chain». Ele afirma: «Fornece-nos os dados de telemetria necessários para sabermos o que os programadores estão a utilizar ou o que tentaram instalar, dando-nos mais contexto sobre quem está suscetível a um ataque».
A equipa da Kristina na Cognism planeia implementar esta solução por motivos semelhantes. «Atualmente, nenhuma outra ferramenta oferece esse tipo de cobertura. As ferramentas EDR não mostram os pacotes instalados nos computadores dos programadores, e as vulnerabilidades nas extensões do Chrome não são abrangidas por outros fornecedores. Vamos, sem dúvida, colmatar essa lacuna.»
O Steeven já o testou. «Estou muito contente por ver uma visão geral completa das extensões do navegador, das extensões do Cursor e de todos os registos de pacotes. Isso dá-nos um modelo global de ameaças para todos os nossos computadores de desenvolvimento.»
Todas as equipas com quem falámos identificaram a mesma lacuna
O padrão observado nestas conversas foi consistente entre os responsáveis pela segurança e pela engenharia de diferentes empresas e setores, tendo todos identificado, de forma independente, a mesma lacuna. Os computadores dos programadores ficam nas frestas das ferramentas existentes, e os atacantes já perceberam isso.
As equipas que já estão a lidar com esta questão começaram com controlos ao nível dos pacotes e estão agora a expandir-se para uma visibilidade total dos dispositivos. As que ainda não começaram provavelmente utilizam a mesma configuração de EDR e MDM que não detetou nenhum dos ataques mencionados neste artigo.
Descubra como funciona a Proteção de Dispositivos aqui ou experimente-a aqui.
