O estado dos projetos
Projetos antigos e populares, e que não são mais mantidos e esquecidos, costumam ser usados como vetor para espalhar vírus, se alguém puder comprometer a conta e carregar uma nova versão compilada. O mesmo tem sido feito com os sistemas de atualização automática - ainda pior, porque eles se entregam e instalam uma atualização nos sistemas dos usuários sem que o usuário final saiba.
Possíveis ações a serem tomadas
Mantenedores e Desenvolvedores
Você pode tentar entrar em contato com os desenvolvedores / mantenedores, mas se for um projeto antigo, é improvável que eles respondam. Se a conta deles tiver sido comprometida, você será avisado ou deixado gritando contra uma parede.
Plataforma / Rede de Entrega
Você pode ter uma chance melhor de remover o código malicioso entrando em contato com a plataforma que hospeda o software. Eu mesmo não tentei entrar em contato diretamente com uma plataforma como Sourceforge ou NPM. A probabilidade de você receber uma resposta de volta geralmente está ligada ao tamanho da empresa e se ela foi monetizada - se é uma demonstração de uma pessoa, então boa sorte!
Quanto mais informações você tiver para verificar sua solicitação de remoção, mais provável e rapidamente ela deverá ocorrer.
A comunidade e sua voz
Freqüentemente, você pode tentar as etapas acima e se sentir impotente, mas se puder deixar um comentário ou uma revisão do software, essa pode ser a melhor coisa que você pode fazer. Mesmo que muitos usuários finais ainda façam o download cegamente ou confiem anteriormente no software.
Extra: Prevenção recente e futura
Pare de ler aqui ™ ou continue ¯\_(ツ)_/¯
Havia um pacote NPM altamente usado com o qual o mantenedor original era finalizado - como muitos projetos de código aberto alcançam em seu ciclo de vida. Alguém estendeu a mão pedindo para mantê-lo. Certamente isso deve parecer um fardo incômodo levantado dos ombros de um desenvolvedor. Infelizmente, o novo mantenedor lançou malware para roubar carteiras de criptografia .
Ironicamente, ouvi falar sobre isso através do boca a boca e lendo o problema aberto no repositório do github antes de ler um artigo sobre ele ou vê-lo aparecer no npm audit. Isso mostra que sua voz em uma plataforma pública realmente pode ter um impacto .
Nosso grupo de discussão teve uma conversa rápida sobre o que a comunidade poderia fazer para impedir uma coisa dessas e de quem é a responsabilidade de impedir que isso aconteça.
Plataforma / Rede de Entrega
Assumir a responsabilidade da NPM exigiria uma situação monetizada que seria péssima ou talvez estivesse disponível apenas para empresas - mas todos os outros se beneficiariam de graça?
Mantenedor da fonte
Como mantenedores de código aberto, precisamos estar atentos às conseqüências de nossas ações. Se você é um mantenedor de código aberto, isso pode se tornar uma tarefa árdua à medida que o valor intrínseco que você obtém do projeto diminui. Seria difícil dizer não a alguém que aparentemente tem a energia que você já teve para manter seu projeto avançando. Um ponto a ser observado é que algumas plataformas permitem um processo de revisão antes da publicação, se os níveis de permissão corretos estiverem em vigor. Nesse caso, a propriedade do projeto foi completamente transferida, você deve tentar não fazer isso, a menos que confie totalmente na pessoa / entidade - mesmo assim, parece que não é uma maneira limpa de conduzir a continuação do software que foi estabelecido e confiável. As pessoas também podem criar códigos de acesso, mas isso pode ficar confuso.
Comunidade e Consumidores
A infraestrutura atual pode usar alguns recursos para ajudar.
Por exemplo, as liberações podem ser verificadas, aprovadas ou sinalizadas pela comunidade, assim como a forma como os torrents podem ser classificados para cima ou para baixo pela comunidade, para que outros possam tomar decisões rápidas antes de mergulhar. Uma classificação negativa alta pode sinalizar um pacote e avisar os consumidores sobre ele e as instalações futuras.
Como consumidor que instala cegamente o software e atualiza, é sua responsabilidade observar o que está consumindo. Você pode usar os gerenciadores de pacotes que possuem o bloqueio de versão para ajudar a negar isso. Infelizmente, duvido que muitas pessoas gastem o tempo necessário para revisar os 100 pacotes que estão instalando quando estabelecem um bom controle npm install. Algumas empresas passam por um processo de fornecedor quando o software muda; Espero que nenhum negócio faça isso com os pacotes NPM (isso poderia interromper seriamente o desenvolvimento), mas essa foi uma opção apresentada.
Dinheiro $$$
Ninguém quer pagar por software livre de código aberto, mas se aqueles que escreviam código fossem recompensados por suas contribuições, eles poderiam estar mais motivados a manter o software e a imagem da comunidade. O dinheiro pode vir diretamente dos consumidores ou como uma gota para a plataforma em que está sendo entregue. Por mais que eu detestasse vê-lo, pude ver as bibliotecas seguindo o mesmo caminho das plataformas de CI - gratuitas para código aberto, mas com custo para empresas / particulares - isso pode ser tratado com licenciamento, mas os desenvolvedores não querem perder tempo se tornando profissões de licenciamento (talvez elas possam ser simplificadas e diretas).