Trusted publishing no npm: remover o token não resolve uma identidade reciclável

O GitHub passou a expirar configurações de trusted publishing do npm que não forem validadas em 48 horas.[5] A primeira publicação bem-sucedida vincula a relação à identidade imutável do repositório.[5] A mudança responde à pesquisa SlugFest, da Bloom Security, sobre um caminho de sequestro de pacotes sem roubo de credenciais.[5] É uma correção na associação de confiança, não uma razão para voltar a guardar tokens permanentes.

O que muda para quem desenvolve

Antes da validação inicial, a configuração confiava no endereço legível proprietário/repositório, e não no identificador permanente presente no token OIDC.[5] Se o projeto fosse renomeado, transferido ou removido e o endereço pudesse ser reivindicado, uma relação nunca utilizada podia confiar em outro repositório.[5]

A publicação confiável usa tokens OIDC de curta duração emitidos pelo ambiente de CI/CD e gera atestações de proveniência.[5] O caso mostra que autenticar corretamente uma declaração não basta quando o identificador interpretado como identidade pode trocar de dono.

Na minha leitura, há uma diferença entre endereço e identidade que deveria aparecer no modelo de ameaças. Nomes são úteis para configuração e leitura humana. Para conceder publicação, acesso ou assinatura, proponha verificar se a autorização continua apontando para o mesmo objeto após mudanças administrativas.

A Bloom identificou mais de 1.500 pacotes potencialmente vulneráveis, com mais de 10 milhões de downloads acumulados.[5] Isso descreve exposição potencial, não comprova que esses pacotes receberam versões maliciosas.[5]

Como aplicar

Configure a relação de confiança perto da primeira publicação planejada. Faça essa publicação por um fluxo controlado e registre a confirmação de que a associação foi validada. Evite preparar permissões que ficarão abandonadas por tempo indeterminado.

Inclua renomeação e transferência de repositórios na lista de mudanças de release. A reportagem orienta revisar associações e remover e recriar relações depois dessas alterações.[5] Dê a essa tarefa um responsável, em vez de presumir que o registry acompanhará automaticamente a mudança.

Um exercício seguro é desenhar o ciclo de vida de uma associação em um pacote de teste: criação, primeira publicação, alteração de identidade e nova configuração. Antes de executar cada etapa, defina qual projeto deveria estar autorizado. Compare o estado observado com essa expectativa sem tentar reivindicar nomes de terceiros.

Cuidados e limites

A política também rejeita tokens originados de issue_comment, além da restrição já existente para pull_request_target.[5] Portanto, revise o evento que inicia o fluxo, não apenas o usuário configurado no registry.

Edições comuns não reiniciam a janela de validação; mudar a identidade exige uma nova relação.[5] Não use a expiração como justificativa para ignorar higiene de configuração. Para agentes que sugerem dependências ou releases, mantenha revisão da origem e aprovação das ações relevantes. Automação pode acelerar a operação correta e a incorreta com a mesma eficiência.

Fonte

[5] Fonte: The Hacker News