GitHub lança publicação em estágios no npm para conter ataques à supply chain de software

O GitHub anunciou a disponibilidade geral do staged publishing no npm, recurso que exige aprovação manual com 2FA antes que um pacote fique acessível para instalação, em resposta direta à onda de ataques contra a cadeia de suprimentos de código aberto que dominou 2026 — incluindo a campanha do grupo TeamPCP, que já comprometeu Trivy, Checkmarx, Bitwarden CLI, TanStack e o próprio GitHub.

O que aconteceu

A subsidiária da Microsoft introduziu nesta semana dois conjuntos de mudanças no npm desenhados para frear ataques de cadeia de suprimentos. O primeiro, chamado staged publishing, muda fundamentalmente o ciclo de publicação: em vez de uma versão do pacote ficar instantaneamente disponível após o comando “npm publish”, o tarball é depositado em uma fila de homologação até que um mantenedor humano valide a entrega com um desafio de autenticação de dois fatores.

A medida foi pensada explicitamente para fluxos de CI/CD não interativos e para o trusted publishing baseado em OpenID Connect (OIDC), onde a publicação automatizada via tokens é exatamente o vetor que cresceu em 2026. Ao impor “prova de presença” para cada release, o GitHub busca cortar o caminho mais curto dos atacantes — comprometer um token de CI e despejar pacotes maliciosos no registro instantaneamente.

Como o controle funciona

Para utilizar o staged publishing, mantenedores precisam atualizar o CLI do npm para a versão 11.15.0 ou superior e enviar o pacote para a área de staging com o comando “npm stage publish” a partir do diretório raiz. O GitHub recomenda combinar o recurso com trusted publishing via OIDC, configuração que já reduz o risco de comprometimento de tokens estáticos.

“Em vez de uma publicação direta que torna imediatamente uma versão disponível para os consumidores, o tarball pré-compilado é enviado para uma fila de estágio onde um mantenedor precisa explicitamente aprová-lo antes que se torne instalável”, explicou o GitHub em comunicado.

A segunda mudança expande as proteções no momento da instalação. O npm passa a oferecer três novas flags de origem além da já existente –allow-git, permitindo que desenvolvedores apliquem allowlists explícitas a cada fonte de instalação fora do registro oficial. Tarballs locais, diretórios e symlinks agora ficam bloqueados por padrão a menos que liberados individualmente — fechando vetores frequentemente abusados em ataques que dependem de instalações fora do canal oficial.

Quem é afetado

• Mantenedores de pacotes públicos no npm, que precisarão habilitar o staged publishing e atualizar suas pipelines de release.
• Times de DevSecOps que dependem de trusted publishing OIDC em workflows automatizados.
• Empresas que mantêm pacotes internos e privados via npm dentro de seus monorepos.
• Desenvolvedores que utilizam dependências fora do registro oficial — enfrentarão atritos adicionais até configurar as allowlists para suas pipelines existentes.

Análise

A iniciativa do GitHub chega como reconhecimento tácito de que o ecossistema npm vem operando como o calcanhar de Aquiles do código aberto moderno. O grupo TeamPCP, batizado pela imprensa em 2026, articulou uma cascata de comprometimentos que se autoalimentam: um pacote comprometido despeja credenciais, credenciais permitem comprometer o pacote seguinte, e assim por diante. O modelo de “publicar e propagar” sem fricção criou exatamente o ambiente em que esse efeito dominó prospera.

Comparado às defesas que outros registros públicos vêm adotando — como o sistema de trusted publishers do PyPI ou o tooling de attestation do Maven Central —, o staged publishing é uma resposta tardia mas necessária. A combinação com trusted publishing via OIDC se aproxima de um modelo defendido por especialistas há anos: build verificável + identidade verificável + aprovação humana. O custo, claro, é fricção: pipelines que dependiam de publicações silenciosas precisarão de revisão.

Ainda assim, é improvável que a medida sozinha pare o TeamPCP. Como mostrou o caso confirmado nesta semana de invasão a 3.800 repositórios internos do próprio GitHub via uma extensão envenenada do VS Code, os atacantes têm migrado para a estação de trabalho do desenvolvedor — onde 2FA no momento do publish pode simplesmente ser respondido pela máquina já comprometida. A defesa em profundidade precisa avançar simultaneamente em três frentes: registro, identidade de publicação e integridade do endpoint do mantenedor.

Recomendações práticas

• Atualizar o npm CLI para 11.15.0 ou superior em ambientes de build e estações de desenvolvedor.
• Habilitar staged publishing para todos os pacotes ativos sob sua responsabilidade — começar pelos pacotes mais baixados.
• Configurar trusted publishing via OIDC em integrações CI/CD; eliminar tokens estáticos de longa duração sempre que possível.
• Definir explicitamente as novas flags –allow-tarball, –allow-directory e –allow-link nas allowlists para travar fontes não-oficiais.
• Auditar extensões do VS Code instaladas em máquinas de desenvolvedores — preferencialmente via política de organização.
• Monitorar eventos de publicação não aprovados na fila de staging como sinal de comprometimento de credenciais de publicador.
• Revisar a tabela de mantenedores ativos por pacote e reduzir o número de identidades com permissão de publish.

Fonte: The Hacker News