GitHub’s security team faced a problem that will feel familiar to anyone who has inherited a sprawling internal codebase: by early 2025 the company’s primary internal GitHub organization held more than 14,000 repositories, over 11,000 of them unarchived, and the large majority had no identifiable owner. Production services were tracked cleanly through an internal Service Catalog, but for the long tail of team repos, documentation, internal tools, and one-off experiments, nobody could reliably answer a single question — who owns this?
That blind spot stopped being academic during GitHub’s secret-scanning remediation push. The team could rotate a leaked credential technically, but rotating it without knowing who owned the repo was risky and disruptive, and there was no clean way to route the work. So in a little over a month and a half, GitHub validated an owner for every active repository, archived roughly 8,000 that were no longer in use, and changed repository creation so that ownership became a required field from the very first commit. The write-up, published by Staff Security Engineer Michael Recachinas, is a rare public look at how one of the world’s largest code hosts organizes its own house.
The original model wasn’t broken so much as lopsided. For years GitHub had tied ownership to deployed services through the Service Catalog, where each entry recorded the repository, the owning team, an executive sponsor, and support details. That enabled service-centric workflows — incident response, on-call routing, vulnerability management, compliance scoping. The catch was structural: the relationship was many-to-one. A service mapped to a single repository, so starting from a service you could find the repo and its owners. But starting from a repository with no associated service, you had to reverse the lookup, and it only worked for repos that happened to map to a service at all. Team repos, docs repos, and internal tools fell straight through the gap.
The fix was a dedicated Repo Ownership app that made ownership a first-class, queryable property of every repository rather than a side effect of service mapping. Each entry carries the owning team, the repository, a kind, a long name, a description, a maintainer, and an executive sponsor — the same rich metadata the Service Catalog used, but inverted so the repository is the anchor. Because ownership is now durable and validated, the reverse lookup that used to fail simply doesn’t happen anymore: ask any repo who owns it and you get a routed answer.
Day-one coverage was the hard part. GitHub didn’t grandfather the backlog; it worked through it. Over the course of roughly six weeks the team validated ownership for every active repository and archived about 8,000 that were no longer in use. Archiving mattered as much as assigning, because a dead repo with a stale owner is still a liability — it shows up in vulnerability scans, complicates compliance scope, and gives future automations a false positive to chase. Clearing it from the active set made the ownership graph trustworthy.
Just as important was closing the front door. Repository creation was changed so that an owner is required at creation time. New repos can no longer enter the organization ownerless, which means the validated graph stays validated instead of decaying the moment the next project spins up. That is the part most internal cleanup efforts miss: they sweep the pile but leave the faucet running.
The payoff shows up in the workflows that ownership unlocks. Recachinas notes that secret-scanning remediation — the original pain point — now has a clear route. When a credential leaks, the system knows who to page and who is accountable for the fix, instead of a security engineer guessing from git blame. Vulnerability management, compliance scoping, and incident response all benefit from the same durable mapping. Ownership becomes the foundation that other security automation builds on, rather than the missing prerequisite that blocks it.
There were sharp edges. Requiring ownership at creation met the usual friction: teams that move fast push a repo first and figure out process later, and a mandatory field can feel like a speed bump. The rollout leaned on existing signals — service mappings, CODEOWNERS files, org membership — to pre-fill suggestions so the required field was usually already answered. Making the secure choice the easy choice, in Recachinas’s framing, is the whole point of developer-first security automation.
The result GitHub reports is a complete, validated ownership map across its primary organization, with the dead weight archived and new repos born with an owner attached. For teams running their own internal GitHub or GitLab instances, the lesson is less “copy the app” and more “treat ownership as data, not folklore.” A repository without a known owner is a small debt that compounds: it silently fails every future automation that assumes someone is responsible for it. GitHub’s approach was to make ownership mandatory, validated, and durable — and then to actually do the boring work of assigning the 11,000 it already had.
For open-source maintainers the piece is a useful mirror. Public projects rarely have GitHub’s internal tooling, but the same principle applies at a human scale: a repo with no clear maintainer, no CODEOWNERS file, and no security policy is harder to trust and harder to contribute to. GitHub ships six free settings — branch protection, secret scanning, Dependabot alerts, and a security policy among them — that close the easy doors for any project, regardless of size. The durable-owner project is the internal version of that same instinct applied at platform scale.
The full account, including the rollout timeline and the repo-ownership entry schema, is on the GitHub Engineering blog. For teams wanting to apply the same discipline externally, GitHub’s documentation on CODEOWNERS remains the lightweight on-ramp: a single file that, unlike an internal Service Catalog, travels with the repository and makes ownership visible to everyone, not just security engineers.
Image: GitHub’s invertocat logo, via github.blog (GitHub)
