IBM and Red Hat aren’t the only ones that mean to lock down open-source code against AI hacking tools.
Last week, IBM and Red Hat launched Project Lightwell to protect open-source projects with $5 billion and 20 thousand engineers. Not to be outdone, with tongue in cheek, Chainguard’s CEO Dan Lorenc announced a $50 million, 100‑engineer commitment as an attempt to “build new trust infrastructure for open source consumption.” Why? Because Lorenc argues that open source consumption “is fundamentally broken, and no amount of incremental improvement is going to fix it in time.” I wish I could disagree, but he’s right.
In his blog post, The Hardest Fork, Lorenc warns “Mythos is real,” pushing back on those who dismiss Anthropic’s scary code scanner as hype or a “marketing stunt.” He describes the Mythos findings as “novel combinations of a few dozen issues out of thousands of things every SAST [Static Application Security Testing] scanner already finds, chained together into something much worse.” In short, Mythos is “not a better scanner” but “a different category of threat.”
This means modern AI is ruining coordinated vulnerability disclosure into an at‑scale problem: “A model can now find hundreds overnight in the long tail. The existing system is not going to keep up, and we all need a backup plan for the vulnerabilities that don’t get patched.”
Lorenc argues that the basic way enterprises use open source is unsustainable under AI pressure. He wrote, “The way the world consumes open-source software is fundamentally broken, and no amount of incremental improvement is going to fix it in time.” Open source is “going to have to change.”
After all, he points out that “modern apps are layers of dependencies,” where changing one component can cascade through an entire stack, especially in large organizations with legacy codebases. On the maintainer side, he notes that “some of the most critical software on the internet is maintained by one or two people in their spare time,” and that “automated scanners and AI-generated reports have already been burying them in low-quality noise for years.”
What to do?
Plan A: coordinated disclosure that actually scales
In the near term, Lorenc says the ecosystem needs both “a Plan A and a Plan B.” Plan A is “coordinated disclosure that actually works at scale,” which he defines as “a single, trusted group that routes fully vetted reports and patches upstream, and supports the maintainers who want help.”
That’s all well and good, but who will that be? IBM and Red Hat have certainly thrown their hat into the ring, but do you trust them?
Lorenc is certainly right when he states this can’t be left to “a dozen competing groups filing noisy tickets” and instead needs “one coordinated effort that maintainers recognize and trust, so their reports get bubbled to the top of every inbox.” He cites Project Glasswing’s current performance as a warning sign, writing that “Glasswing has managed to get about 6% of its findings upstreamed” and estimating that “we can get normal coordinated disclosure working, under hard time crunches, for maybe 50% of projects at best.”
Plan B: a “maintainer of last resort.”
For everything that Plan A can’t reach, Lorenc says the ecosystem needs a fallback: “For all of those, and for the projects where maintainers can’t or won’t patch at all, we need a maintainer of last resort.” He anchors this in the traditional FOSS right to fork: “Open source gives you the right to fork. To take a project, assume stewardship, and keep it alive independently.”
What’s different, he argues, is scale: “We’re not talking about forking one project. We’re talking about building the infrastructure to fork, maintain, and distribute thousands of them. Under time pressure, with real adversaries on the other side. That’s the hardest fork any of us has ever had to make.”
That is the role he positions Chainguard as helping to fill, leveraging AI to make this kind of “maintainer of last resort” function viable. In a comment, Lorenc adds, “We’re not going to be the maintainer of last resort, we’re just going to help with it.”
Three futures for open source
Looking further ahead, Lorenc lays out three possible futures he calls “forks in the road”: “The naive one,” “The chaotic one,” and “The hard fork.”
In the naive scenario, he writes, “you do nothing and hope,” and imagines a world where “Glasswing patches everything upstream” and “every maintainer responds to every disclosure within 24 hours” — a world he says plainly, “We do not live in.”
Indeed, we already live in that one, and you may have noticed that not a day goes by that there’s not another new open-source supply chain incident. Just ask Red Hat with its spectacular npm breach. Yes, there is more than a little irony here.
In “the chaotic one,” he warns that “every major cloud provider forks its own versions of critical libraries, each with its own patch sets,” while “three different security vendors ship competing forks of the same logging framework.” That, he says, is “the default if we do nothing.”
I really, really hope that won’t be the case, but I find it all too easy to see it happening. It’s everything that’s wrong about proprietary code with an open-source wrapper.
The third path is “the hard fork: a deliberate, coordinated, painful decision to build new trust infrastructure for open-source consumption, including “one disclosure pipeline that works at scale” and “one trusted place for maintained forks.”
Lorenc closes his essay with a mix of realism and dark humor: “Is any of this actually going to work? I honestly have no idea. But we have to start, and as the Programmer’s Credo says, ‘We do this not because it is easy, but because we thought it would be easy when we started.’ This one doesn’t even feel easy at the start.”
No, no, it doesn’t.