Publicar um pacote npm a partir do CI costumava depender de um segredo com vida longa. Mesmo protegido pelo provedor, aquele token podia vazar em log, action comprometida ou configuração permissiva. Trusted publishing trocou esse segredo por uma credencial OIDC temporária, ligada a um workflow conhecido.
Agora, um mesmo pacote pode cadastrar múltiplas configurações de trusted publisher. Isso resolve um limite prático: projetos com fluxos separados para release estável, pré-release e ambientes diferentes não precisam escolher um único caminho nem ressuscitar um token permanente para os demais.
OIDC troca segredo armazenado por identidade verificável
No fluxo OIDC, o provedor de CI emite um token curto com informações sobre repositório, workflow e ambiente. O npm verifica essas afirmações contra a configuração cadastrada e entrega autorização para aquela execução. Não existe um NPM_TOKEN reutilizável esperando alguém copiá-lo.
Múltiplos publishers são aditivos e independentes. Uma publicação é aceita quando corresponde a qualquer uma das configurações cadastradas; não há ordem de avaliação. A documentação do npm informa limite de até dez trusted publishers por pacote.
Separar canais sem ampliar a credencial
- Um workflow protegido publica versões estáveis a partir de tags.
- Outro publica versões beta com um dist-tag próprio.
- Um terceiro pode atender um repositório de manutenção ou ambiente com aprovação distinta.
Cada caminho recebe a menor identidade necessária. Se o workflow de pré-release for comprometido, ele não herda automaticamente um token capaz de publicar por qualquer máquina. O benefício vem da combinação de credencial efêmera e vínculo explícito com o emissor.
Staging adiciona uma janela para detectar desastre
Configurações criadas desde 3 de setembro usam staging por padrão. O pacote enviado fica aguardando a verificação de malware antes da liberação, e a aprovação manual permanece indisponível enquanto a análise não termina. É possível optar por publicação direta, mas o GitHub recomenda o estágio intermediário.
Isso reduz a chance de um workflow comprometido transformar imediatamente código malicioso em release público. Não elimina risco: scanner não conhece toda intenção nociva, maintainer pode aprovar artefato errado e uma identidade ampla demais continua perigosa.
Proveniência ajuda quem consome
Publicações via trusted publishing geram proveniência automaticamente nos provedores suportados. O consumidor consegue relacionar o pacote ao repositório e à execução que produziu o artefato. Isso não garante que o código seja seguro, mas torna a origem verificável e melhora a investigação de supply chain.
Migração sem deixar uma porta lateral
- Liste todos os workflows que publicam e elimine caminhos abandonados.
- Cadastre cada combinação de repositório, workflow e ambiente de forma restrita.
- Proteja tags, branches e environments que autorizam release.
- Teste primeiro um canal de pré-release.
- Revogue tokens antigos depois de confirmar todos os fluxos OIDC.
- Revise periodicamente a lista; múltiplas configurações não devem virar permissões esquecidas.
O último passo é o que fecha a migração. Manter o token antigo “por segurança” conserva exatamente o segredo de longa duração que o OIDC deveria remover. Tenha um processo de recuperação, não uma credencial paralela permanente.
Múltiplos trusted publishers tornam a opção segura compatível com repositórios reais, que raramente têm um único workflow para sempre. A flexibilidade é bem-vinda; a lista de identidades autorizadas agora merece a mesma revisão que qualquer outra política de acesso.