Ing. Calogero Bono
O GitHub apresentou em 20 de outubro de 2026 o firewall de pacotes, um filtro que fica entre os computadores que instalam pacotes e os registros públicos de onde eles são baixados. Hoje está em prévia pública para todos os clientes do GitHub Enterprise Cloud e oferece suporte apenas ao npm. O objetivo é bloquear o malware que age no momento da instalação, um risco maior para agentes de IA e sistemas de build que instalam dependências sem ninguém para verificar. Se você desenvolve software ou gerencia quem o desenvolve, é um sinal de para onde está indo a segurança da cadeia de suprimentos.
Alguns termos, antes de entrarmos nos fatos. Um registro (ou registry) é o repositório online de onde se baixam os pacotes, como o npm para JavaScript. Uma dependência é um trecho de código de terceiros que o seu projeto usa. As CI/CD são os procedimentos automáticos que compilam e publicam o software. Uma attestation SLSA é uma declaração verificável sobre como e por quem um pacote foi construído. Os metadados são as informações sobre o pacote, por exemplo a lista das versões disponíveis.
O que é o firewall de pacotes do GitHub?
Segundo o changelog oficial do GitHub, nos últimos tempos houve uma verdadeira onda de ataques de malware que exploram o momento em que os pacotes são instalados. Agentes e runner de CI são alvos especiais, porque instalam dependências para concluir uma tarefa ou um build sem uma pessoa no meio.
O firewall fica entre os endpoints, ou os registros internos, e os repositórios de pacotes a montante. Como informa The Hacker News, o GitHub o descreve assim – «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate,» ou seja, um portão de regras aplicado no momento da instalação.
O tema não é teórico. O site The Register deu manchete sobre uma campanha em que os atacantes teriam transformado issues do GitHub em um ataque à cadeia de suprimentos contra 61 repositórios públicos em menos de uma hora. Na página que temos à disposição não há outros detalhes, então não podemos dizer se e como as duas notícias estão ligadas.
Como funciona e quais controles oferece?
O fluxo tem duas etapas. Primeiro os administradores definem as regras para a sua enterprise. Depois agentes de codificação e hosts CI/CD apontam para o firewall em vez de ir diretamente aos registros públicos. Tanto as requisições de metadados quanto os downloads passam pelo firewall, que os avalia conforme a política.
Os controles disponíveis
Pela lista do The Hacker News, estes são os controles disponíveis.
- Bloqueio de malware conhecido, verificando os alertas ativos no GitHub Advisory Database.
- Bloqueio por gravidade das vulnerabilidades, sempre usando o banco de dados. A configuração padrão bloqueia apenas o nível «Critical only», mas é possível escolher «High or higher», «Medium or higher» ou «Any severity».
- Bloqueio de downgrade de attestation. O firewall compara as attestation da versão solicitada com as das versões anteriores e interrompe o download se faltar a attestation SLSA.
- Bloqueio de novos scripts de instalação, ou seja, aqueles que rodam com os hooks preinstall ou postinstall e podem ser usados para roubar dados sensíveis.
- Período de espera (cooldown), que impede a instalação de versões mais recentes que a idade mínima configurada.
O cooldown pode variar de 1 a 365 dias. O valor padrão é 1 dia e ele é desativado definindo-o como 0.
E se bloquear um pacote legítimo?
Se um pacote for bloqueado por engano, o usuário pode pedir uma exceção. Para o GitHub, o fluxo é semelhante ao de outras funções do GitHub Advanced Security. Segundo o The Hacker News, o pedido pode ser aprovado por administradores e responsáveis pela segurança da enterprise.
Quanto custa e quem pode usar?
O serviço está disponível em prévia pública para todos os clientes do GitHub Enterprise Cloud, inclusive na versão com residência de dados. Durante a prévia é gratuito. Quando chegar a disponibilidade geral, o GitHub afirma que será cobrado conforme o consumo medido, de forma parecida com a cobrança do Actions.
O GitHub explica que a prévia serve para ampliar a infraestrutura e adicionar funções conforme os pedidos dos clientes. Para as instruções de configuração, remete à documentação Protecting endpoints with package firewall.
Por que se fala tanto em períodos de espera?
O cooldown é a regra mais simples e, talvez, a mais difundida. O The Hacker News lembra que, no último ano, esperas semelhantes foram introduzidas no npm, Python, Visual Studio Code, Ruby, Bun, pnpm e Yarn. O princípio é reduzir a probabilidade de uma versão recém-publicada e ainda não revisada acabar logo em um build.
Ajuda sobretudo contra quem assume o controle da conta de um mantenedor e publica uma versão envenenada de um pacote popular. A espera freia a disseminação rápida, manual ou automática.
O mesmo artigo informa que o Rust 1.100, previsto para 12 de novembro de 2026, deve adicionar uma idade mínima de publicação configurável para os crates. A opção se chama «global-min-publish-age» e fica no arquivo cargo/config.toml. Se não for especificada, aplica-se uma espera padrão de sete dias.
Do outro lado da moeda fala a Socket, citada pelo The Hacker News. «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception,» afirma a empresa. Ela acrescenta que uma versão que escapou aos controles pode simplesmente sobreviver ao cooldown. O valor, segundo a Socket, está em dar tempo a pesquisadores, mantenedores e registros para agir.
Limites que você precisa conhecer
- Hoje o firewall oferece suporte apenas ao npm. Quem trabalha com PHP, Python ou outros ecossistemas não está coberto, e as fontes não indicam datas para outros registros.
- É reservado aos clientes do GitHub Enterprise Cloud. As fontes não mencionam planos menores.
- Estamos em prévia. Funções, infraestrutura e preços podem mudar, e o custo por consumo ainda não foi quantificado.
- Não temos dados independentes sobre a eficácia. As fontes relatam as declarações do GitHub, não testes com malware reais, e não há números sobre falsos positivos.
- Como lembra a Socket, o cooldown não torna inofensivo o código malicioso. Uma versão não detectada pode permanecer oculta além da espera.
O que muda para quem trabalha com tecnologia digital
O ponto prático é que a segurança passa do controle a posteriori para o controle antes da instalação. Para quem desenvolve com agentes de IA que escrevem e instalam sozinhos, isso significa ter uma regra central em vez de confiar em cada agente. Se você usa ferramentas de desenvolvimento guiadas por IA, vale reler os riscos que descrevemos no nosso artigo sobre o vibe coding para a PMI.
Para as empresas italianas, o tema também toca a conformidade. A cadeia de suprimentos do software faz parte do que tratamos no guia sobre o registro de fornecedores NIS2. Poder demonstrar que os pacotes passam por um filtro com regras escritas é um argumento concreto, embora nenhuma fonte relacione o firewall à NIS2.
Quem usa muito open source deve lembrar que cada dependência é um fornecedor. Falamos disso no aprofundamento sobre open source na empresa. Mesmo quem não é cliente Enterprise pode copiar a ideia com as ferramentas já disponíveis, por exemplo os períodos de espera que alguns gerenciadores de pacotes oferecem.
Para servidores de build e de produção também contam atualizações e isolamento. Se você quer uma infraestrutura cuidada por terceiros, há o nosso serviço de hospedagem e servidores gerenciados. Se, por outro lado, você está avaliando um projeto sob medida, o caminho está em desenvolvimento de software sob medida.
Nossa opinião
A ideia é correta. Bloquear um pacote antes que ele rode no computador é mais eficaz do que perceber o problema depois, e fazer isso em um ponto único evita depender da disciplina de cada desenvolvedor ou de cada agente. O fato de o GitHub partir justamente dos agentes sem supervisão nos parece uma leitura honesta do problema.
As ressalvas são duas. A primeira é comercial. Uma proteção tão útil, por enquanto reservada ao plano Enterprise e cobrada por consumo após a prévia, corre o risco de deixar descobertas as pequenas equipes, que costumam ser as mais expostas. A segunda é técnica. Muitos controles dependem do banco de dados do GitHub e do tempo, e o tempo não é uma garantia, como admite a própria Socket.
Por isso não o vemos como um escudo definitivo. É mais uma camada, útil se acompanhada de revisão das dependências, travamento de versões e permissões mínimas para os agentes. Se você acha que basta ligar o firewall, está criando uma falsa sensação de segurança.
Perguntas frequentes
O firewall de pacotes do GitHub é gratuito?
Sim, mas somente durante a prévia. O GitHub afirma que, na disponibilidade geral, será cobrado conforme o consumo medido, de forma parecida com o Actions. Os preços ainda não foram divulgados.
Funciona apenas com npm?
Sim, por enquanto oferece suporte apenas a pacotes npm. As fontes não anunciam datas para outros ecossistemas. Se você usa outras linguagens, por ora precisará buscar outras defesas.
Quem pode usar?
Todos os clientes do GitHub Enterprise Cloud, inclusive na versão com residência de dados. As fontes não mencionam outros planos. Os administradores configuram as regras para toda a enterprise.
O que acontece se bloquear um pacote legítimo?
O usuário pode pedir uma exceção. Segundo o The Hacker News, o pedido pode ser aprovado por administradores e responsáveis pela segurança. O fluxo, diz o GitHub, é semelhante ao de outras funções do Advanced Security.
O período de espera basta para bloquear o malware?
Não. Ele ajuda a ganhar tempo contra versões recém-publicadas, mas a Socket lembra que o código malicioso não se torna inofensivo com o passar do tempo. Uma versão não detectada pode superar a espera.
O que acompanhar até a disponibilidade geral
Nos próximos meses vale acompanhar três pontos. O preço por consumo que o GitHub vai definir, a eventual extensão para além do npm e a chegada da espera mínima no Rust 1.100, prevista para 12 de novembro de 2026. Enquanto isso, você já pode agir assim.
- Liste as dependências usadas por CI e agentes, e decida quem pode instalar o quê sem supervisão.
- Avalie um período de espera para as versões novas, sabendo que ele também atrasa correções legítimas.
- Prepare um procedimento para exceções, com um responsável que aprove com rapidez, mas com registro por escrito.
