Dependabot新增匿名组织级注册表配置

如果组织里的 Dependabot 访问私有镜像时并不需要账号或令牌，GitHub 现在提供了更准确的配置方式：组织级私有注册表可以选择 Anonymous 作为认证方式。它不是把匿名访问“伪装”成一个占位令牌，而是把注册表的认证模型明确记录下来。

官方公告：https://github.blog/changelog/2026-10-12-anonymous-organization-level-registries-for-dependabot/

截至这次公告，Anonymous 已在 github.com 正式可用，GitHub Enterprise Server 计划从 3.24 开始提供。已有注册表不能直接修改认证方式；如果以前用占位令牌，应该删除旧条目，再用 Anonymous 重新创建。

这次变化解决的是哪一种注册表问题

我会先把判断条件收窄：你的内部镜像必须允许 Dependabot 在没有凭据的情况下读取。比如内部只读镜像开放了匿名读取，或者网络边界已经用其他方式限制了来源，此时继续填写一个“看起来像令牌”的占位值，反而会让配置含义变得模糊。Anonymous 的价值是让组织设置直接表达“这里不需要凭据”。

这项能力针对的是组织级私有注册表，不等于所有仓库配置都自动变成匿名访问。Dependabot 仍然要能够到达注册表主机；github.com 上的更新任务只会访问允许的外部主机和已配置的私有注册表。只在 .npmrc、nuget.config 等生态文件里写地址，并不能替代 Dependabot 侧的注册表配置。

组织级配置会影响哪些仓库

公告里最容易被忽略的一点，是组织级注册表不是只服务某一个已经写了 dependabot.yml 的仓库。只要仓库被授予该注册表的访问范围，它就可能在对应的 Dependabot 更新任务中使用这份定义。

这也包括只启用 Dependabot 安全更新、没有 dependabot.yml 文件的仓库。换句话说，排查“为什么这个仓库突然能够读取镜像”时，不能只打开仓库里的配置文件，还要回到组织的 Private registries 页面核对仓库授权范围。

官方文档入口：

私有注册表配置文档：https://docs.github.com/en/code-security/how-tos/secure-at-scale/configure-organization-security/manage-usage-and-access/giving-org-access-private-registries

按官方路径重新创建 Anonymous 注册表

1. 进入组织的 Settings，在安全相关区域打开 Secrets and variables。
2. 选择 Private registries，点击 New private registry。
3. 填写注册表的 URL 和类型，在认证方式中选择 Anonymous。
4. 选择允许使用它的仓库范围，保存配置。

如果旧条目是为了绕过表单而填写的占位令牌，不要尝试在原条目上寻找“切换认证方式”的按钮。GitHub 的公告明确说明，注册表创建后不能修改认证方式；正确动作是删除旧条目并重新添加。

这里有一个实际的排查顺序：先确认镜像的匿名读取确实成立，再确认组织级条目授权了目标仓库，最后查看 Dependabot 作业是否因为主机未被允许而被阻断。这样能把“认证失败”和“主机不可达”区分开。

发布后最值得核对的三个边界

如果作业日志出现网络或认证错误，先查 Dependabot 的代理日志是否指出了未被允许的主机。官方说明建议把组织私有或专用注册表配置在对应的 Dependabot 注册表范围中，而不是把它当作所有任务共享的默认主机。

常见问题

Anonymous 会不会让私有注册表暴露给所有仓库？

不会自动扩大到所有仓库。组织级注册表仍然需要配置可访问的仓库范围；需要重点复查的是保存配置时选中的授权集合。

已经创建的 Token 注册表能直接改成 Anonymous 吗？

不能。认证方式创建后不可修改；如果确实要改成匿名，需要删除原条目并重新创建。

只在 npm 或 NuGet 的配置文件中写私有镜像够不够？

不够。GitHub 的 Dependabot 作业还要知道要访问的注册表主机，并受出站访问范围控制；生态文件中的地址不能替代这层配置。

这次更新的重点不是增加一个“免密开关”，而是让组织级注册表的认证语义与实际访问方式一致。先判断镜像是否真的允许匿名读取，再按组织范围重新创建，最后分别核对平台版本、仓库授权和主机可达性，就能避开占位令牌和文件配置造成的误判。