How long will the rapid update cycle last? [LWN.net]

How long will the rapid update cycle last?

Posted May 11, 2026 10:03 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Wrong tense? by ras
Parent article: Dependency-cooldown discussions warm up

With any luck, this period of high CVEs is temporary. There's a lot of code out there, and the current round of automated tooling is finding a lot of security-relevant bugs in older code, but once we've got through this hump, it's plausible that the total amount of CVEs found will drop considerably.

to post comments

How long will the rapid update cycle last?

Posted May 12, 2026 9:23 UTC (Tue) by ras (subscriber, #33059) [Link] (4 responses)

> With any luck, this period of high CVEs is temporary.

It's not obviously true.

If you look at the situation before AIs came along (say, a month ago), there seems to be a continuous stream of new CVEs. Not at the current AI-accelerated levels of course, but the point is they didn't go away despite what I assume is a constant level of both "intelligence" and effort put into it.

With AI, intelligence is no longer a constant. According to the AI companies it is doubling every 4 months. I don't trust that figure, but clearly it's increasing. AI also means effort is no longer constrained by the number of very clever, highly specialised people you can find. Instead it's constrained by how many power plants you can build, and the number of chips you can make. That means over the long term, the amount of effort a nation-state can put into it isn't constrained at all.

If there is some point where increasing the (intelligence × effort) stops yielding new CVEs, you're right. If that point doesn't arrive, nation-states will forever be building bigger and better AIs to find new CVEs.

However, there is another wrinkle. When I first read about Mythos my first reaction was like yours - there is a finite amount of code, so there can be only so many bugs. Now I'm not even sure about the "finite amount of code" thing any more. I have a personal friend who tells me he's written and deployed 1M lines of diffs so far this year. I know it's partially true. No human could produce 1M lines of diffs by hand [0]. But he did deploy them, and no other humans were involved in writing them. He could not have read them. Given he hasn't read them and given he uses the same Opus models I do, I know they are full of bugs. Not bugs your typical user will hit because a major portion of that 1M lines are tests, so from his perspective and his user's perspective he's done well. Sadly, CVEs are not the sort of bugs tests find.

I do not know what the way out of this is. I suspect languages in the mould of Rust and Wuffs that allow us to prove bugs of certain classes don't exist will be required, because I doubt you will be able to prevent the oncoming avalanche of AI-produced code.

[0] It takes about 1 billion tokens a day to produce that level of output.

How long will the rapid update cycle last?

Posted May 12, 2026 10:32 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (2 responses)

> over the long term, the amount of effort a nation-state can put into it isn't constrained at all.

You assume the effort curve will tend to infinity?
It's clearly an S curve that will eventually become logarithmic. Since we haven't seen the inflection point yet, we shouldn't assume it tends to infinity.

How long will the rapid update cycle last?

Posted May 12, 2026 11:03 UTC (Tue) by ras (subscriber, #33059) [Link] (1 responses)

> It's clearly an S curve that will eventually become logarithmic.

Yes, logarithmic is probably where it will end up. But if code generation starts growing exponentially that doesn't help.

There is another worrying aspect to this. There is a tendency to view this new CVE finding capability as an "open source" problem. That's wrong. Have you ever fed obfuscated javascript to an LLM and asked it to translate it back to readable code? It does it so well, it's often more readable and better commented than the original.

This ability to understand code humans find inscrutable isn't limited to obfuscated javascript. Researchers found CVE-2026-3854 two weeks ago by using AI-augmented tools to analyse closed-source binaries in GitHub’s internal infrastructure. A suitably trained LLM has no trouble reconstituting the intent of machine code, and once it's done that the CVE hunt is on. The machine code can be obtained from a proprietary binary or a ROM.

The proprietary hunt for CVEs hasn't started in earnest yet, as the right sort of people haven't woken up to the possibilities. But they will, and then the hunters will have a field day. You may be right about it becoming logarithmic eventually, but I would not count on that saving us.

How long will the rapid update cycle last?

Posted May 12, 2026 12:02 UTC (Tue) by paulj (subscriber, #341) [Link]

How would you know the translated code is the same as the obfuscated or the machine code?

I'd fully expect the LLM to produce code that looks reasonable - it's been trained on large volumes of code after all. However, it's not at all the case that LLMs are perfect at preserving meaning/equivalence across translations.

How long will the rapid update cycle last?

Posted May 12, 2026 13:56 UTC (Tue) by farnz (subscriber, #17727) [Link]

My hope is that projects will start applying bug-finding tools (including LLM-based tools) in earnest to code during the review phase, in order to stop there being a stream of CVEs for their project, and that we will not simply accept that security bugs are found after deployment.

If I'm right, then the increased capability-effort product from AIs will not result in more CVEs; it will result in more patches being fixed before they're applied to the mainstream project.

Thus, even with orders of magnitude more code being written, I hope to see the number of CVEs found by LLMs going down, not because fewer bugs are being written, but because tool-assisted review means that the bugs are found and fixed before the code gets to the point where a CVE can be issued.

And part of why I think this is plausible is that the tools don't get tired. If you give a human reviewer 10x the code to review, they'll start to make more mistakes over time, and more bugs will get past them; in contrast, the tools can be run in parallel, and if there's 100x more code, well, you just have the tool spend 100x the time on finding the bugs.