A nova firewall npm do GitHub bloqueia pacotes de risco antes da instalação

Cada npm install é um pequeno ato de confiança. Uma compilação descarrega centenas de pacotes de um registo público, executa os scripts de ciclo de vida que vierem incluídos e ninguém lê o código antes. O GitHub oferece agora uma forma de colocar um ponto de controlo de políticas à frente desse momento: uma firewall de pacotes, lançada em pré-visualização pública, que inspeciona os pedidos de metadados e as transferências do npm e recusa tudo o que infrinja as regras definidas pela organização.

O que aconteceu

A firewall está disponível em pré-visualização pública para os clientes do GitHub Enterprise Cloud, incluindo as implementações com residência de dados. Por agora só entende npm; espera-se que outros ecossistemas se sigam.

Em termos de arquitetura, é um portão colocado entre os endpoints ou registos internos da organização e o registo público a montante. Os portáteis dos programadores, os servidores de CI/CD e os agentes autónomos de programação apontam o gestor de pacotes para a firewall em vez de diretamente para o registo. Cada pedido é verificado contra a política, e as transferências que falham são bloqueadas no momento da instalação em vez de descobertas mais tarde.

Os administradores têm de configurar eles próprios os controlos de política. O conjunto atual cobre cinco verificações:

• Malware conhecido. Os pacotes com um aviso de malware ativo na base de dados de avisos do GitHub são rejeitados de imediato.
• Limiar de severidade. São bloqueadas as versões afetadas por uma vulnerabilidade publicada com nível igual ou superior ao escolhido. A predefinição é "apenas Critical", com as opções "High ou superior", "Medium ou superior" e "qualquer severidade".
• Retrocessos de atestação. A atestação de proveniência SLSA da versão pedida é comparada com as versões anteriores. Se um pacote que publicava proveniência assinada deixar subitamente de o fazer, a transferência é travada. Esse padrão é um forte sinal de um pipeline de publicação comprometido.
• Scripts de instalação recém-introduzidos. São bloqueadas as versões que acrescentam hooks preinstall, install ou postinstall onde as versões anteriores não os tinham. Os scripts de instalação executam código arbitrário e continuam a ser o mecanismo preferido para distribuir pacotes que roubam credenciais.
• Idade mínima do pacote. Um período de espera que recusa versões mais recentes do que um número configurado de dias. O intervalo vai de 1 a 365 dias, a predefinição é um dia e definir zero desativa a verificação.

Os programadores que esbarrem num falso positivo, ou que precisem mesmo de uma versão ainda dentro do período de espera, podem submeter um pedido de exceção com uma justificação, que os administradores e gestores de segurança da organização aprovam ou recusam.

Porque é que importa

O momento da instalação é onde os ataques modernos à cadeia de abastecimento realmente triunfam. O padrão típico é o sequestro da conta de um responsável pelo pacote, seguido de uma versão envenenada com um script postinstall que recolhe tokens, chaves de cloud e ficheiros .npmrc poucos minutos depois da publicação. Quando o registo remove a versão, milhares de compilações já a executaram.

Duas tendências agravam a janela. Os runners de CI instalam dependências em cada execução do pipeline sem qualquer pessoa no circuito, e os agentes de programação com IA adicionam e atualizam agora pacotes por conta própria para concluir uma tarefa. Nenhum deles lê o diff do lockfile antes de descarregar uma versão com poucas horas.

É por isso que os períodos de espera se estão a espalhar pelos ecossistemas. No último ano, o npm, o PyPI, as extensões do Visual Studio Code, o RubyGems, o Bun, o pnpm e o Yarn introduziram alguma forma de idade mínima de versão. O Rust junta-se a eles: a versão 1.100, prevista para 12 de novembro de 2026, acrescenta uma idade mínima de publicação configurável no ficheiro de configuração do Cargo e, se nada for definido, aplica-se por predefinição uma espera de sete dias às versões de crates.

Vale a pena ser honesto quanto aos limites. Um período de espera atrasa as correções de segurança legítimas tanto como as maliciosas, a menos que alguém conceda uma exceção, e o código malicioso não se torna inofensivo com a idade. Uma versão que escapa aos scanners simplesmente sobrevive ao período de espera. O que o atraso compra é tempo: tempo para investigadores, responsáveis pelos pacotes e registos detetarem e retirarem uma versão má antes de a próxima atualização de dependências a levar mais longe.

O que fazer

1. Se usa o GitHub Enterprise Cloud, ative a pré-visualização primeiro numa organização não crítica, aponte para ela os runners de CI e os agentes de programação e afine o limiar de severidade e o período de espera antes de alargar a implementação.
2. Todos os outros, definam um período de espera na mesma. A maioria dos principais gestores de pacotes expõe já uma definição de idade mínima de versão. Um a três dias chegam para apanhar a maioria das versões sequestradas sem travar o ritmo de trabalho.
3. Domem os scripts de ciclo de vida. Executem as instalações com os scripts desativados sempre que a stack o permita e mantenham uma lista explícita dos poucos pacotes que legitimamente precisam deles.
4. Façam commit e revisão dos lockfiles. Tratem uma alteração de lockfile como uma alteração de código, sobretudo quando foi gerada por um agente automático. Uma nova dependência transitiva ou um salto para uma versão com poucas horas merece um segundo olhar.
5. Reduzam o que um script malicioso pode roubar. Usem tokens de registo de curta duração e só de leitura, e credenciais de cloud com âmbito restrito nos servidores de compilação, e nunca deixem segredos de longa duração em variáveis de ambiente que um hook de instalação consiga ler.
6. Vigiem os sinais de proveniência. Uma versão que perde a atestação ou ganha um script de instalação é motivo para parar, não uma curiosidade.

Os manifestos de dependências, os diffs de lockfile, os scripts de ciclo de vida e a proveniência do que uma compilação descarrega são exatamente a camada que a revisão de código assistida por IA da nossa equipa examina, para que um pacote suspeito seja sinalizado enquanto ainda é um pull request e não depois de ter corrido num runner de produção.