O GitHub anunciou a criação de um novo firewall de pacotes, disponível em versão preliminar, para bloquear a instalação de pacotes npm suspeitos.
“O firewall inspeciona solicitações de metadados e downloads de pacotes em busca de sinais de atividade maliciosa, atuando como uma barreira de controle durante a instalação”, informou a empresa.
Por enquanto, o recurso é compatível apenas com pacotes npm e está disponível em versão preliminar pública para todos os clientes do GitHub Enterprise Cloud, inclusive os que usam a versão com residência de dados.
Segundo a subsidiária da Microsoft, o firewall fica entre os endpoints ou registros internos e os registros de pacotes de origem. O objetivo é conter ataques de malware que comprometem sistemas durante a instalação de pacotes.
Esse tipo de comportamento pode expor usuários a graves riscos de segurança, sobretudo quando agentes de IA e executores de CI instalam dependências automaticamente para concluir uma tarefa ou compilação, sem autorização explícita.
A proposta é que endpoints, como agentes de programação e máquinas de CI/CD, encaminhem suas solicitações pelo firewall, em vez de se conectarem diretamente aos registros públicos de pacotes. O firewall verifica os downloads de acordo com controles de política, como o tempo mínimo desde a publicação do pacote e a presença de alertas de malware, e bloqueia os que não atendem aos critérios.
Para usar o firewall, os administradores precisam configurar controles de política, como os seguintes:
- **Bloquear malware conhecido:** consultar o GitHub Advisory Database em busca de alertas ativos de malware.
- **Bloquear pacotes conforme a gravidade das vulnerabilidades:** consultar o GitHub Advisory Database para identificar falhas que afetem a versão solicitada. Por padrão, a instalação é bloqueada apenas para vulnerabilidades “Críticas”, mas os usuários podem escolher “Altas ou superiores”, “Médias ou superiores” ou “Qualquer gravidade”.
- **Bloquear reduções no nível de atestação:** comparar as atestações da versão solicitada com as de versões anteriores e interromper o download se a versão não tiver uma atestação SLSA.
- **Bloquear novos scripts de instalação:** verificar se o pacote adicionou recentemente scripts executados por meio dos hooks `preinstall` ou `postinstall`, que podem ser usados indevidamente para roubar dados confidenciais.
- **Bloquear pacotes com base em um período de espera:** impedir a instalação de versões publicadas há menos tempo do que o mínimo configurado. O período pode variar de 1 a 365 dias. O padrão é 1 dia, mas o recurso pode ser desativado ao definir o valor como 0.
Usuários que precisarem de um pacote bloqueado por engano podem solicitar uma exceção. O pedido pode ser aprovado por administradores da empresa e responsáveis pela segurança.
A novidade chega enquanto o Rust se prepara para incluir, na versão 1.100, prevista para 12 de novembro de 2026, uma opção configurável de idade mínima de publicação. O intervalo permitirá que ferramentas de segurança e mantenedores tenham tempo para identificar e bloquear versões maliciosas de crates antes que sejam instaladas ou usadas.
A opção `global-min-publish-age`, definida no arquivo `cargo/config.toml`, permite especificar uma idade mínima de publicação em dias ou semanas. Se nenhum valor for informado, será aplicado por padrão um período de espera de sete dias, que exclui versões publicadas nesse intervalo.
No último ano, períodos de espera semelhantes foram adotados em diferentes ecossistemas open source, incluindo npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm e Yarn. A medida busca reforçar a segurança da cadeia de suprimentos de software e reduzir a chance de que uma versão recém-publicada e ainda não analisada seja incorporada imediatamente a uma compilação.
Esses períodos criam obstáculos e podem desacelerar ataques em que um agente malicioso assume o controle da conta de um mantenedor e publica uma versão adulterada de um pacote popular. Com isso, fica mais difícil que a versão se espalhe rapidamente por instalações manuais ou automáticas.
“A desvantagem é que correções legítimas também precisam esperar, a menos que os desenvolvedores abram uma exceção”, afirmou a Socket. “O código malicioso não se torna inofensivo só por envelhecer. Uma versão que passe despercebida pode simplesmente superar o período de espera. O benefício está em dar aos pesquisadores, mantenedores e registros tempo para agir antes que a próxima atualização de dependência leve o ataque adiante.”
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...