Dependabot 讀不到私有 GitHub Packages？用 Manage Actions access 免 PAT

先確認是不是這個問題#

下面情況才適合改用免 PAT 流程：

• 相依套件存放在 GitHub Packages，而不是 npmjs、Artifactory、Azure Artifacts 或其他外部 registry。
• Dependabot 工作的 repository 與目標 package 都可由有權限的管理者設定存取。
• update log 顯示 private package 驗證或讀取失敗，而一般公開 package 仍能解析。
• package 使用 granular permissions，或設定頁確實能看到 Manage Actions access。

若錯誤是 package 名稱、版本範圍、lockfile、網路或 ecosystem 不受支援，授予 Read 不會解決。先在 repository 的 Dependabot update log 保存失敗訊息、registry host、package 名稱與執行時間，避免把不同來源的 401、403 或 404 全部當成同一種權限問題。

設定 Manage Actions access 的步驟#

對每個 private package 執行：

1. 開啟 GitHub Packages 的 package 頁面，進入 Package settings。
2. 找到 Manage Actions access，選擇 Add repository。
3. 加入實際執行 Dependabot 的 repository，權限選 Read。
4. 回到 repository，重新執行或等待下一次 Dependabot version update。
5. 在 update log 確認 package metadata 與版本可成功讀取，再處理舊 PAT。

「package 已連結到 repository」和「repository 已取得 Manage Actions access」不是同一件事。連結常用來顯示來源與繼承設定，不保證 Dependabot 已拿到讀取 package 的權限；驗收時要回到 access 清單確認 repository 與 Read 狀態。

這個設定不需要在 dependabot.yml 新增 token，也不要求建立一個只為讀取 GitHub Packages 使用的 registries 區塊。若同一個更新同時依賴外部 registry，外部來源的設定仍須保留。

從 PAT 遷移時，先驗證再刪 secret#

不要先刪 PAT，再觀察排程會不會恢復。較安全的順序是：

1. 列出 dependabot.yml 目前的 registries、updates[].registries 與所引用的 Dependabot secrets。
2. 對需要的 GitHub Packages package 授予 repository Read access。
3. 保留現況執行一次 Dependabot update，確認工作成功且取到預期 package 版本。
4. 用獨立 PR 移除只為 GitHub Packages 建立的舊 registry credential 引用。
5. 再執行一次 update；確認成功後，才刪除已無 consumer 的 Dependabot secret 與 PAT。

刪 secret 前要搜尋是否還有 Actions workflow、其他 repository 或 automation 共用同一個 PAT。GitHub Packages 的免 PAT 流程只取代這個特定讀取用途，不會自動搬移其他 consumer。

為什麼先前推出後又暫停#

GitHub 曾在 2026 年 6 月 23 日推出這項功能，之後因部分 npm 公開套件被錯誤嘗試從 GitHub Packages 解析而回復。9 月 8 日重新啟用時，GitHub Packages 的自動 credential 改成 fallback：明確設定的 registry credential 與正常 package routing 會先處理，只有符合條件時才使用自動權限。

因此，免 PAT 不代表 Dependabot 會把所有 package 都導向 GitHub Packages。若公開 npm package 仍出現錯誤 host，應檢查：

• lockfile 是否保存錯誤的 resolved URL。
• ecosystem 的 registry／scope 設定是否把公開 package 指到 GitHub Packages。
• dependabot.yml 是否仍有過度寬廣的 explicit registry 設定。
• package manager 設定檔，例如 .npmrc，是否把 default registry 改寫。

先修正 routing，再處理 credential；用增加 token 來掩蓋錯誤 host，之後只會留下更難辨認的供應鏈路徑。

公開 repository 要特別檢查 fork 風險#

GitHub Packages 文件提醒：private package 若授權給 public repository，該 repository 的 fork 可能取得 private package 的存取能力。這是 package access model 的結果，不會因為沒有 PAT 就自動消失。

授權前至少確認：

• repository 是否真的需要在公開範圍執行相依更新。
• package 是否含有內部程式碼、客戶名稱、版本資訊或其他不應被 fork 取得的內容。
• organization 是否啟用 repository access inheritance；package 從連結 repository 繼承權限時，管理畫面可能和逐一設定不同。
• 能否改由 private mirror、不同 package 邊界或受限 repository 執行更新。

最小權限不只是把角色選成 Read，也包含只授權真正需要的 repository 與 package。每個 package 都應能說明 consumer、owner 與撤銷條件。

仍然失敗時怎麼分流#

若 update log 顯示套件版本遭安全機制攔下，也要和一般權限問題分開，可再對照 Dependabot malware alerts 的處理流程。認證成功只代表 package 可讀，不代表該版本一定應該被採用。

完成條件#

免 PAT 遷移完成時，應同時具備以下證據：

• package 的 Manage Actions access 明列正確 repository 與 Read 權限。
• Dependabot update log 已成功讀取 private package，且 registry host 符合預期。
• dependabot.yml 沒有為自動 GitHub Packages 存取新增多餘 credential。
• 舊 PAT 引用、secret 與其他 consumer 已盤點；只刪除確定無人使用的項目。
• public repository 的 fork 風險與 access inheritance 已完成審查。
• 外部 private registries 的認證仍可正常執行。

真正的改善不是「把 PAT 欄位刪掉」，而是把 package 授權放回 package access model，讓 repository 只取得需要的 Read 權限，並用 update log 證明 fallback、routing 與撤銷流程都符合預期。

常見問題#