写过私有包的人都踩过这个坑——Dependabot 每次读内部包都要配一个 PAT，今天这件事被 GitHub 彻底原生化了

写过私有包的人都踩过这个坑——Dependabot 每次想读一个内部包，都要先在 GitHub 上生成一个有 read 权限的 Personal Access Token，再把它粘贴到 dependabot.yml 里。Token 过期了没 rotation，Dependabot 就静默失败，安全扫描也断了。今天这件事被 GitHub 用一个新的认证机制彻底原生化了。

2026 年 9 月 8 日，GitHub 正式上线了 Dependabot 对 GitHub Packages 私有注册表的免 PAT 认证。如果你给一个包配置了「Manage Actions access」里允许某个仓库的 Actions 用 GITHUB_TOKEN 读它，那 Dependabot 在跑更新的时候就会自动复用同一套权限——不再需要单独配一个 PAT，也不需要在 dependabot.yml 里写任何 registry 配置。

这个变化解决的是一个实打实的供应链安全风险。以前的流程里，PAT 要写在 dependabot.yml 里，而 yml 文件在 PR diff 里是可见的——只要有人把包含 PAT 的配置 push 上去，Token 就暴露了。这个问题的本质不是配置错误，而是「把长期有效凭证写进代码里」这件事本身就不应该发生。现在 Dependabot 直接用 Actions workflow 的 token，它本身是短生命周期的、受 GitHub 管理的、不会出现在 diff 里。

具体怎么配：去包的 Settings → Packages → Manage Actions access，给跑 Dependabot 的那个仓库加上 Read 权限。配完之后，Dependabot 会自动拿到访问权，原来 dependabot.yml 里写的 registries: - name: github-org 那段 PAT 配置就可以删掉了。GitHub Packages 支持的所有生态（npm/Docker/Maven/NuGet 等）都适用这个逻辑。

补充一个工程细节：GitHub 最初在 2026 年 6 月 23 日就上线了这个功能，但很快回滚了——因为发现了一个 bug，让某些 npm update 任务的共有包也错误地走了 GitHub Packages 的认证路径。现在重新上线后，认证顺序变成了：显式配置的 registry credentials 优先 → 自动 GITHUB_TOKEN 兜底 → PAT 最后 fallback。原来的 bug 已经修了，配置上不需要担心公私有包路由混乱。

下一步：如果团队里有私有包靠 Dependabot 维护，先去包的 Settings 里确认「Manage Actions access」配置正确，然后在 staging 仓库里把 PAT 配置移除，验证 Dependabot PR 依然正常，最后推送到生产。