GitHub 为所有仓库设立永久所有者

背景

GitHub 内部主组织下拥有超过 14,000 个仓库。截至 2025 年初，其中超过 11,000 个仓库未被归档，但绝大多数缺乏明确的所有者。对于与生产服务绑定的仓库，GitHub 历史上拥有可靠的持久所有权；但对于没有关联服务的仓库，无法可靠判断谁是其所有者。这一缺口在机密扫描修复工作中反复出现问题：技术上可以轮换密钥，但不知所有者的情况下操作风险高且具有破坏性，也没有明确的修复路线。在六个星期内，GitHub 为每个活跃仓库验证了所有者，归档了约 8,000 个不再使用的仓库，并改变了仓库创建流程，要求从创建时就必须指定所有者。

核心内容

原有所有权模型

多年来，GitHub 通过内部 Service Catalog 跟踪已部署服务的所有权。每个服务条目记录所属仓库、负责团队、执行发起人、支持信息等元数据。例如，Repo Ownership 应用中的服务条目包含 team、repo、name、kind、long_name、description、maintainer、exec_sponsor 等字段。这些丰富的元数据支持以服务为中心的工作流，如事件响应、值班路由、漏洞管理和合规范围界定。

但这种关系是多对一的：一个服务只能关联一个仓库，但一个仓库可以对应多个服务。这意味着从服务出发可以找到仓库及其所有者，但从仓库出发反向查找所有者时，只有那些映射到服务的仓库才能成功。这留下了巨大的所有权空白，包括团队仓库、文档仓库、内部工具、一次性项目仓库、个人实验仓库等。每次需要联系这些“无主”仓库的所有者时，都需要手动检查提交历史、阅读 README、在 Slack 中询问或根据仓库名猜测。对于一次性工作，这种模糊性可以忍受，但对于需要辐射全组织的安全工作流，这构成了实际风险。在机密扫描清理中，团队花费大量时间寻找正确所有者，然后才能对告警做出明智决策。

设计新所有权模型

GitHub 决定将仓库所有权作为一等属性。他们考虑过在每个仓库内存储专用文件或在集中仓库中维护，但最终选择了 GitHub custom properties。这种方法提供了原生、结构化且可全组织查询的管理方式，还能根据所有权类型选择性执行企业策略和规则集。

创建了两个自定义属性：ownership-type 和 ownership-name。

• ownership-type 接受三个值：Service Catalog、Hubber Handle（Hubber 是 GitHub 对员工的称呼）和 Team。这覆盖了 GitHub 仓库所有权的实际范围：仓库要么属于某个服务（有值班团队和生命周期）、要么属于某个团队（如共享文档仓库或内部工具）、要么属于个人（如个人项目或实验）。
• ownership-name 是文本字段，带有轻量验证。GitHub App 会验证每个值：Hubber 句柄会对照组织成员检查，团队会验证存在于组织中且至少有两人，Service Catalog 条目会与 Service Catalog 本身确认。格式上故意宽松，如果用户输入 @my-team 而不是 my-team，也会接受。目标是让添加所有权无摩擦，依靠健壮的验证来捕获无效条目（如不存在的团队、前员工、已退役的服务）。

首日覆盖

在要求任何人做任何事之前，Team 构建了一个从 Service Catalog 到仓库自定义属性的定期同步。每个对应已知服务的仓库自动将其 ownership-type 设为 Service Catalog，ownership-name 自动填充。这覆盖了约 1,500 个服务背书的仓库，剩下团队仓库、文档仓库、一次性项目和个人仓库。

推出过程

推出通过一个 Kubernetes CronJob 驱动的 GitHub App 实现。强制执行逻辑需要访问 Service Catalog、GitHub API 和几个内部系统，因此简单的 GitHub Actions 工作流不够用。首次运行 CronJob 安排在周六早上，本以为没人会注意——但这是个重大错误。问题出现在全组织仓库中，人们开始在 Slack 上询问这个新 issue 说仓库将被归档。在全球化分布的公司中，总有人在线。

30 天宽限期后，任何仍未设置所有权的仓库都会被归档。选择归档是因为它是可逆且非破坏性的：仓库变为只读，GitHub Actions 停止运行，但不会删除任何内容。如果有人需要恢复，他们可以轻松地取消归档、设置所有权并继续使用。这使得安全地大规模应用归档成为可能，而无需争论每个边缘情况。

初始宽限期过去、批量归档完成后，Team 将强制执行周期从 30 天收紧到 1 小时。任何新建仓库如果绕过创建时所有权要求，几乎会立即被标记。

遇到的问题

推出基本顺利，但有两个小内部事件暴露了有趣边缘情况。

第一起事件：归档一个未设置所有权的仓库时，Datadog 被配置为在该仓库中打开 issue 作为监控工作流的一部分。仓库被归档后 Datadog 无法创建 issue，内部监控服务自动通知了负责团队，团队升级到 Team。这暴露了通知方式上的缺口：所有权 issue 落入了仓库，但没有人直接收到通知。Team 修复了这个问题：在所有权 issue 中 @ 提及仓库管理员，并回退到给所有拥有写权限的用户分配 issue。这样 issue 不会被埋没或忽略，实际能设置所有权的人能立即看到。

第二起事件是数据可靠性问题。虽然 Team 对 Service Catalog 宕机有韧性，但未考虑它可能返回陈旧或损坏的数据。如果坏数据导致 App 认为一批仓库失去了 Service Catalog 条目（而实际上没有），就会批量归档具有有效所有者的仓库。为降低风险，Team 增加了低水位线（low water mark）。在每次运行中，在开始归档之前，App 会检查当前批次中被标记为“失去 Service Catalog 条目”的仓库数量是否超过一个阈值（例如，如果超过 10% 的仓库突然失去所有权，则暂停归档并发出告警）。这提供了一道安全网，防止因数据问题误删大量仓库。

关键要点

• GitHub 内部超过 11,000 个非归档仓库中，绝大多数没有明确所有者，这对安全修复、机密扫描等工作带来了严重风险。
• 原有所有权模型依赖 Service Catalog，但只覆盖与服务关联的仓库，留下大量团队、文档、个人等仓库无法追溯所有者。
• 新模型采用 GitHub custom properties，定义 ownership-type（Service Catalog / Hubber Handle / Team）和 ownership-name，并将所有权作为仓库的一等属性。
• 通过自动同步 Service Catalog 覆盖约 1,500 个服务仓库，剩余的通过 30 天宽限期 + 归档强制执行