O npm, gerenciador de pacotes padrão do Node.js mantido pelo GitHub, oficializou o lançamento geral do 'staged publishing' (publicação em estágio), uma nova funcionalidade desenhada para mitigar ataques à cadeia de suprimentos (supply chain attacks) ao exigir uma aprovação humana explícita antes que novas versões de pacotes fiquem disponíveis para o público.
- Adição de uma fila de estágio que impede a publicação imediata de pacotes Node.js sem revisão.
- Exigência de 2FA apenas no momento da aprovação humana, mantendo pipelines de CI automatizadas e não interativas ativas.
- Integração recomendada com Trusted Publishing (OIDC) para travar publicações diretas de ambientes de CI.
- Rápida adoção do conceito por ferramentas concorrentes como pnpm, Yarn e release-it.
Como o staged publishing redefine a publicação no npm<\/h2>
Historicamente, a publicação de um pacote no npm disponibilizava a nova versão de forma imediata para todos os consumidores do ecossistema. Esse modelo direto sempre foi um alvo atraente para agentes maliciosos que, ao comprometerem credenciais de CI/CD ou tokens de automação, conseguiam injetar códigos nocivos diretamente na produção.
Com a chegada do staged publishing, o fluxo ganha uma barreira crucial. Em vez de uma publicação direta, o arquivo empacotado (.tarball) pré-construído é enviado para uma fila de estágio, visível tanto no portal npmjs.com quanto via linha de comando (CLI). A partir daí, o pacote permanece retido até que um mantenedor humano valide a liberação por meio de um desafio de autenticação de dois fatores (2FA).
# publicidade
Requisitos técnicos e fluxo de comandos<\/h2>
Para implementar a novidade, os desenvolvedores precisam utilizar o npm CLI na versão 11.15.0 ou superior, rodando sob o Node.js v22.14.0 ou superior. Além disso, o pacote já deve existir previamente no registro do npm.
O processo foi simplificado em um conjunto enxuto de subcomandos nativos que cobrem desde a submissão até a tomada de decisão final pelo mantenedor responsável.
- npm stage publish: Envia a versão para a fila de estágio sem publicá-la imediatamente.
- npm stage list: Lista todas as versões que aguardam aprovação no estágio.
- npm stage view <stage-id>: Permite inspecionar o conteúdo do tarball retido para garantir a integridade do código.
- npm stage approve <stage-id>: Promove a versão para o registro oficial, exigindo autenticação MFA/2FA.
- npm stage reject <stage-id>: Descarta e remove a versão proposta da fila.
Fortalecendo a pipeline de CI com oidc<\/h2>
Um dos maiores benefícios do novo fluxo é que o envio para a fila de estágio não requer autenticação 2FA. Isso significa que as pipelines de Integração Contínua (CI) não interativas podem continuar gerando e enviando os builds de forma totalmente automatizada com qualquer tipo de token.
O GitHub recomenda fortemente associar o staged publishing à publicação confiável (Trusted Publishing) via OpenID Connect (OIDC). Dessa forma, a configuração do repositório pode ser limitada exclusivamente para aceitar comandos de estágio. Caso uma pipeline comprometida tente realizar um npm publish direto, a operação será rejeitada imediatamente na raiz.
A repercussão na comunidade de segurança<\/h2>
A novidade chega após uma sequência severa de incidentes de segurança no ecossistema de software, incluindo as ondas de ataques de malware conhecidas como Shai-Hulud e migrações conturbadas de tokens de acesso antigos. A recepção do recurso, contudo, divide opiniões entre otimismo e ceticismo prático.
O pesquisador de segurança Adnan Khan defendeu o uso imediato da ferramenta, argumentando que todos os desenvolvedores que utilizam pipelines de CI deveriam configurar o estágio e aprovar os pacotes manualmente via OIDC para neutralizar riscos de sequestro de pipeline. Por outro lado, discussões no Hacker News apontaram que, embora o recurso feche uma brecha massiva, ele ainda depende da adesão voluntária dos desenvolvedores para ter um impacto global real, atuando mais como um redutor da taxa de propagação de malwares do que uma cura definitiva.
Reação do ecossistema e próximos passos<\/h2>
A resposta dos ecossistemas concorrentes foi veloz. O gerenciador pnpm (na versão 11.3) já implementou suporte nativo ao comando pnpm stage com o mesmo fluxo de trabalho. O Yarn também passou a expor yarn npm stage list, e a ferramenta popular de automação de releases 'release-it' adicionou suporte direto à flag de estágio.
Para as próximas atualizações de segurança (npm v12), o GitHub planeja tornar o estágio o destino padrão para tokens de acesso granular que burlam o 2FA. Além disso, haverá a introdução de novos campos de configuração, como o allowScripts, que tornará a execução de scripts pós-instalação uma etapa opcional e de livre consentimento do usuário.
| Comando | Ação Realizada | Exige 2FA? |
|---|---|---|
| npm stage publish | Envia o pacote para a fila de estágio temporário | Não |
| npm stage list | Lista as versões que aguardam aprovação do mantenedor | Não |
| npm stage view <id> | Inspeciona o conteúdo do tarball gerado no estágio | Não |
| npm stage approve <id> | Valida e publica oficialmente a versão para o ecossistema | Sim (Obrigatório) |
| npm stage reject <id> | Descarta o pacote do estágio, cancelando a publicação | Não |
Arraste para o lado para ver toda a tabela.
Perguntas frequentes (faq)<\/h2>
O staged publishing quebra minhas automações de CI/CD atuais?<\/h3>
Não. O processo de envio para o estágio ('npm stage publish') não exige interação nem 2FA, permitindo que suas pipelines continuem gerando releases normalmente. A barreira de 2FA só ocorre no momento final da aprovação pelo mantenedor.
Quais são os requisitos mínimos para usar o recurso?<\/h3>
É necessário utilizar o npm CLI na versão 11.15.0 ou superior, Node.js na versão 22.14.0 ou superior, e o pacote correspondente já deve estar previamente registrado no npmjs.com.
Como o staged publishing protege contra ataques de CI takeover?<\/h3>
Mesmo que um invasor comprometa sua esteira de CI e altere o código do build, o máximo que ele conseguirá fazer é enviar a versão modificada para a fila de estágio. Sem as credenciais de 2FA do mantenedor humano, a versão maliciosa nunca ficará disponível para instalação pública.
