Vincular a identidade de publicação no npm e no PyPI aos artefatos de lançamento aprovados

O que é

Situação em 25 de outubro de 2026. A publicação confiável troca a identidade de CI por credenciais temporárias do registro, em vez de armazenar um token permanente de publicação. Consulte novamente os provedores aceitos pelos registros, as restrições de runners e os requisitos de configuração antes de alterar um workflow de lançamento. A documentação citada é uma referência atualizada continuamente, consultada para esta análise, não um aviso de incidente datado.

Para o npm, os pré-requisitos documentados são npm CLI 11.5.1 ou posterior e Node 22.14.0 ou posterior. Este artigo se concentra em workflows do GitHub Actions que publicam pacotes npm ou distribuições Python no PyPI.

Por que importa

O modelo de segurança do PyPI atribui explicitamente ao publicador a responsabilidade pela integridade do workflow. Credenciais temporárias continuam sendo sensíveis, e um workflow autorizado comprometido pode obtê-las. Eliminar tokens armazenados reduz a exposição de credenciais, mas não torna segura a execução de dependências.

A documentação de proveniência do npm distingue uma conexão verificável com o código-fonte e as instruções de build de uma garantia de que o código é inofensivo. A consequência operacional é direta: um pipeline autorizado pode atestar um artefato malicioso. A aprovação deve avaliar os componentes de entrada e o resultado do lançamento, além da identidade que o assina.

Como aplicar

• Cadastre com precisão o proprietário, o repositório e o workflow de publicação pretendidos. Na configuração do npm para GitHub, informe o nome do arquivo de workflow e vincule o nome opcional do ambiente ao ambiente protegido de publicação. Confira a identidade configurada com o job real antes de remover a forma anterior de autenticação.
• Siga o padrão de separação do PyPI: um job de build cria as distribuições; um job pequeno de publicação as recupera e envia. Conceda permissions: {id-token: write} somente ao job que precisa de OIDC. Mantenha a instalação de dependências, os testes e as alterações não confiáveis fora do alcance das permissões desse job.
• Configure revisores do ambiente, impeça a autoaprovação, restrinja os branches ou tags de lançamento e desative a possibilidade de administradores contornarem a proteção, quando houver suporte. Verifique a disponibilidade desses recursos para o repositório e o plano. Por padrão, o GitHub permite que administradores contornem a proteção de ambientes; apenas dar um nome ao ambiente não basta.
• Torne a aprovação específica: registre a revisão do código-fonte, a execução do build e o digest do artefato no registro de lançamento e publique exatamente os bytes revisados. Confira a identidade do atestado e as informações sobre o código-fonte com esse registro. Investigue divergências em vez de usar um selo de proveniência como critério para decidir pela publicação.
• Revise o código dos workflows e as ações de terceiros. Conceda aos tokens do repositório apenas as permissões mínimas e fixe as ações em identificadores completos de commits revisados. Nunca imprima credenciais nem despeje as variáveis de ambiente para depuração. O GitHub alerta que o mascaramento automático de logs pode falhar, inclusive quando os valores são transformados; examine os logs dos caminhos de falha e também os das execuções bem-sucedidas.
• Após a migração, remova tokens de publicação sem uso e audite os cadastros de publicadores confiáveis. No PyPI, esses cadastros pertencem aos projetos e permanecem mesmo após a remoção de quem os criou. Inclua-os explicitamente no processo de desligamento de mantenedores.

Armadilhas

Uma etapa obrigatória de aprovação não compensa uma conta de aprovador comprometida nem alterações não revisadas na própria etapa. Um cache de build reutilizável e um runner persistente precisam de avaliações de confiança próprias. Registre como falhas de lançamento as verificações de identidade ou de artefato rejeitadas; recorrer silenciosamente a um token de escrita armazenado enfraquece o controle pretendido.