GitHub Fixes Repo Ownership

GitHub has tackled a significant internal challenge: defining clear ownership for its massive codebase. The company recently announced it had assigned a durable owner to every active repository within its primary internal organization, a move that streamlines security and operational workflows.

Previously, out of over 11,000 non-archived repositories, fewer than half had a clearly designated owner. This ambiguity complicated critical tasks like secret scanning remediation, where identifying the responsible party was often a manual, time-consuming process.

The Ownership Gap

GitHub's existing Service Catalog system provided robust ownership data for repositories tied to production services. However, this system was a many-to-one mapping, meaning it could trace a service to a repository but not reliably reverse that for repositories without a direct service link.

This left a significant gap, encompassing team repositories, documentation, internal tools, and experimental projects. Finding the owner for these "unowned" repositories often involved digging through commit history, README files, or relying on Slack inquiries.

Designing for Durability

To rectify this, GitHub opted for custom properties within its platform. This approach allowed for a native, structured, and organization-wide method to manage ownership, enabling policy enforcement and rule sets.

Two custom properties were introduced: ownership-type and ownership-name. The former accepted values like "Service Catalog," "Hubber Handle" (for individual GitHub employees), or "Team." The latter captured the specific name, with validation ensuring the existence of Hubber handles, teams (requiring at least two members), and Service Catalog entries.

Implementation and Rollout

A periodic sync from the Service Catalog automatically populated ownership for the ~1,500 service-backed repositories. The remaining repositories required manual ownership assignment, with a 30-day grace period.

A dedicated GitHub App, powered by a Kubernetes CronJob, managed the enforcement logic. This system scanned repositories, created issues for those lacking ownership, and ultimately archived those that remained unassigned after the grace period.

The initial rollout, mistakenly scheduled for a Saturday morning, quickly highlighted the need for this change as developers immediately engaged with the new issues appearing in their repositories.

Archiving was chosen as a reversible, non-destructive action, ensuring that no data was lost and repositories could be easily restored if needed. This initiative fundamentally changed how GitHub manages its internal codebase, making GitHub repository ownership a foundational element for all subsequent operations.