Tecnologia

Como o código malicioso entra no software de confiança através da cadeia de fornecimento

Susan Hill

Um ataque à cadeia de fornecimento não arromba o software que utiliza. Envenena uma das peças com que esse software é construído e depois espera que o processo normal de atualização o leve até à sua máquina. A aplicação instala-se sem problemas, a assinatura continua válida e a atualização chega pelo canal oficial. O código malicioso viaja com ela. É esta inversão que torna a técnica tão eficaz: transforma a confiança que faz o software funcionar no ponto que é explorado.

Quase nada do que executa hoje é escrito por inteiro pela empresa cujo nome aparece no ecrã. Uma só aplicação pode arrastar consigo centenas ou milhares de pacotes de código aberto, cada um mantido por desconhecidos e cada um com mais pacotes atrás. Os programadores raramente leem esse código; confiam no registo de onde veio e no número de versão que o acompanha. Quem se infiltra em qualquer elo dessa cadeia atinge de uma só vez todos os que estão a jusante, e por isso uma única peça envenenada pode afetar dezenas de milhares de projetos antes de alguém reparar.

Os pontos de entrada agrupam-se em poucos padrões. O typosquatting coloca um pacote malicioso com um nome a uma tecla de distância do popular e espera pelo erro de escrita. A confusão de dependências aproveita a forma como as ferramentas resolvem os nomes e engana-as para que apanhem um pacote público em vez do privado da empresa. O sequestro de contas apodera-se das credenciais de um verdadeiro responsável e distribui o malware como uma atualização de rotina; no início de 2026, o muito usado pacote axios chegou a publicar uma versão comprometida depois de a máquina do seu responsável principal ter sido violada por engenharia social. E o envenenamento da linha de montagem visa os sistemas automáticos que montam e publicam o software, onde um único passo corrompido atinge todos os projetos que dele dependem.

A linha de montagem tornou-se o alvo mais cobiçado precisamente por estar a montante de tudo o resto. Quando o popular componente do GitHub Actions tj-actions/changed-files foi comprometido em 2025, os atacantes reescreveram as suas etiquetas de versão para apontarem a código malicioso e retiraram segredos dos registos de compilação de mais de vinte mil repositórios: chaves de acesso, tokens e chaves privadas, tudo em texto simples. Uma campanha posterior, batizada de Megalodon pelos investigadores, transformou o GitHub Actions numa porta dos fundos capaz de se propagar sozinha, chegando a 5.561 repositórios em cerca de seis horas. A máquina que constrói o seu software pode ser subvertida com a mesma facilidade que o próprio software.

As ferramentas que os programadores usam todos os dias também estão na zona de impacto. O GlassWorm, detetado pela primeira vez no final de 2025, espalhou-se por extensões do Visual Studio Code nos mercados do OpenVSX e da Microsoft. Escondia a sua carga com caracteres Unicode invisíveis, de modo que as linhas maliciosas eram literalmente ilegíveis no editor e passavam a revisão humana. Uma vez instalado, roubava credenciais do npm, do GitHub e do Git e usava-as para infetar automaticamente mais pacotes e extensões, o traço que define um worm. Como os editores atualizam as extensões em segundo plano e em silêncio, as vítimas recebiam as versões envenenadas sem carregar em nada. Outra extensão envenenada do VS Code serviu para roubar cerca de 3.800 repositórios internos do próprio GitHub.

O que torna estes ataques tão difíceis de apanhar é que cada passo, isoladamente, parece legítimo. O pacote está assinado. A atualização vem do registo real. A conta do responsável é autêntica. As defesas tradicionais procuram ficheiros já conhecidos como nocivos e malware evidente, mas os ataques à cadeia de fornecimento escondem-se dentro de código de confiança, esperado e muitas vezes invisível, que chega exatamente quando e como o software deve chegar. Pior ainda: o conselho de segurança de sempre, atualizar de imediato, é precisamente o mecanismo de que o atacante depende. Pela primeira vez, instalar a versão mais recente não é, sem reservas, a opção segura.

Quem defende foi convergindo num punhado de práticas que funcionam. Os ficheiros de bloqueio fixam cada dependência a uma versão exata e verificada, para que o instalador descarregue apenas o que foi revisto, e não o mais recente. Desativar os scripts de instalação automáticos corta a via mais comum por onde um pacote malicioso executa código mal aterra. Fixar as GitHub Actions a um hash de commit concreto, em vez de uma etiqueta móvel, anula o truque de reescrever etiquetas. Uma lista de materiais do software, o inventário detalhado de cada componente dentro de uma compilação, permite a uma equipa saber em minutos se está exposta quando o próximo incidente é revelado. Muitas das organizações que escaparam aos ataques recentes não fizeram nada de exótico: compilavam a partir de um ficheiro de bloqueio confirmado e trabalhavam por trás de um proxy de registo que punha em quarentena os pacotes acabados de publicar.

Para quem não programa, a proteção é sobretudo indireta, mas a lição não é. A cadeia de fornecimento de software é hoje um campo de batalha de primeira linha, e são as empresas que constroem as aplicações do seu telemóvel e do seu portátil que têm de a proteger. A resposta sensata não é o pânico nem o velho reflexo de atualizar tudo assim que aparece um aviso. É preferir o software de equipas que tornam público o que entregam e como o constroem, e tratar a ideia de fonte de confiança como algo que tem de ser conquistado em cada elo, e não como uma propriedade que desce sozinha pela cadeia.

A resposta do setor está a ganhar forma em torno da proveniência: uma prova criptográfica de onde nasceu um pedaço de código e de como foi construído, verificada automaticamente antes de se instalar fosse o que fosse. É a mesma ideia que há uma geração tornou seguro o tráfego na web, aplicada agora à linha de montagem do próprio software. Até essa prova ser universal, cada instalação continua a ser um ato de confiança em pessoas que nunca irá conhecer.

Discussão

Existem 0 comentários.