GitHub为仓库指定可靠所有者GitHub拥有超过14,000个仓库但其中只有不到一半有明确的所有者。在不到45天的时间内GitHub为每个活跃仓库指定了经过验证的所有者将其余仓库存档并使所有权成为后续工作的基础。原有所有权模型的困境GitHub在主要的内部GitHub组织中拥有超14,000个仓库。截至2025年初超11,000个非存档仓库中绝大多数无明确所有者。对于与生产服务相关的仓库历来有可靠的持久所有权但对于无关联服务的仓库却无可靠方法确定所有者。在密钥扫描修复工作中此问题反复出现不知道仓库所有者时轮换密钥风险大、干扰多且无明确方法分配修复工作。多年来GitHub通过内部服务目录跟踪已部署服务的所有权服务条目记录元数据可建立从服务到仓库的映射还记录所属团队、执行发起人及支持信息。但这种关系是多对一的从服务入手可找仓库及其所有者从仓库出发找所有者需反向查找且仅适用于映射到服务目录中服务的仓库留下巨大所有权缺口包括团队仓库、文档仓库等。每次联系“无主”仓库所有者都需手动操作对于重复性安全工作流程带来真正风险在密钥扫描清理工作中寻找合适所有者花费大量时间。设计新所有权模型GitHub需要将仓库所有权作为首要属性考虑过将所有权存储在每个仓库内的专用文件中或维护在一个集中的仓库中最终选择了GitHub自定义属性这种方法提供原生、结构化且可在整个组织范围内查询的方式管理所有权还能根据所有权类型有选择地执行企业和组织政策及规则集。GitHub创建了两个自定义属性“ownership - type”和“ownership - name”。“ownership - type”接受“Service Catalog”“Hubber Handle”“Team”三个值涵盖了GitHub仓库所有权的实际范围“ownership - name”是经过轻度验证的文本字段GitHub应用程序会验证每个值在格式方面有意放宽要求希望让添加所有权轻松无压力并依靠强大的验证捕捉无效条目。首日覆盖情况在要求任何人采取行动之前GitHub建立了一个从服务目录到仓库自定义属性的定期同步机制。每个支持已知服务的仓库都会将其“ownership - type”设置为“Service Catalog”并自动填充“ownership - name”处理了约1,500个由服务支持的仓库剩下团队仓库、文档仓库、一次性项目和个人仓库。推广过程为推广新模型GitHub构建了一个由Kubernetes CronJob支持的GitHub应用程序因执行逻辑需访问服务目录、GitHub API和一些内部系统简单的GitHub Actions工作流不够。仓库所有权执行流程从最初的所有权扫描到创建警告问题再到自动关闭或在30天后进行存档。GitHub将CronJob的首次运行安排在周六早上但问题开始出现在整个组织的仓库中人们在Slack上询问仓库中说要被存档的新问题。经过30天宽限期后将仍未设置所有权的仓库进行存档存档可逆且非破坏性若有人再次需要可取消存档、设置所有权并继续使用。初始宽限期过后将执行周期从30天缩短到一小时新仓库若绕过创建时所有权要求会立即被标记。遇到的问题及解决办法此过程总体顺利但有两起轻微内部事件暴露出有趣的边缘情况。第一起事件因存档未设置所有权的仓库Datadog被配置为在该仓库中创建问题仓库被存档后无法创建问题内部监控服务注意到并向所属团队发送警报问题升级。这暴露出通知方式漏洞通过在所有权问题上提及仓库管理员并将所有具有写入权限的用户作为后备分配解决问题。第二起事件是数据可靠性问题未考虑服务目录可能返回过时或损坏的数据若错误数据导致应用程序认为一批仓库失去服务目录条目会大规模存档拥有有效所有者的仓库。为降低存档合法仓库的风险设置了下限每次运行前应用程序统计即将进行的存档数量和即将创建的问题数量若超过保守阈值将停止操作并触发Datadog监控若无法访问服务目录作业将跳过服务目录验证只检查能独立验证的内容。数据结果最终GitHub有大约3,000个活跃仓库和11,000个存档仓库最初存档约3,000个。从第一次运行到稳定状态整个过程不到45天。现在每个活跃仓库都有经过验证的所有者否则就会被存档。许多新存档的仓库多年未提交代码存档减少了管理范围使活跃仓库清单更符合实际情况。确保所有权持续有效实现100%的覆盖只有在能够保持的情况下才有意义因此GitHub在每个仓库创建工作流程中都强制执行所有权属性包括仓库创建页面、内部工具和自动化流程使这些属性对所有新仓库都是必需的。同时收紧了执行周期失去所有权的仓库会在一小时内被标记出来。每种所有权类型都有其自身的持久性特点服务目录条目遵循服务生命周期服务被弃用时其仓库通常也会被存档团队会被验证是否至少有两名成员团队的存在和成员资格往往相当稳定个人Hubber用户名只有在有人离开公司时才会失效此时个人仓库通常应被存档。对于重要到能超越个人的仓库所有权应该是团队或服务而不是个人。对您的启示您现在可以使用GitHub自定义属性实现类似的所有权模型推荐方法如下定义您的所有权分类确定适合组织的所有者类型在组织级别创建自定义属性设置“ownership - type”属性作为单选框包含允许的值以及“ownership - name”属性作为文本字段如果有服务目录或资产清单进行同步为已跟踪的仓库填充所有权在仓库创建时强制执行所有权使这些属性成为必需为现有仓库构建宽限期工作流程创建带有合理截止日期的问题然后存档无人认领的仓库不要在周六进行第一次强制执行在大规模信任自动化之前构建防护措施假设数据源偶尔会出错通知有时会丢失从一开始就为此进行设计。