How GitHub Ensured Every Repository Has a Validated Owner in Just 45 Days

GitHub recently pulled off a massive organizational feat: ensuring every active repository across its primary internal organization had a validated owner. With over 14,000 repositories and fewer than half having clear ownership, this was no small task. But in under 45 days, they transformed repository management, archived inactive repositories, and made ownership a foundational pillar for security and operational workflows. Here’s how they did it and what you can learn from their approach.

The Problem: Thousands of Repositories, No Clear Owners

GitHub’s internal organization had over 11,000 non-archived repositories, most of which lacked clear ownership. While repositories attached to production services had robust ownership tracking through the Service Catalog, others—like team repositories, documentation repos, and personal experiments—were effectively 'unowned.' This created significant challenges, especially during security efforts like secret scanning remediation, where identifying repository owners was crucial to rotating secrets safely.

Without clear ownership, teams had to manually track down owners through commit histories, README files, or Slack messages. This ad-hoc process was time-consuming and risky, especially for recurring security workflows. GitHub needed a solution that made repository ownership a first-class property and eliminated ambiguity.

The Solution: A New Ownership Model

GitHub’s solution revolved around GitHub custom properties, which allowed them to enforce and manage ownership at scale. They introduced two key properties:

1. ownership-type: This could be one of three values:

   • Service Catalog: Repositories tied to a deployed service.
   • Hubber Handle: Repositories owned by individual GitHub employees.
   • Team: Repositories owned by a team, such as shared documentation or internal tools.

2. ownership-name: A text field with light validation to ensure the entered values (e.g., team names or employee handles) were accurate.

This approach provided a structured, queryable way to manage ownership across the organization. It also enabled GitHub to enforce enterprise policies and rulesets based on ownership type.

Rolling Out the Change

The rollout involved several key steps:

1. Day-One Coverage: GitHub built a periodic sync from the Service Catalog to repository custom properties, automatically setting ownership for repositories backed by known services. This covered about 1,500 repositories initially.

2. Enforcement Workflow: A GitHub App backed by a Kubernetes CronJob was used to scan repositories, create warning issues, and archive repositories without validated ownership after a 30-day grace period.

3. Automated Archival: Repositories without ownership were archived, making them read-only and stopping GitHub Actions. This process was reversible, allowing repositories to be unarchived if needed.

4. Tightened Enforcement: After the initial rollout, GitHub reduced the enforcement loop from 30 days to one hour, ensuring new repositories without ownership were flagged almost immediately.

Overcoming Challenges

The rollout wasn’t entirely smooth. Two incidents highlighted the need for better notification and data reliability:

• Notification Gaps: Initially, ownership issues were landing in repositories, but no one was directly notified. GitHub fixed this by @-mentioning repository administrators and assigning issues to users with write access.
• Data Reliability: The app had to handle potential data corruption from the Service Catalog. GitHub introduced a low water mark to prevent mass archiving based on bad data and added fallbacks to skip Service Catalog validation if it was unreachable.

Results: By the Numbers

• Active Repositories: ~3,000
• Archived Repositories: ~11,000 (up from ~3,000 at the start)
• Total Time: Under 45 days

Many of the archived repositories were abandoned experiments or one-off projects, some dating back to 2008. Archiving these repositories reduced GitHub’s surface area and ensured the active repository inventory reflected reality.

Making Ownership Stick

To maintain 100% coverage, GitHub enforced ownership properties across all repository creation workflows. They also tightened the enforcement loop, ensuring repositories that lost ownership were flagged within an hour. Each ownership type was designed with durability in mind, accounting for service lifecycles, team stability, and employee turnover.

What This Means for You

If you’re managing repositories at scale, GitHub’s approach offers valuable lessons:

1. Define Your Ownership Taxonomy: Decide which types of owners make sense for your organization.
2. Use Custom Properties: Set up ownership-type and ownership-name properties at the organization level.
3. Sync Existing Data: Populate ownership for repositories you already track.
4. Enforce Ownership at Creation: Make ownership properties required for new repositories.
5. Build a Grace-Period Workflow: Open issues with a deadline for existing repositories and archive unclaimed ones.
6. Prepare for Incidents: Build guardrails to handle data inconsistencies and notification gaps.

And remember, don’t run your first enforcement pass on a Saturday—someone is always online!

Final Thoughts

GitHub’s effort to validate ownership for every repository is a masterclass in organizational efficiency and security. By making ownership a first-class property, they’ve ensured accountability, streamlined workflows, and reduced risk. Whether you’re managing a small team or a massive organization, these principles can help you take control of your repositories and build a more secure, efficient development environment.