The Maintainer of Last Resort

“

"Engineers wanted for thankless work. Low pay, less glory, other people's abandoned code, long nights in unfamiliar codebases, a backlog that never empties, safe handoff doubtful. Honor and a more secure internet in case of success."

An ugly name for an uglier reality. If we lived in a world where end users watched their upstreams and moved off anything abandoned the moment it went quiet, where commercial support sat behind every critical dependency, where open source itself was healthy and well-funded enough never to need rescuing, we wouldn't be here.

But here we are. I think we can fix it, though — or at least get pretty close. In my last post, The hardest fork, I outlined a few of the pieces organizations need to secure how they consume open source, in the short time we have. This is about Plan B: what happens when coordinated disclosure to upstreams doesn't work. The short version is a maintainer of last resort (MOLR) — a neutral backstop that forks a package whose upstream can't fix it in time, patches the live vulnerability, ships a build everyone can verify, and quickly handles all future vulnerability disclosures.

What happens if nobody builds this

Follow the chain of events. Glasswing and the dozens of groups like it keep finding vulnerabilities faster than maintainers can absorb them. A meaningful chunk never gets upstreamed because the maintainer is unreachable, burned out, buried, or the group can't even find contact information.

But the finders are holding working patches, and sitting on a fix to a critical bug isn't an option. So they have to publish them somewhere, someday. A gist, a blog post, a branch on a fork nobody's heard of. And a patch in a gist isn't something an organization can actually use. Almost nobody builds their dependencies from source — they pull built, versioned packages from a registry. Until the patch becomes a published build in a place where their tooling already points, the fix only exists in theory.

Now multiply that by thousands of vulnerabilities and dozens of disclosing groups, and stand on the receiving end. Someone has to assemble all those scattered fixes. Everyone will have to try. The major cloud providers will merge the patches they care about into their own forks. A whole new industry will appear to do the same for the ones the clouds skipped. Three companies ship three patched versions of the same logging library, each with its own fixes, build, and namespace. You're left guessing which fork closed which CVEs, whether any quietly introduced something new, and — the part that actually matters — which one you're supposed to trust.

That last question is not academic. We just watched TeamPCP and Shai-Hulud prove that a trusted distribution channel is the most valuable thing an attacker can capture. A world of competing, semi-official patch forks is a world full of exactly those channels — new namespaces, thin provenance, and a downstream population already conditioned to grab whatever fix it can find. We would be manufacturing the attack surface by hand.

That's the default if nobody builds anything. It's already starting. And it's worse than the disease, not because the vulnerabilities go unpatched, but because the cure fragments into something no one can verify.

The alternative is a maintainer of last resort (MOLR): a GitHub org of forks, a few namespaces on the registries everyone already pulls from, a secure build-and-publish pipeline, and a lot of automation. Nothing exotic. The hard part is running it fast enough to matter and making the output something a stranger can trust.

How I imagine this working

There's a precedent worth borrowing from. The CVE program has a CNA of Last Resort — the org that takes a vulnerability report when no other numbering authority will. A MOLR is that idea extended from cataloging to patching and stewardship: a neutral backstop that steps in only when the normal system has already broken down.

Think of it like the lifeguard at an Olympic swimming final. They'll probably never enter the water, but everyone would immediately understand their value if they weren't there the one time they were needed.

The same principle applies here. The project's maintainers should still fix most vulnerabilities. MOLR exists for the exceptional cases where that process fails. A vulnerability comes in through the central CVD/SIRT function. If the SIRT can find the maintainer and get a patch upstreamed in time, Plan A worked, and the lifeguard stays in the chair. If they can't be reached, or are reachable but can't fix it within the window, MOLR goes in.

A swimmer going under doesn't wait for a committee, and MOLR can't either. The swimmer needs help in seconds, and the industry needs help in hours. MOLR exists to make that kind of intervention possible: a way to step in quickly without asking users to place blind trust in a random third party. The goal isn't just speed. It's speed with legitimacy, transparency, and a clear chain of custody. When intervention is necessary, the project gets forked into a single, canonical, neutral namespace. One sanctioned fork, no ambiguity about which one is real. MOLR either authors a patch or, more often, validates and merges one that already came in with the disclosure. A lot of reports arrive with a fix attached, so the job is to review and merge, not invent. Then MOLR publishes actual builds to the relevant package managers — signed, attested, SBOMs, all the bells and whistles — so security teams have everything they need to verify it independently and switch over right away. And MOLR becomes the disclosure point of contact for that package until the original maintainer comes back.

No one should need to think twice about switching to these forks.

Nothing lasts forever, and these forks can't either. If the maintainer comes back, MOLR can work out a reconciliation process. If they don't, MOLR publishes a stated lifetime for each fork and a firm date when support ends. Sometimes that means handing back to a returned maintainer or a healthy successor; more often, it just means giving downstream enough notice to find another path or rip the dependency out. A backstop only works if everyone leaning on it knows when it ends and can plan accordingly.

I don't know how long MOLR should wait before jumping in. A week? A month? It probably varies on severity. A project with a history of responding probably gets more time than one that no one has ever contacted, with no evidence of recent activity. But we need a framework that doesn't change on every vulnerability to take discretion out of the loop.

Drawing the rest of the owl

This is an outline, not a finished plan. I'm a terrible artist, and the owl isn't drawn yet. But there's enough here to start on. These are the parts I'm most worried about getting wrong.

