In the modern software development ecosystem, managing repositories can become a monumental challenge when a clear ownership system is lacking. GitHub, one of the world's most widely used platforms, faced a critical situation: over 14,000 repositories in its internal organization, of which 11,000 were active and a large portion had no defined owner. This problem, far from being a mere administrative detail, became a recurring obstacle for tasks such as secret rotation, incident response, and vulnerability management. The story of how they solved this problem offers valuable lessons for any company handling a significant volume of code.
The underlying issue was structural. Although a Service Catalog existed associating repositories with responsible teams, that relationship was one-way: a service could have multiple repositories, but it was not easy to discover who owned a repository not linked to a production service. This left out documentation repos, internal tools, personal experiments, and hackathon projects. Every time someone needed to contact the owner, manual methods were required: checking commit history, reading the README, asking on Slack, or simply guessing. For one-off tasks it was annoying, but for security processes that fan out across the entire organization it posed a real risk. At Q2BSTUDIO, as a company specializing in custom software development, we know that ownership traceability is a fundamental pillar for ensuring software quality and security.
The solution involved making repository ownership a first-class property using GitHub's custom properties. Two properties were defined: ownership-type and ownership-name. The accepted types were 'Service Catalog', 'Hubber Handle' (individual employee), and 'Team'. Each value was automatically validated by a GitHub App: handles had to belong to active organization members, teams had to have at least two members, and Service Catalog entries had to correspond to active services. They opted for lenient formatting to reduce friction; for example, '@my-team' was accepted as valid input, but validation later rejected nonexistent teams or former employees. This initial flexibility accelerated adoption while maintaining data integrity.
The rollout began with an automatic sync from the Service Catalog, which covered about 1,500 service-backed repositories. The remaining repositories —teams, documentation, personal projects— had to fill in the information manually. For this, an application with a Kubernetes CronJob opened reminder issues in each repository lacking an owner, giving a 30-day grace period. The first run was scheduled for a Saturday morning, thinking nobody would notice. Big mistake: in a global company someone is always online, and issues started appearing with questions on Slack. After the grace period, repositories without an owner were archived. Archiving is reversible and non-destructive: the repository becomes read-only and Actions stop, but nothing is deleted. This allowed mass archiving without debating edge cases. Ultimately, about 8,000 repositories were archived, reducing the active count to about 3,000, all with a validated owner.
However, not everything was perfect. Two minor incidents forced adjustments. The first occurred when an archived repository prevented Datadog from creating automatic issues, triggering an unexpected alert. The lesson was that ownership issues were not directly notifying repository administrators. The fix was to @-mention administrators and automatically assign all users with write access, ensuring notifications could not be overlooked. The second incident involved data reliability: if the Service Catalog returned corrupt or outdated data, the application could archive legitimate repositories. To prevent this, a 'low water mark' was implemented: before archiving, the system counted how many repositories it was about to touch; if that count exceeded a conservative threshold, it aborted and triggered a Datadog alert. This guardrail approach is something we at Q2BSTUDIO constantly apply in our cloud AWS and Azure projects, where automation must be robust against imperfect data sources.
The numbers speak for themselves: in 45 days, archived repositories went from about 3,000 to over 11,000, while active ones dropped to 3,000, all with known owners. Many of those archived repositories had seen no commits in years: abandoned hackathon projects, personal experiments, and even prototypes from 2008. Archiving not only reduced the attack surface but also made the inventory reflect operational reality. To maintain 100% coverage, ownership was made mandatory in all repository creation flows, and the grace period for new repositories that lost ownership was tightened to just one hour.
Ownership durability depends on the type. Services follow their lifecycle: when a service is decommissioned, its repositories are typically archived. Teams are stable as long as they have at least one member. Individual handles become invalid when someone leaves the company, at which point their personal repositories should also be archived. For critical repositories that must outlast a person, ownership should be a team or service, never an individual. This philosophy applies to any organization wanting to strengthen its security posture. In a context where cybersecurity and artificial intelligence are transforming development, having solid ownership control is essential. For instance, deploying AI agents to automate vulnerability detection in repositories requires knowing whom to notify. Similarly, a BI/Power BI dashboard monitoring repository health is only useful if ownership data is reliable.
For companies wanting to replicate this model, GitHub offers custom properties as a native tool. The recommended process includes defining an ownership taxonomy (service, team, individual), creating the properties at the organization level, syncing from a service catalog if one exists, making ownership mandatory at creation, and establishing a grace flow with archiving as the final action. The lessons learned are clear: don't run the first sweep on a Saturday, design guardrails for automation, and notify responsible parties directly. The end result is an orderly, secure repository ecosystem with clear owners, allowing teams to focus on what really matters: building quality software. At Q2BSTUDIO, we help companies implement these practices by combining custom software development, cloud, AI, cybersecurity, and BI, ensuring that code ownership is not another headache.
