Microsoft traz Trusted Publishing ao NuGet: Como aplicar e proteger pacotes com exemplo real no ReactiveLock

Sumário

Mostrar/Ocultar

Introdução

A Microsoft lançou recentemente o Trusted Publishing no NuGet, eliminando a necessidade de tokens de API permanentes (ou de alta duração) para publicar pacotes .NET. Este recurso é essencial para proteger a cadeia de suprimentos de pacotes contra ataques (supply chain attacks), garantindo que apenas workflows confiáveis possam publicar versões oficiais.

Ataques de supply chain já vêm acontecendo em outros ecossistemas, como o npm, onde invasores conseguiram injetar código malicioso em pacotes populares ou em dependências indiretas, comprometendo projetos que consumiam essas bibliotecas. Esses incidentes mostram a importância de mecanismos de segurança que garantem a autenticidade e a rastreabilidade das publicações, exatamente como o Trusted Publishing propõe para o NuGet.

Por que é importante

Tokens de alta duração armazenados em secrets podem vazar e ser usados para publicar pacotes comprometidos. O Trusted Publishing:

Substitui tokens de alta duração por chaves temporárias, válidas apenas durante a execução do workflow.
Garante que apenas pipelines autorizados e validados pelo NuGet possam publicar pacotes.
Melhora a rastreabilidade: é possível identificar qual execução publicou cada pacote.
Reduz o risco de ataques à cadeia de suprimentos (supply chain attacks).

Como aplicar

1. Criar política Trusted Publishing no NuGet

Acesse NuGet e faça login.
Vá para a seção Trusted Publishing.
Crie uma nova política indicando:
- Proprietário do pacote (usuário ou organização).
- Repositório GitHub que fará a publicação.
- Nome do arquivo de workflow YAML que publicará o pacote.
- (Opcional) Environment se você usar ambientes no GitHub Actions.
Para repositórios privados, a política fica provisória por 7 dias até a primeira execução válida.

2. Ajustar workflow do GitHub Actions

No .github/workflows/<workflow>.yml:

permissions:
  # Esta permissão permite que o GitHub Actions emita um token OIDC para o workflow.
  # O token OIDC é usado pelo NuGet para validar a identidade do workflow e emitir
  # uma chave API temporária. Sem esta permissão, o Trusted Publishing não funcionaria.
  id-token: write

jobs:
  build-and-publish:
    permissions:
      # Aqui reafirmamos que este job específico também pode gerar o token OIDC.
      # É obrigatório para que a ação `NuGet/login@v1` consiga trocar o token por
      # uma chave temporária e publicar o pacote de forma segura.
      id-token: write
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      # Build, testes e geração do .nupkg

      # A nova action `NuGet/login@v1` realiza a autenticação no NuGet usando o token OIDC
      # gerado pelo GitHub Actions. Ela solicita ao NuGet uma **chave API temporária** 
      # válida apenas para esta execução do workflow. Dessa forma, não é necessário 
      # armazenar tokens permanentes nos secrets do repositório.
      - name: NuGet login (OIDC → chave temporária)
        uses: NuGet/login@v1
        id: login
        with:
          # Novo secret NUGET_USER (usuário do nuget, não é o e-mail)
          user: ${{ secrets.NUGET_USER }}

      # O comando `dotnet nuget push` utiliza a chave temporária fornecida pelo 
      # passo anterior (`steps.login.outputs.NUGET_API_KEY`) para publicar o pacote.
      # Como a chave é de curta duração e única para esta execução, aumenta-se a 
      # segurança e a rastreabilidade das publicações.
      - name: Publicar pacote
        run: dotnet nuget push **/*.nupkg \
             --source https://api.nuget.org/v3/index.json \
             --api-key ${{ steps.login.outputs.NUGET_API_KEY }}

Notas importantes:

id-token: write é necessário para gerar o token OIDC.
NuGet/login@v1 troca o token OIDC por uma chave temporária, válida apenas para aquela execução.
Não é mais necessário armazenar chaves de alta duração como secrets.

Como o Trusted Publishing funciona no NuGet

3. Migrar de chaves antigas

Crie a política Trusted Publishing primeiro.
Ajuste o workflow conforme acima.
Teste a publicação via workflow.
Remova tokens de alta duração antigos dos secrets após confirmar que o fluxo Trusted Publishing funciona.

Exemplo real: ReactiveLock

No PR micheloliveira‑com/ReactiveLock #34 é possível ver a aplicação prática:

Permissões id-token: write no workflow.
Uso da ação NuGet/login@v1 para gerar a chave temporária.
Publicação de pacotes sem depender de tokens permanentes, garantindo que apenas workflows confiáveis publiquem o pacote ReactiveLock.

Conclusão

O Trusted Publishing moderniza a publicação de pacotes .NET e é essencial para proteger seus pacotes contra ataques de supply chain, garantindo rastreabilidade e segurança na publicação de bibliotecas como o ReactiveLock.