Review? [LWN.net]

Review?

Posted Apr 27, 2026 6:39 UTC (Mon) by tchernobog (subscriber, #73595)
In reply to: Review? by pabs
Parent article: Dependency-cooldown discussions warm up

> I feel like code review and building from source is the way to avoid malware in the "supply chain".

Unfortunately:

* in FOSS, we don't have many (good) reviewers, and most companies are freeloaders
* LLMs are producing harder and harder code to review, and in a quantity that puts considerable burden on maintainers
* the xz supply-chain attack shows that a bit more sophistication and planning from the attacker goes a long way; and it certainly was triggered when building from source and the code was reviewed

At some point, nobody will like it, but we need some kind of attestation process for FOSS, or a way to make companies invest resources into FOSS maintenance.

We'll see if the EU CRA law will help in this regard starting end of 2027. It can go both ways.

to post comments

Review?

Posted Apr 27, 2026 8:25 UTC (Mon) by pabs (subscriber, #43278) [Link] (11 responses)

Yeah, review is in short supply, hopefully the CRA and or the many supply-chain attacks in recent years change that.

IIRC the xz attack payload was outside the VCS in the tarball, probably if people were doing reproducible tarball creation then it would have been caught.

What do you mean by attestation process for FOSS?

Have we seen any early effects of the EU CRA on companies yet? Are they talking about internally yet? IIRC so far I only saw people retracting their FOSS code from public view or reducing/eliminating their FOSS activities.

Review?

Posted Apr 27, 2026 9:23 UTC (Mon) by tchernobog (subscriber, #73595) [Link] (3 responses)

> What do you mean by attestation process for FOSS?

Some kind of way of reliably checking the author of a change, e.g. via proper code signing and on-boarding of developers. But with AI taking more and more the helm, this is getting to be a fuzzy concept anyway. There are some attempts with e.g. https://slsa.dev/

> Have we seen any early effects of the EU CRA on companies yet? Are they talking about internally yet?

I can only speak for my company, a EU mid-sized manufacturer (around 1'000 employees, ~ half a billion yearly revenue).

I can tell that:

* we are well aware of the requirements and are currently (and slowly: we are a hardware company too) working towards compliance
* this led to the creation of internal processes and structures that weren't there to respond requirements; this means also the establishment of an independent security team which was not there before, which is good
* we have now a (not huge, but not tiny) budget to spend on external contractors for fixing important open-source bugs, e.g. in u-boot, hashicorp vault, and more
* we have now full SBoM scanning for all dependencies and are taking timely action to reduce risks around unmaintained or buggy dependencies. So well maintained projects will get more attention, poorly maintained FOSS projects will get the kick

But I cannot speak of course for all companies; this is only anecdotal evidence that something is happening.

Review?

Posted Apr 27, 2026 13:01 UTC (Mon) by pabs (subscriber, #43278) [Link]

> Some kind of way of reliably checking the author of a change

What would be the point of that? As we saw with xz it isn't the author (or any aspect of their identity) that matters, its the code that matters. The many many times devs got hacked and their credentials were used to push malware. Or they sold their maintainership of their program (possibly including credentials), and spyware got added. Or that time an upstream released with a backdoor that would only activate on a particular Debian person's machine.

> via proper code signing and on-boarding of developers

Distros like Debian have both of those, but they don't have enough code review that they would always block any of the above.

Review?

Posted Apr 27, 2026 13:14 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

A few suggestions for your FOSS processes:

Hope your license compliance is up to scratch too :)

Have a budget for contributing back financially with direct donations and or sponsorship.

Have a team working on contributing back code and otherwise participating in FOSS communities, joining forums, mailing lists, conferences etc.

The unmaintained/undermaintained projects are the ones that need you to assist them *more* *instead* of ditching them.

Since you are a hardware company, please consider making it simple to replace your software/firmware with open equivalents.

Review?

Posted Apr 27, 2026 13:36 UTC (Mon) by pizza (subscriber, #46) [Link]

> The unmaintained/undermaintained projects are the ones that need you to assist them *more* *instead* of ditching them.

...I wish more folks understood this.

(Not to mention that "undermaintained" being the overwhelming norm -- If you ditch those [sub-[sub-]] dependencies you're left with... doing all of the work yourself, I guess?)

Wrong tense?

Posted May 10, 2026 4:09 UTC (Sun) by ras (subscriber, #33059) [Link] (6 responses)

> Yeah, review is in short supply,

It was in short supply, until about 7 April. Not long after that, Firefox (on an unnamed OS I've forced to use) started updating itself every day. I had no idea why, and it drove me nuts. I later learned about Mythos, and a light bulb went off.

We can't be too far from the day when a review LLM of some sort becomes integrated into Debian's upload queue. I don't see any other way Debian can say, with a straight face, that the distribution uses its best efforts to give secure code to its users. My local LUG mate who packages Chromium for Gentoo tells me since about April 7, it went from 3 CVEs a week to 167 last week, and it's still going up. He was as perplexed as I was, for a while.

It's our brave new world I guess, one where we augment the limited human review pool with gigawatt power stations.

How long will the rapid update cycle last?

Posted May 11, 2026 10:03 UTC (Mon) by farnz (subscriber, #17727) [Link] (5 responses)

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.

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.

Review?

Posted Apr 27, 2026 9:50 UTC (Mon) by kleptog (subscriber, #1183) [Link] (1 responses)

> LLMs are producing harder and harder code to review, and in a quantity that puts considerable burden on maintainers

Is this an actual data point or a fear? If the patches are too difficult to understand they should be rejected. Otherwise they'll never learn to produce readable code.

Junior developers have to be taught this as well.

Review?

Posted Apr 27, 2026 10:35 UTC (Mon) by TomH (subscriber, #56149) [Link]

I find that the difficulty is mostly not understanding the change, as a lot of the LLM driven PRs I see are actually fairly trivial, but rather the process of trying to carry out the review and interact with the nominal submitter.

The difference is that a human junior developer will (hopefully) learn from review comments, not just in terms of acting on then for the change under review, but also in terms of doing better with their next change.

An LLM will never do that, because it can't, so every change it makes is like a freshly minted junior developer and you're starting over from scratch every time. Sure in theory you could provide previous reviews as context but nobody's actually going to burn tokens on that.

Now if there's a human sitting between the LLM and the reviewer then maybe they will learn and will do a better job of prompting the LLM and reviewing it's output next time round but all too often any human that does exist is just copy-pasting the review comments back into the LLM and then copy-pasting the result back into the pull request and essentially just acting as a stenographer that adds no value to the process at all.

Frankly it's utterly soul destroying trying to review most of the LLM driver PRs we get for the OpenStreetMap web site code and I at least have mostly given up even trying.