O site Ars Technica reporta que um desenvolvedor foi pego adicionando código malicioso a um popular pacote de código aberto que apagou arquivos em computadores localizados na Rússia e na Bielorrússia como parte de um protesto que enfureceu muitos usuários e levantou preocupações sobre a segurança do software livre e de código aberto.

O aplicativo, node-ipc, adiciona a um sistema recursos de comunicação e redes neurais a outras bibliotecas de código aberto. Por ser uma dependência de outro programa, o node-ipc é baixado automaticamente e incorporado a outras bibliotecas, incluindo algumas como Vue.js CLI, que possui mais de 1 milhão de downloads semanais.
A atualização espúria do node-ipc é apenas um exemplo do que alguns pesquisadores estão chamando de protestware. Especialistas começaram a rastrear outros projetos de código aberto que também estão lançando atualizações chamando a atenção para a brutalidade da guerra da Rússia. Esta planilha lista 21 pacotes diferentes que são afetados.
Um desses pacotes é o es5-ext, que fornece código para a especificação da linguagem de script ECMAScript 6. Uma nova dependência chamada postinstall.js, que o desenvolvedor adicionou em 7 de março, verifica se o computador do usuário tem um endereço IP russo. Em caso positivo o código transmite uma “mensagem de paz”.

As pessoas que não trabalham no ramo talvez se surpreendam com a grande quantidade de software crítico que depende dos caprichos de programadores anônimos que mantêm bibliotecas de software de forma inconsistente, como hobby ou projeto secundário. Repetidas ocorrências estão transformando isso em uma vulnerabilidade séria. A Casa Branca anunciou no ano passado uma iniciativa para começar a resolver esse problema, declarando que vai passar a exigir uma “lista de materiais de software” para todo software encomendado pelo governo:
…o termo “Lista de Materiais de Software” ou “LMDS” significa um registro formal contendo os detalhes e relacionamentos da cadeia de suprimentos de vários componentes usados na construção de software. Desenvolvedores e fornecedores de software geralmente criam produtos montando e mesclando componentes de software comercial e de código aberto dos repositórios existentes. A LMDS enumera esses componentes em um determinado produto. É análogo a uma lista de ingredientes em embalagens de alimentos. Uma LMDS é útil para quem desenvolve ou fabrica software, para quem seleciona ou compra software e para quem opera software. Os desenvolvedores geralmente usam componentes de software de código aberto e de terceiros disponíveis para criar um produto; uma LMDS permite que o desenvolvedor certifique-se de que os componentes de terceiros usados em seus projetos estejam atualizados e responda rapidamente a novas vulnerabilidades. Por exemplo, os compradores podem usar uma LMDS para realizar análise de vulnerabilidade ou licença. Aqueles que operam software podem usar LMDSs para determinar facilmente se estão em risco potencial de uma vulnerabilidade recém-descoberta. Um formato LMDS universal, legível por máquina, que seja amplamente utilizado, permite maiores benefícios por meio da automação e integração de ferramentas. Os LMDSs ganham maior valor quando armazenados coletivamente em um repositório que pode ser facilmente consultado por outros aplicativos e sistemas. Compreender a cadeia de suprimentos de software, obter um LMDS e usá-lo para analisar vulnerabilidades conhecidas são cruciais no gerenciamento de riscos.
Fornecedores governamentais
Vários empreiteiros de defesa em todo o mundo usam recursos de código aberto em todos os tipos de aplicativos implantados em sistemas militares, desde comunicações, navegação, controle de voo, controle de fogo e aplicativos de missão crítica.
Grande parte do código que é modificado ou adicionado nos repositórios de código aberto está dentro do contexto de aplicativos seguros. A questão, porém, é qual o nível de exposição dos sistemas de missão crítica e outros sistemas vulneráveis a esse problema? Qual o componente de risco/recompensa mais aparente nessa escalada interminável de guerra de códigos? Talvez estejamos diante da necessidade de um acordo de não proliferação de armas cibernéticas entre estados-nações.
Bom começo…
Uma LMDS é apenas uma boa prática. Os projetos de desenvolvimento bem executados sempre devem ter uma lista de requerimentos de sistema para gerenciar dependências e atualizações. Algumas licenças, a GPL e a LGPL em particular, exigem implicitamente uma licença parcial na medida em que exigem a identificação dos componentes GPL para o destinatário. Estabelecer uma lista de requerimentos que possa ser compartilhada não é um um problema complicado e é um bom começo.
...mas não suficiente
A dimensão do problema está muito além de uma Lista de Materiais. Um grande número de desenvolvedores executa muitos pacotes de software que são atualizados em massa, ou muitas vezes atualizados automaticamente a partir de uma ampla variedade de “fornecedores” em vários países.
No mundo do código aberto, instalamos chaves para os gerenciadores de repositórios (como o Ubuntu) que, em teoria, assinam os pacotes destinados ao download pelos usuários após verificá-los, mas na verdade não os verificam. Portanto, quando o desenvolvedor oficial autorizado de um pacote deseja inserir malware em seu pacote, pouco ou nada pode detê-lo. É uma violação de confiança que pode resultar em punição – uma punição que virá após o fato.
O desenvolvedor do qual falamos aqui atacou indiscriminadamente tanto civis como alvos legítimos em sua sanha de justiça – talvez tenha até cometido um crime de guerra. O que aconteceria se ele tivesse codificado seu programa para atingir alvos militares sensíveis no contexto geral das relações Leste-Oeste? E se fosse o próprio computador de Putin?
Nenhuma regra vai parar isso. Se o seu país estiver em uma guerra (uma que ele começou ou para a qual foi arrastado), você deve considerar que qualquer atualização de software em seu sistema vem de um adversário – ou de uma fonte que pode ser comprometida pelo seu adversário. Essa é a realidade da guerra.