"Mythos is real," Dan Lorenc writes — and he says the findings are "bad."
Mythos: a new category of threat
Dan Lorenc, CEO and co‑founder of Chainguard, argues that what the community calls "Mythos" is not a clever marketing stunt but a genuine shift: chains of dozens of low‑level issues, combined by AI, can create attacks far beyond the usual single‑bug remote code execution headlines. These are not isolated scanner false positives; Lorenc likens the creativity to "Move 37" and calls it "a different category of threat." He warns that even if one model were a hoax, the capability is coming regardless.
Why Washington, Europe, and open source consumption clash
Lorenc describes a structural policy problem. He says Washington has been tracking the threat, but regulating a phenomenon many in industry deny is real is difficult. He points to Europe’s attempt with the CRA as evidence that open source is hard to govern: "open source isn't governable," he writes, because laws and orders cannot reach people worldwide who put code on the internet for free. As a result, the US is focusing where it can — on consumption — and Lorenc endorses that instinct.
Plan A: coordinated disclosure that scales
Lorenc sets out a two‑part response. Plan A is an upgraded coordinated disclosure system: a single, trusted group that routes fully vetted reports and patches upstream and supports maintainers who want help. He is explicit about the scale problem — Glasswing has managed to get about 6% of its findings upstreamed — and that the best realistic outcome is far short of complete coverage. His "best guess" is that normal coordinated disclosure could be made to work, under duress, for maybe 50% of projects at best, but it will take a lot of work.
Plan B: a maintainer of last resort and the hard fork
For the remainder, Lorenc argues we need a Plan B: a maintainer of last resort. Open source permits forking, and for projects where maintainers cannot or will not patch, somebody must take stewardship. He contends that piling dozens or hundreds of vulnerability reports into the long tail requires centralization: "we need to centralize in one place to maintain those forks that end users can trust." The function must be sustainably funded, staffed, neutral, and trusted — and, crucially, AI makes that scale possible now where a year ago it would not have been.
The naive, chaotic, and hard‑fork outcomes
Lorenc lays out three concrete paths forward. The naive path is effectively hope: every maintainer responds instantly, every vendor sandboxes perfectly, and every team updates without introducing regressions — a world he says we do not live in. The chaotic outcome is fragmentation: "Every major cloud provider forks its own versions," multiple security vendors ship competing forks, and teams are left to untangle which forks fix which CVEs. The hard fork is deliberate centralization: build new trust infrastructure, operate one disclosure pipeline, and run one trusted place for maintained forks. Lorenc calls this the most difficult option, but "the only real one."
What this means for open‑source maintainers, Washington, and enterprises
- Open‑source maintainers: Many critical projects are run by "one or two people in their spare time," Lorenc notes. Maintainership already faces being overwhelmed by low‑quality noise from automated scanners and AI reports; a trusted support pipeline and the possibility of a recognized maintainer of last resort could relieve that burden for maintainers who want help.
- Washington and regulators: Because laws struggle to reach global, voluntary contributors, Lorenc describes a realistic policy focus on consumption rather than production. He warns regulators they must balance the risk of over‑regulation — pushing capability to other countries — against the risk of under‑regulation, which could let a US‑based entity inadvertently create a weapon that threatens critical infrastructure.
- Enterprises and security teams: Modern applications are deep dependency stacks; Lorenc stresses that hurried patches can install malware worse than the original vulnerability. Teams will have to plan for partial coverage — even with improved disclosure, many projects will remain unpatched — and for decisions about which forks and maintained packages they can trust.
Lorenc traces his credibility on the topic to long involvement in the open‑source security ecosystem: he says he helped found the OpenSSF and Alpha‑Omega while at Google, created Sigstore and Scorecards and "the first open source malware scanners," funded grants that put Rust in the Linux kernel and MFA on PyPI, and then started Chainguard. That experience underpins his central claim: "the way the world consumes open source software is fundamentally broken, and no amount of incremental improvement is going to fix it in time."
He closes without certainty. "Is any of this actually going to work? I honestly have no idea. But we have to start," he writes, echoing the Programmer's Credo: "We do this not because it is easy, but because we thought it would be easy when we started." Whether the community chooses the hard fork — and whether a trusted, neutral maintainer of last resort can be built and funded at web scale — are the near‑term, concrete decisions the post leaves on the table.
