O GitHub anunciou o lançamento de um novo firewall de pacotes, em versão de prévia, para bloquear a instalação de pacotes npm (gerenciador de pacotes do Node.js) considerados suspeitos durante o processo de instalação.
“O firewall inspeciona tanto as requisições de metadados quanto os downloads de pacotes em busca de sinais de atividade maliciosa, atuando como um portão de política no momento da instalação”, afirmou o GitHub.
O recurso, que atualmente oferece suporte apenas a pacotes npm, está disponível em prévia pública para todos os clientes do GitHub Enterprise Cloud, incluindo o GitHub Enterprise Cloud com residência de dados.
Segundo a subsidiária da Microsoft, o firewall fica posicionado entre os endpoints ou registros internos e os repositórios de origem (upstream) de pacotes, para impedir ataques de malware que comprometam sistemas durante a instalação de pacotes.
Esse comportamento pode expor usuários a sérios riscos de segurança, sobretudo quando agentes de inteligência artificial (IA) e executores de integração contínua e entrega contínua (CI/CD) instalam dependências automaticamente para concluir uma tarefa ou build, sem permissão explícita do usuário.
A ideia é que endpoints, como agentes de programação e hosts de CI/CD, usem o firewall para suas requisições, em vez de apontar diretamente para os registros públicos de pacotes. Em seguida, o firewall verifica os downloads de pacotes com base em controles de política, como idade mínima do pacote e alertas de malware, e bloqueia os downloads que não atendam a essas políticas.
Para usar o firewall, os administradores precisam configurar controles de política, como os listados abaixo:
- Bloquear malware conhecido, verificando a GitHub Advisory Database em busca de alertas ativos de malware.
- Bloquear pacotes com base na gravidade das vulnerabilidades, verificando na GitHub Advisory Database as falhas que afetam a versão solicitada do pacote. O controle usa “Somente crítica” como padrão para bloquear uma instalação, mas os usuários podem escolher “Alta ou superior”, “Média ou superior” ou “Qualquer gravidade”.
- Bloquear rebaixamentos de atestação, comparando as atestações da versão solicitada com as de versões anteriores e interrompendo o download caso a versão solicitada não tenha uma atestação SLSA (Supply-chain Levels for Software Artifacts, ou níveis de cadeia de suprimentos para artefatos de software).
- Bloquear scripts de instalação recém-introduzidos, verificando se o pacote adicionou recentemente scripts executados pelos hooks preinstall ou postinstall, que podem ser usados para roubar dados sensíveis.
Também é possível bloquear pacotes com base em um período de espera, que impede a instalação de versões mais recentes que a idade mínima configurada. O valor pode variar de 1 a 365 dias, e o padrão é 1 dia. Os usuários podem desativar o recurso definindo o valor como 0.
Usuários que precisarem acessar um pacote bloqueado por engano pelo firewall podem enviar uma solicitação de exceção, que pode ser aprovada por administradores e gestores de segurança da empresa.
O desenvolvimento acontece enquanto o Rust 1.100, cujo lançamento está previsto para 12 de novembro de 2026, se prepara para adicionar suporte a uma idade mínima de publicação configurável. A medida permitirá que scanners de segurança e mantenedores tenham tempo para identificar e bloquear versões maliciosas de pacotes (crates) antes que possam ser instaladas ou usadas.
O valor, definido pela opção “global-min-publish-age” no arquivo “cargo/config.toml”, permite especificar uma idade mínima de publicação em dias ou semanas. Se não for definido, um período de espera de sete dias é aplicado por padrão para ignorar versões publicadas dentro dessa janela.
No último ano, períodos de espera semelhantes foram implementados em ecossistemas de código aberto, como 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, reduzindo a chance de uma versão recém-publicada e não revisada ser incorporada imediatamente a uma build.
Os períodos de espera ajudam a criar obstáculos e a desacelerar ataques em que um agente mal-intencionado publica uma versão adulterada de um pacote popular após assumir o controle da conta de um mantenedor, evitando a disseminação rápida por instalações manuais ou automatizadas.
“O custo é que correções legítimas também precisam esperar, a menos que os desenvolvedores façam uma exceção”, afirmou a Socket. “Código malicioso também não se torna inofensivo com o tempo. Uma versão que escapa da detecção pode simplesmente sobreviver ao período de espera. O valor está em dar a pesquisadores, mantenedores e registros tempo para agir antes que a próxima atualização de dependência leve um ataque ainda mais longe.”
