GitHub is, famously, the largest code host on earth. What is less often discussed is that the company that runs it had a quiet internal problem: a sprawl of repositories no one could clearly account for. In a post published this month on the GitHub Engineering blog, GitHub Staff Security Engineer Michael Recachinas described the cleanup in unusually concrete terms — and the numbers make the case for durable ownership anything but abstract. The company had over 14,000 repositories. Fewer than half had clear ownership. The rest were drift — projects whose responsible human was unknown, departed, or simply never recorded.
The fix was not a clever algorithm. It was a durable-ownership program that gave every active repository a validated human owner in under 45 days, archived the rest, and then made ownership the foundation for everything that followed: secret scanning, vulnerability routing, and access review all key off the owner field. The lesson is less about GitHub’s internal hygiene and more about a principle every engineering organization eventually rediscovers — you cannot secure, maintain, or retire what you cannot attribute.
Why ownership is the hidden prerequisite
Most security and reliability tooling assumes someone is listening on the other end. A vulnerability scanner that files a ticket into the void accomplishes nothing. A secret-scanning alert that lands in an unattended inbox is just noise. GitHub’s own numbers make the trap vivid: it reported 20,000+ secret scanning alerts across 15,000 repositories, and reaching “inbox zero” took nine months of work that depended on first knowing who should act.
Ownership is what converts a signal into an action. Without it, even the best automation produces orphaned alerts. With it, the same tools become accountable workflows — the alert knows where to go, who is on call, and what “done” looks like. Recachinas frames ownership as “the foundation for everything that followed,” and that ordering matters: GitHub did not try to bolt smarter automation onto an unmapped estate. It mapped the estate first.
How the 45-day turnaround actually worked
The program had three moves, and the first was the hardest: decide what “active” even means. GitHub did not attempt to assign owners to everything. It separated living repositories from abandoned ones, then routed each down a different path.
Active repositories got a validated owner — not a team name or a mailing list, but a specific accountable person whose responsibility was confirmed rather than assumed. Repositories that failed the activity test were archived, pulling them out of the operational surface area so they no longer counted against the security backlog or consumed maintenance attention. The combination is what made the timeline possible: by not pretending to own 14,000 repos uniformly, the team could give real ownership to the subset that mattered and stop pretending about the rest.
The “validated” part is the detail worth copying. Inheritance from a parent team or a CODEOWNERS file is brittle — teams rename, reorg, and the file goes stale. A validated owner is one a human signed off on during the window, which is why the count could be trusted afterward. Durable ownership is a verb, not a field you fill once.
What changed once ownership was real
With a reliable owner attached to every active repo, the downstream automations stopped guessing. Vulnerability management could route a CVE to a named person instead of a distribution list. Secret scanning could escalate to a real owner rather than rotting in a shared folder. Access reviews had a default approver.
This is the part of the story that scales beyond GitHub. The durable-owner pattern is reusable anywhere code lives: internal platforms, open-source program offices, university labs, startup monorepos. The mechanics differ, but the shape is identical — enumerate, classify active vs abandoned, assign validated human owners to the active set, archive the rest, and make every subsequent tool depend on that field. GitHub’s nine-month secret-scanning cleanup was possible precisely because the ownership map existed to aim it.
The open-source angle
For the open-source ecosystem the principle is just as sharp, and the tooling is already here. GitHub’s CODEOWNERS feature lets a repository declare who reviews what, and the “durable owner” mindset suggests treating that file as a living contract rather than a setup step. Projects that rename a maintaining team or graduate a busy maintainer owe themselves a five-minute ownership review, the same way they’d rotate a deploy key.
The harder open-source case is the abandoned dependency — the package everyone depends on and no one maintains. GitHub’s internal “archive the rest” move has a public echo in archived repositories and the broader conversation about critical open-source plumbing. You cannot give a dead project a human owner, but you can stop treating it as if it has one, and either fork it, pin it, or fund it deliberately.
The takeaway for your own repositories
If GitHub — with a security engineering staff and its own platform — found itself with most repositories unowned, the odds are good that your org has the same gap and just hasn’t measured it. The remediation is unglamorous and fast: list every repository, mark the ones that are actually active, assign a validated human owner to each, and archive or transfer the ones that aren’t. Forty-five days is not a fantasy timeline; it is what happens when you stop trying to own everything and start owning the right things on purpose.
GitHub’s story is ultimately a mandate loop. Ownership enables automation, automation surfaces risk, and risk routes to the owner who can close it. Break the first link and the whole chain is theater. Fix it, and the tools you already have start doing the job they promised.
