At Machine Speed

Yesterday, I opened Discord to a message from my friend Bastian Allgeier that I had never quite seen in all the years I’ve been building sites with his Kirby CMS. “Today we are releasing our biggest security release in the last 14+ years,” Bastian wrote. “The last few weeks have been intense, to say the least. We received 8 reports within just a couple of days.”

Six of those eight security reports turned out to be valid vulnerabilities. The resulting Kirby 5.4.0 release ships with a list of advisories that reads less like a changelog and more like a triage report. Nothing critical, nothing exploited in the wild, luckily – but for a small team that has been quietly maintaining a beautifully designed CMS for more than a decade, this is unlike anything they’ve had to deal with before.

And Kirby is far from alone.

A few weeks ago, Anthropic’s red team described how their large language model Claude Opus, pointed at a handful of open source projects, autonomously found and validated more than 500 high-severity vulnerabilities – some of them in code that had been aggressively fuzzed and reviewed by humans for years. Earlier this month, the same kind of work went public in a much bigger way. Project Glasswing, Anthropic’s partnership with AWS, Apple, Google, Microsoft, the Linux Foundation, and roughly forty other organisations, uses an unreleased model called Claude Mythos Preview to find vulnerabilities in the software that runs pretty much everything. Thousands of zero-days. Including a 27-year-old bug in OpenBSD, an operating system famous for its security hardening. A model, Anthropic says, capable enough that they have decided not to release it.

There is, obviously, a marketing layer to all of this. Glasswing is a beautifully staged announcement, complete with partner logos and a butterfly metaphor. Independent researchers have pointed out that the list of CVEs directly attributable to the project is, at the moment, much shorter than the headline numbers would suggest. And there are legitimate antitrust concerns about a private consortium of the world’s largest tech companies having exclusive access to a tool like this. And yet, if you look around, even the more sceptical voices in security seem to be treating this as a genuine inflection point. Rich Mogull at the Cloud Security Alliance has been calling it the “Vulnpocalypse” – the moment when language models can find zero-days and write working exploits faster than we can patch them.

What this means on the ground, for the people actually maintaining the software, is a flood.

In January, Daniel Stenberg, who has maintained curl for nearly three decades, shut down the project’s bug bounty program because he and his security team were drowning in AI-generated slop. A few months later, the slop receded. But it was replaced by something harder to dismiss: genuinely good security reports, almost all done with the help of AI, arriving at a frequency his team has never seen before. The quality went up. The workload did not go down.

And that’s the problem: generating a finding is cheap. Validating and patching it is not. And that cost then falls entirely on the maintainers – on people like Bastian and his Kirby team, on the Linux kernel reviewers, on the handful of volunteers who keep the dependencies of the dependencies of the dependencies alive. If the only realistic answer to machine-speed discovery is machine-speed triage and patching, then the maintainers who are drowning in reports don’t just need more time and more hands – it feels like at some point, they will need the same kind of tooling that is drowning them. The tool is both the flood and the pump.

But the pump has a price tag. Right now, that pricing is softened by subsidy – the big AI companies are losing money on every query while they compete for market share. When prices adjust – and they will, in fact, they already are – the bill lands somewhere. Big companies will pay it without flinching. The corporate security industry is already busy selling them tools to handle attacks “at machine speed” – agentic AI, autonomous SOCs (security operations centres), hyperautomation platforms. But who pays the bill for a small team like Kirby’s, or the maintainer of a Craft CMS plugin, or the PHP library three layers down that half the web quietly depends on? All of this is also going to become a governance question for open source, and I don’t know whether we have an answer yet.

And ultimately, we, as an industry, are the downstream.

I run Kirby in several client projects and I trust the team and their work. Every time a security release lands, I update quickly and quietly, usually covered by a reasonable maintenance retainer. But the cadence is changing. The usual “let’s skip a few minor updates to save the budget for the bigger ones” will probably not hold up anymore – at least not if you care about security, which you should. And for each update, someone has to read the release notes, test the update, and push it to production, ideally the same day. That is going to become a much more explicit part of the conversations I have with clients.

And of course, it’s good that these bugs are being found. And they need to be fixed. The 27-year-old hole in OpenBSD was there all those years – we just couldn’t see it. Making bugs visible is a gift, even when the gift arrives wrapped in a pile of work. But visibility is only the first step. What matters is whether we can really close the gap between finding and fixing – and whether we, as clients, as agencies, as developers, as a community, are willing to fund, staff, and support the people doing the work.

But also: what can we do, together, to make the software we depend on more secure? In budgets, in update routines, in client conversations, in the way we contribute to and pay for the projects we use every day. I will see Bastian at beyond tellerrand Düsseldorf next week and we’ll certainly talk about all of this a bit. But I know I’ll also be having that conversation with every one of my clients in the coming weeks. And I’d love to hear your thoughts on this as well: how does it all play out for the projects and websites you maintain?

~