GitHub lança package firewall em preview público para barrar pacotes npm maliciosos antes da instalação

Fala aí, beleza? O GitHub acabou de colocar uma camada nova entre o seu npm install e o registro de pacotes, e a ideia é barrar o pacote zoado ANTES dele chegar no endpoint 😀

O anúncio saiu no GitHub Changelog em 20 de outubro de 2026: o package firewall entrou em preview público para clientes do GitHub Enterprise Cloud, incluindo quem usa residência de dados

Ele fica no meio do caminho entre endpoints como runners do GitHub Actions e agentes de código e os registros de pacotes upstream, e pode bloquear pacotes npm suspeitos antes da instalação

Por que o GitHub criou o package firewall

Porque o ataque mudou de lugar

Segundo o próprio changelog do GitHub, cada vez mais malwares exploram o momento da instalação do pacote e coletam credenciais em hosts de CI/CD ou em estações de trabalho de desenvolvedores, sem nem precisar executar o código do pacote

Se liga no detalhe: sem executar o código!

Ou seja, aquela lógica de "instalei mas não usei, então tá de boa" não vale mais

Aí a conclusão é meio óbvia: se o estrago acontece na instalação, o bloqueio precisa acontecer antes do download chegar no endpoint

Como o package firewall funciona

O fluxo descrito pelo GitHub tem duas etapas: primeiro o admin define a política, depois os endpoints passam a mandar as requisições pelo firewall

Se você já mexeu com firewall numa VPS com n8n, a ideia é parecida: em vez de deixar tudo passar direto, você coloca um porteiro no meio que decide o que entra 🙂

Etapa 1: políticas no nível da enterprise

Os administradores definem os controles de política para a enterprise

Hoje os controles disponíveis são:

• Cooldown configurável: um período de espera configurável
• GitHub Advisory Database: checagem de alertas de malware ou de vulnerabilidade
• Checagens de cadeia de suprimentos: como o rebaixamento de atestação (attestation downgrade)

O changelog não detalha como esse cooldown se comporta na prática: não há explicação oficial sobre o que exatamente acontece durante esse período ou como ele é calculado. Pra quem quiser esse nível de detalhe, a própria documentação "Protecting endpoints with package firewall", indicada no anúncio, é a fonte certa pra consultar antes de configurar

Etapa 2: endpoints apontando para o firewall

Os endpoints, como agentes de código e hosts de CI/CD, precisam ser configurados para usar o firewall em vez de apontar direto para o registro upstream

A partir daí, tanto as requisições de metadados (as listas de pacotes) quanto os downloads em si passam pelo firewall, que avalia tudo contra a política definida

Os passos concretos de configuração estão na documentação oficial "Protecting endpoints with package firewall", indicada no próprio anúncio, então é por lá que tu segue

E se o firewall bloquear um pacote legítimo?

Acontece, né?

Pra isso existe um fluxo de exceção: o usuário pede a liberação por um processo semelhante ao de outros recursos do GitHub Advanced Security

Disponibilidade, preço e limitações do preview

Resumindo o estado atual, conforme o anúncio:

• Quem pode usar: todos os clientes do GitHub Enterprise Cloud, inclusive com residência de dados
• Ecossistemas: só npm por enquanto
• Preço no preview: grátis
• Preço na disponibilidade geral: cobrança por uso medido, parecida com a do GitHub Actions, ainda sem valor anunciado

O GitHub também diz que o recurso segue em preview enquanto amplia a infraestrutura e adiciona funcionalidades conforme a demanda dos clientes

O anúncio não traz data de disponibilidade geral nem confirma suporte a outros ecossistemas, então quem trabalha com Python, Java ou Ruby ainda não tem informação oficial sobre cobertura

O que muda para quem usa agentes de código e vibe coding

Aqui é onde a coisa fica interessante pra galera do vibe coding

Agente de código instala dependência sozinho

Tu pede uma feature, ele decide que precisa de uma lib, roda o install e segue a vida, muitas vezes sem ninguém revisar pacote por pacote

É como contratar um dev que vai no mercado comprar ingrediente sem você conferir a lista haha

Por isso um firewall entre o agente e o registro faz MUITO sentido nesse fluxo: a política barra o pacote antes de chegar no ambiente onde o agente está rodando

Porém, tome cuidado!

A proteção só vale para os endpoints que foram configurados para usar o firewall

Runner ou agente de código que continuar apontando direto pro registro upstream fica fora da política, simples assim

E se você não está no GitHub Enterprise Cloud, esse preview não está disponível pra você

Quer revisar o básico de Git e GitHub antes?

O firewall é coisa de admin de enterprise, mas se você ainda está chegando agora no GitHub, esse curso do canal cobre Git e GitHub do básico ao avançado, com projeto

Próximo passo para testar o package firewall

Se você é admin de Enterprise Cloud, o primeiro movimento nem é técnico: é fazer o inventário

Lista tudo que roda instalação de pacote npm na sua organização: runners do Actions, agentes de código, hosts de CI/CD e por aí vai

Como os endpoints precisam ser configurados para usar o firewall em vez de apontar direto pro registro upstream, esse mapa é o que ajuda a garantir que nenhum endpoint fique pra trás

Com a lista em mãos, segue a documentação oficial "Protecting endpoints with package firewall", linkada no changelog, e acompanha a discussão no GitHub Community pra ver o que outros times estão reportando e pedindo de recurso

Até o próximo post! 😀

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.