NuGet API key 11 月大限：GitHub Actions 同 Azure DevOps 執漏清單
先分清發佈目標，再揀 OIDC 或 30 日輪換方案
11 月前唔改，pipeline 可以照綠但發佈失敗
iThome 報道，NuGet.org 由 2026 年 8 月 17 日起，新開嘅 API key 最長只可用 30 日，原本 365 日嘅選項會取消。喺嗰日之前建立嘅 key，無論本身寫住幾時到期，都會喺 11 月 1 日失效。影響集中喺 package 發佈：build、測試同產生 .nupkg 仍然可能全部成功，到最後 dotnet nuget push 先報錯，所以一般 CI 健康檢查未必會提早捉到。
NuGet 官方公告講得幾直接：API key 本質上就似發佈密碼，長期擺喺 repo secret、service connection 或 build 設定，一旦洩漏，攻擊者會有較長時間冒充維護者推出新版本。縮到 30 日只係減少 key 洩漏後可以俾人濫用嘅時間，唔代表洩漏嗰刻冇風險；官方亦預告日後可能再縮短效期，所以每月人手換 key 只適合做過渡安排。
圖片：Microsoft .NET Blog
第一步：搵齊所有真正會推 package 嘅位置
先喺 GitHub Actions、Azure Pipelines、release script 同共用模板搜尋 dotnet nuget push、nuget push、api.nuget.org、NUGET_API_KEY 同相關 secret 名稱。跟住查埋 GitHub organization secret、Azure DevOps variable group、Key Vault、NuGet service connection 同舊式 nuget.config。盤點表至少記低 repo、pipeline、package owner、發佈目標、key 建立日、scope、保管位置同負責人；淨係望 nuget.org 帳戶入面有幾多 key，通常搵唔出邊條 pipeline 仲用緊佢。
GitHub Actions：有條件就直接轉 OIDC
GitHub Actions 而家有完整嘅 NuGet Trusted Publishing 路線。維護者先喺 nuget.org 建立 policy，綁定 package owner、GitHub repo、workflow 檔案同可選嘅 environment；workflow 再加入 id-token: write，用 NuGet/login@v1 換取臨時 API key。呢條 key 只得 1 小時效期，每個 OIDC token 亦只可換一次，應該放近 push 步驟先申請。咁做之後，GitHub secrets 入面就唔使再長期擺可重用嘅發佈 key。
遷移期間可以暫時留住現有 API key 做後備，再揀一個風險較低嘅 package 試發佈；亦可以等下一次正常出版本時，確認 owner、workflow 檔名、environment 同權限設定全部對得上。私有 GitHub repo 嘅 policy 可能先得 7 日臨時啟用期，要有一次成功發佈先會完成綁定；測試通過後，再移除 workflow 對舊 secret 嘅引用，最後喺 nuget.org 刪走舊 key。次序唔好倒轉，否則 policy 一個字填錯都可以即場截停 release。
Azure DevOps：先睇 source URL，兩種 key 完全兩回事
Azure Pipeline 跑 NuGet task，唔代表 package 一定發佈去 Azure Artifacts。若果 source 係 https://api.nuget.org/v3/index.json，pipeline 多數仍靠 NuGet.org API key，可能收藏喺 NuGet service connection；呢批 key 會受 30 日同 11 月死線影響。NuGet 官方現階段列出嘅 Trusted Publishing 對象係 GitHub Actions 同 GitLab，Azure DevOps 團隊短期要安排換 key、限制 package scope、確認到期通知有人睇，同喺每次 release 前檢查剩餘日數。
如果 source 指向 pkgs.dev.azure.com 嘅內部 Azure Artifacts feed，情況就唔同。Microsoft 文件講明，nuget.exe push 嗰個 -ApiKey 參數可以填任意字串，實際認證靠 Azure Artifacts Credential Provider、build identity 或相關 service connection；NuGet.org 今次改例唔會令呢類內部 feed key 喺 11 月失效。盤點時按目標 registry 分組，可以避免團隊忙住輪換一批根本冇受影響嘅設定。
11 月前可以照住呢個次序收尾
8 月內完成盤點，9 月前揀好每條 pipeline 嘅方案，10 月做一次真實發佈驗證。 GitHub Actions 同 GitLab 優先轉 Trusted Publishing；Azure DevOps 發佈去 NuGet.org，就建立 scope 最窄嘅 30 日 key，更新 service connection，確認舊 key 已停用，同安排下一次輪換日期。最後加一個 release smoke check，至少驗證發佈 credential 可用、source URL 正確同負責人收得到到期通知。等到 11 月 1 日先靠失敗訊息逐條執，最易撞正緊急修補版本要出街。
參考來源
- iThome — NuGet將API金鑰效期縮至30天，11月起既有金鑰全面失效 — original report
- Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime — NuGet 官方公告，確認 8 月 17 日、11 月 1 日、30 日上限同官方遷移建議。
- Trusted Publishing on nuget.org — Microsoft 官方設定文件，確認 GitHub Actions、GitLab、OIDC policy 同 1 小時臨時 key 嘅運作。
- Publish NuGet packages to NuGet.org with Azure Pipelines — 用嚟確認 Azure Pipelines 發佈去 NuGet.org 時，API key 會放入 NuGet service connection。
- Publish and download NuGet packages with Azure Artifacts — 用嚟分清 Azure Artifacts 內部 feed 嘅認證，同 NuGet.org API key 並非同一套機制。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
