許多開發者在將套件發佈到 NuGet.org 時，習慣使用 API Key 作為驗證憑證。然而，長期有效的 API Key 在現代的軟體供應鏈安全中已成為一個巨大的風險漏洞。為了強化生態系安全性，NuGet 官方正式宣布將大幅縮短 API Key 的有效期，並推動開發者轉向使用 Trusted Publishing 驗證機制。
為什麼長期有效的 API Key 是危險的
在工程實務中，API Key 本質上就像是一把能直接開啟發佈權限的鑰匙。許多團隊為了方便，會將這把鑰匙存放在 CI/CD 系統的 Secret 變數中，或是嵌入在建置設定檔裡。
問題在於，API Key 是靜態的字串，一旦發生洩漏（例如不小心 commit 到 Git 倉庫、日誌洩漏或系統被入侵），攻擊者就能在 Key 失效前，持續地發佈惡意版本的套件。這種攻擊被稱為供應鏈攻擊（Supply Chain Attack），其影響範圍極廣。例如先前發生的 NX Console 事件，攻擊者利用盜取的憑證發佈惡意套件，在短短 36 分鐘內就被下載超過 6000 次。如果憑證有效期很長，攻擊者就有更多時間在不被察覺的情況下進行破壞。
NuGet API Key 的有效期變更時程
為了降低洩漏後的損害範圍（Blast Radius），NuGet 採取了強制縮短生命週期的策略。請注意以下關鍵時間點：
2026 年 8 月 17 日起，所有新申請的 API Key 最高有效期將被限制在 30 天，不再提供原先的 365 天長效選項。
2026 年 11 月 1 日起，所有在 8 月 17 日之前建立的舊有 API Key 將全部失效。
這意味著如果你目前的自動化流程依賴於長效 Key，屆時將會導致發佈流程中斷。
推薦方案：遷移至 Trusted Publishing
面對 API Key 的限制，官方推薦的解決方案是 Trusted Publishing（信任發佈）。這是一套基於 OpenID Connect (OIDC) 的現代化驗證流程。
什麼是 OIDC 以及它如何運作
OIDC 是一種身分層協議，它允許 CI/CD 平台（如 GitHub Actions 或 GitLab）在不需要儲存靜態密鑰的情況下，向 NuGet.org 證明自己的身分。
在 Trusted Publishing 流程中，CI/CD 系統會產生一個短期且經過簽名的身分權杖（Identity Token）。NuGet.org 收到權杖後，會根據開發者預先設定的策略（例如：必須來自特定的 GitHub 倉庫或特定的工作流分支）來驗證該權杖。驗證通過後，NuGet.org 會動態核發一個僅限本次操作使用的臨時 API Key。
Trusted Publishing 的實務優勢
首先是消除靜態密鑰儲存。你不再需要在 CI/CD 的 Secrets 區塊中維護長期的 API Key，從根源上解決了密鑰洩漏的風險。
其次是自動化生命週期管理。憑證是短暫且自動過期的，不需要工程師手動進行密鑰輪替（Secret Rotation）。
最後是更精準的權限控制。你可以定義只有在特定環境或特定分支的 Pipeline 才能觸發發佈，增加了身分驗證的維度。
如果你必須繼續使用 API Key
雖然 OIDC 是首選，但並非所有 CI/CD 環境都支援。如果你暫時無法遷移，請採取以下安全措施：
盤點所有發佈流程，確認哪些 Key 將在 2026 年 11 月失效。
更新自動化腳本，使其能夠處理 30 天一次的 Key 輪替。
遵循最小權限原則，僅授予該 Key 必要的套件範圍與權限。
絕對禁止將 API Key 提交至版本控制系統或輸出至日誌。
確保 API Key 到期通知能發送到被積極監控的電子信箱。
總結與建議
對於 Junior 工程師而言，理解這個變動的核心在於從 靜態憑證（Static Credentials）轉向 動態身分（Dynamic Identity）。在現代 DevOps 實踐中，任何長效且可重複使用的密鑰都是潛在的資安漏洞。
如果你目前使用 GitHub Actions 或 GitLab，請立即開始研究並遷移至 Trusted Publishing。這不僅是為了應對 2026 年的失效期限，更是為了建立一個更安全、更自動化的軟體交付流程。
來源：devblogs.microsoft.com - Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。