The most obvious one: what happens when a maintainer comes back. The entire point of MOLR is to return stewardship — we don't want to own anything permanently — but "give it back" is not a one-line policy. There has to be a real handoff process, written down before it's needed: how the maintainer signals they're re-engaging, a review period, what a healthy return actually looks like, and how the MOLR fork gets deprecated or merged back upstream without stranding everyone who switched to it. No one wants to hand the keys back to Jia Tan.

There's also scope, which might be the quietest way this fails. MOLR only works if it stays narrow — patch the live vulnerability, ship it, hand it back. If scope grows too large too fast, the whole thing falls apart: a small team can't backstop an ever-expanding list, and a backstop that falls behind is just one more unreliable upstream. The simplest way to keep it bounded, at least to start, is to limit the work to the latest version of each package. Fix what's current and leave older releases for later. This is almost definitely insufficient. Plenty of projects running across critical infrastructure today run on older versions that are hard to upgrade. But a bit of pressure downstream helps too.

It's worth being precise about the floor under all of this, because MOLR can fail in two very different ways. If it fails by falling behind — too few people, too many packages, forks going stale — no one is worse off than today: it's open source, anyone can fork the work and carry it on, and downstream lands right where it would have without MOLR at all. A MOLR that can't keep up is just a fork gathering dust on a shelf, and the ecosystem has seen a thousand of those. That failure is bounded. A compromise is a different animal: once everyone has consolidated onto one trusted channel, that channel is a skeleton key to everything that trusts it, and breaching it is worse than never having built it. That's why build security sits above everything else here — one failure we can live with, the other we engineer against.

None of these is a reason not to start. Some we won't understand until we run straight into them — that's the rest of the owl, and we'll draw it as we go.

Why this might work, and what it costs

“

"Give me a place to run Claude, and I can patch the world."

The reason a team this small is even thinkable is a leverage shift we've already lived through. We've been doing a version of this with EmeritOSS — stepping in when maintainers step away from mature, stable projects that still have real downstream users. It's not hard to imagine a bit more automation being able to scale up by a few more factors of ten. No room-temperature superconductors needed. MOLR doesn't need to be large to be credible. It needs to be fast and well-instrumented.

Numbers are scary, but we only need a few to show this might work. The work is event-driven: a vulnerability arrives, usually with a patch attached, and the job is to validate, merge, build, sign, attest, publish, and stand in as the disclosure contact. If automation carries the build-and-publish half, the human cost is the judgment — call it a couple of hours a fix. Five engineers is a few thousand hours of fix-work a year, which lands somewhere around one to two thousand fixes if you only ever touch the live version.

But that's only the optimistic end. Some patches need deep domain expertise; some security issues are architectural, with no clean fix. Those are the cases MOLR merges slowly or doesn't touch at all — and being clear about what it won't touch is part of what makes it trustworthy in the first place. They're also exactly what drags the ratio down: if the average fix needs real authoring instead of review, the same five people cover a few hundred, not a few thousand. To be honest, that's a wild-assed guess at either end. We won't know which until we're a few months in with actual throughput to measure. The number is a bet on the leverage, and starting is what settles it.

Is that even enough? In one quarter, Glasswing's open source scanning covered around a thousand projects and surfaced close to 3,900 real high- or critical-severity vulnerabilities — with the shipped patches still counted in the dozens, because finding the bugs was never the bottleneck. Some maintainers have asked the scanners to slow down. MOLR's slice is only the Plan-B cases, but across dozens of scanning groups and a growing backlog, one to two thousand is enough to start and to matter — and nowhere near enough to catch everything. This is the case for narrow scope, not against it.

That ratio is the fork in the road on cost. At five people, MOLR is a two-to-four-million-dollar-a-year operation, and there's a worn path for that: a lean, neutral nonprofit funded by the companies that depend on it, the way ISRG runs Let's Encrypt. At fifty, it's north of twenty million a year — Signal territory, a forever cost that grows with use, where no single backer is safe to lean on, and you need a government or an industry consortium behind it. Unfortunately, we won't know what this looks like until someone tries. So we're going to try.

We're going to stand up a MOLR and run it as a real service: take disclosures, patch abandoned packages, publish builds, and measure what it actually costs to keep critical open source software alive. The examples that lasted all share a shape: incubated somewhere fast-moving, then spun out to neutral stewardship before they turn load-bearing. What that buys is a measured answer to the one open question: the real ratio of people to packages. We'll run it on our own build-and-attestation infrastructure, with our own people on keyboards, because that's the fastest way to get there.

What we won't do is own it forever — a backstop the whole ecosystem leans on shouldn't live inside one for-profit company, ours included. If it works, we move it to a neutral home and help fund it from outside; if it doesn't, we publish what we learned so the next group starts further along.

So what's next?

We're going to start, because the backlog of undisclosed vulnerabilities is growing by the minute, and someone has to. Plus, it's open source. You can just try things.

We'll work in the open — published policies, published patches, published review records, published decision logs for the hard calls. We'll be explicit about what we won't touch.

I really hope we can pull this off together, because I think this could be a much bigger long-term win than a one-time band-aid. The second-order benefits could matter more than the patches themselves. The CVD/SIRT process finally gets a known answer for its hardest case — the disclosure for a project nobody can reach. Organizations can lean on open source without bracing to be stranded at the exact moment it matters. And maintainers get something they've never really had: a safe place to set their code down when they're done. One of the conditions that helped enable xz-utils was a burned-out solo maintainer with no good handoff option — MOLR is that option.