GitHub's internal GitHub organization held over 14,000 repositories as of early 2025, with more than 11,000 active and most having no clear owner. That gap was not academic: during a secret scanning remediation effort, engineers could not safely rotate credentials without knowing who owned the affected repository, and had no reliable way to route the work.
The fix required two properties and a significant cleanup operation. GitHub added two custom properties to every repository, ownership-type and ownership-name, validated by a GitHub App backed by a Kubernetes CronJob. The App checked Hubber handles against org membership, required teams to have at least two members, and verified Service Catalog entries directly. A periodic sync pre-populated about 1,500 service-backed repositories automatically. The remaining repositories required active outreach. Over six weeks, the team validated ownership across every active repository and archived roughly 8,000 that were no longer in use. Repository creation now requires ownership from the start.
The article is worth reading in full for the implementation detail: specifically how GitHub handled the many-to-one problem in its original Service Catalog model, why GitHub Custom Properties won over flat files or a centralized ownership repo, and how the enforcement rollout was sequenced to avoid disrupting teams while still closing the gap. The validation logic and the decision to be permissive on formatting while strict on existence checks is the kind of tradeoff reasoning that applies well beyond this specific problem.
[READ ORIGINAL →]