Staged publishing no npm: a aprovação com 2FA que trava a publicação automática e protege a cadeia de fornecimento

O GitHub tem ativado uma nova ferramenta no npm chamada staged publishing que exige a aprovação manual de um mantenedor (mediante desafio de duplo fator) antes que uma versão publicada seja visível e descarregavel desde npmjs.com. Na prática, o tarball pré-construído já não se torna público instantaneamente: se sobe a uma cauda de staging e requer que uma pessoa com acesso de publicação e 2FA confirme sua liberação. Esta pequena mas significativa modificação procura adicionar teste de presença humana a cada publicação, mesmo para artefatos gerados pela CI/CD.

O mecanismo muda o modelo tradicional em que uma pipeline podia publicar automaticamente uma versão logo que terminava: agora a pipeline pode subir o pacote com o comando "npm stage publish" (disponível a partir de npm CLI 11.15.0), mas a versão não será instalada até que um mantenedor supere o desafio 2FA. Isso mitiga cenários em que credenciais comprometidas ou workflows mal configurados permitem a publicação automatizada de artefatos maliciosos, porque exige uma interação humana autenticada antes do push final.

É importante entender seus limites: não pode ser aplicado a pacotes novos que ainda não existam no registo, requer que a conta do mantenedor tenha 2FA ativado e que as equipes atualizem seu cliente npm a 11.15.0 ou superior. Além disso, o controle só eleva a dificuldade para ataques automatizados; não impede que um atacante que exceda a 2FA do mantenedor (por phishing ou acesso a tokens) publique código malicioso. Por isso o GitHub recomenda combinar staged publishing com trusted publishing por OIDC, que reduz a dependência de tokens de longa duração na CI e melhora a rastreabilidade da identidade da pipeline.

Em paralelo, npm adicionou três bandeiras para controlar origens de instalação não-registro: -- allow- file, -- allow- reote e -- allow- directory, junto à já existente -- allow-git. Estas opções permitem a aplicação de uma estratégia de lista mais rigorosa para instalações de ficheiros locais, URLs remotos ou pastas: controlos úteis para evitar injeções de tarballs maliciosos ou instalação acidental de dependências de origens não verificadas a partir de programas ou testes locais.

Para equipes e mantenedores a recomendação prática imediata é clara: ativa 2FA em todas as contas com permissões de publicação, atualiza o npm CLI a 11.15.0+, e habilita staged publishing para pacotes críticos. A nível organizacional, adota OIDC para seus runners CI/CD e elimina tokens de longa duração; limita os escores dos tokens sobreviventes; registra e alerta sobre atividades de publicação incomuns; e usa assinaturas ou mecanismos de verificação adicionais para artefatos quando possível. Complementa isso com análise de composição de software (SCA), revisões de mudanças obrigatórias e geração de SBOMs para cada build.

Não se esqueça de reforçar as políticas de instalação em ambientes de desenvolvimento e produção: considera negar por defeito as instalações desde URLs ou arquivos e permitir explicitamente apenas o necessário através das novas bandeiras, e educa os desenvolvedores sobre riscos de instalar pacotes de fontes externas. Estas medidas reduzem a superfície pela qual campanhas de "poisoning" em massa, como as atribuídas recentemente a grupos que manipulam pacotes populares, conseguem se espalhar.

Staged publishing não é uma panaceia, mas representa um avanço valioso na defesa do ecossistema open source: introduz um ponto de controle humano que complica os ataques automatizados e melhora a rastreabilidade de publicações. Para aprofundar as práticas de segurança da cadeia de fornecimento de software e recomendações complementares, consulte a documentação oficial do npm em https://docs.npmjs.com/ e recursos de segurança da cadeia de abastecimento como o projeto OWASP https://owasp.org/www-project-supply-chain-security/. Também é útil seguir o blog do GitHub para atualizações e guias práticas neste âmbito: https://github.blog/.