Dependabot终于不必保存PAT：私有包权限仍要手动授予

GitHub于2026年9月8日重新启用Dependabot对私有GitHub Packages的自动访问。GitHub更新说明 显示，Dependabot作业现在可让GITHUB_TOKEN申请packages: read，并在从*.pkg.github.com或ghcr.io拉取依赖时发送该令牌；对于符合条件的GitHub托管包，团队不必再保存PAT。

这项9月8日恢复的能力并不等于私有包自动向所有仓库开放。GITHUB_TOKEN只替代这条访问路径中的个人凭据，目标包仍须通过有效的权限继承，或通过Manage Actions access向运行Dependabot的仓库授予Read权限。

变化的是凭据链，不是包的访问边界

此前，团队通常需要创建具有包读取能力的PAT，把它保存为Dependabot secret，再从dependabot.yml的registries配置中引用。令牌的期限、撤销和持有人变动都可能影响后续更新作业。

新流程由Dependabot作业使用GITHUB_TOKEN请求packages: read，GitHub Packages随后检查目标包是否允许该仓库读取。符合条件时，无需增加PAT型注册表条目，也无需修改dependabot.yml；这减少了长期保存个人凭据的需求，但没有赋予Dependabot写入、发布或管理包的权限。

• 原有路径：创建PAT → 保存Dependabot secret → 在dependabot.yml中引用凭据 → 注册表验证PAT。
• 自动路径：包向消费仓库开放Read → Dependabot作业请求packages: read → GITHUB_TOKEN从GitHub托管注册表读取包。

因此，标题中的“不必保存PAT”有明确边界：它针对Dependabot访问已授权的私有GitHub Packages，而不是所有私有注册表，也不是所有涉及PAT的GitHub操作。第三方注册表仍须采用其支持的静态凭据、OIDC或其他认证方式。

适用范围由托管位置和生态支持共同决定

自动认证适用于Dependabot所支持的全部GitHub Packages生态，包括其支持的Container registry容器镜像场景。判断标准不是依赖是否“与GitHub有关”，而是包是否位于GitHub托管注册表、相应生态是否受Dependabot支持，以及消费仓库是否已经取得包的读取权。

请求目的地也给出了清晰边界：新令牌用于*.pkg.github.com和ghcr.io。自建注册表、云制品库以及其他第三方私有源不在这条自动访问路径内，删除它们原有的认证配置可能直接导致更新失败。

还需区分注册表支持与包权限模型。部分包可以继承关联仓库的权限，部分包则使用独立的细粒度权限；新认证机制复用现有授权结果，不会把一种权限模型转换为另一种。

Manage Actions access仍需逐包确认

对于需要单独授权的包，管理员应打开Package settings，在Manage Actions access中添加实际运行Dependabot的仓库，并选择Read。GitHub包权限文档 明确指出，这项仓库授权也允许Dependabot自动拉取包，且不要求PAT或dependabot.yml注册表配置；它与把包关联到源代码仓库不是同一操作。

1. 从个人账号或组织的Packages页打开目标包并进入Package settings。
2. 确认包是否继承已关联仓库的访问权限。
3. 若运行Dependabot的消费仓库尚未获得访问权，在Manage Actions access中选择Add repository。
4. 添加该消费仓库，并把角色设为Read。
5. 对Dependabot需要读取的每个独立授权包分别检查。

权限继承可能省去手动添加：包若在发布前已经关联仓库，默认可继承该仓库的访问权限，关联仓库中的工作流也会取得访问权。但发布后才从设置页连接仓库时，包会保留原有权限，除非管理员明确启用继承；组织所有者也可以关闭新包的自动继承。

Read已经覆盖下载包及读取包元数据的需要，Dependabot无需Write或Admin。若向公共仓库授予私有包访问权，还要考虑该仓库的派生仓库可能获得访问的风险。

六月回滚解释了为何要先核对路由

这项功能最初于2026年6月23日上线，随后因部分npm更新作业错误地通过GitHub Packages解析公共包而被临时回滚。9月8日恢复后，GitHub把自动提供的GitHub Packages凭据限定为后备认证：显式注册表凭据与正常注册表路由继续优先。

近期独立报道也确认该能力已经恢复，以及Manage Actions access仍是授权条件；但 DevOps.com的9月9日报道 把新令牌描述为默认认证、把PAT描述为后备路径，这与GitHub更新说明写明的优先顺序相反。涉及迁移行为时，应以GitHub的产品说明为准：只要dependabot.yml仍有显式凭据，它就可能继续优先生效。

这意味着一次成功的更新不一定证明自动GITHUB_TOKEN路径已经接管。如果旧PAT条目仍被引用，作业成功可能只说明原路径仍然可用；同时，npm scope、锁文件中的resolved地址和显式registry设置仍可能影响公共包与私有包分别被送往哪里。

删除旧PAT前应验证授权与解析路径

迁移时可先盘点私有包、运行Dependabot的消费仓库以及实际注册表地址，再补齐包级Read授权。随后在一个容易回退的配置变更中移除相应PAT条目，运行一次真实的Dependabot更新，确认私有依赖来自预期的GitHub托管注册表，公共依赖仍沿正常公共注册表路由解析。

• 确认私有依赖指向*.pkg.github.com或ghcr.io。
• 核对npm scope、registry设置和锁文件中的解析地址。
• 测试时可先保留旧secret，只移除对它的引用。
• 自动路径验证成功后，再删除无消费者的secret并撤销PAT。

若作业失败，恢复原有registry配置和secret引用即可回到旧路径；扩大GITHUB_TOKEN权限不能修复错误的包授权或注册表路由。排查应分别覆盖目标包是否授予Read、消费仓库是否正确、依赖是否到达GitHub托管端点，以及显式配置是否覆盖了自动路径。

目前可以确定的是，Dependabot读取已授权的私有GitHub Packages已不再必须保存PAT，第三方私有注册表则不受此次变化影响。管理员仍需维护包与仓库之间的信任关系，而六月的回滚记录也意味着：在确认私有包访问与公共包路由都正常之前，不宜直接撤销旧凭据。