Hacker News Reader

Comment by darkamaul | Hacker News Reader

I would be curious to see the distribution of these vulns in the codebase:

- What subsystems are affected?

- What's the median age of the vulnerable code? Is more recent code stronger than old ones?

- What is the type of vulnerabilities found? Memory corruptions, logic bugs, race conditions, ...

This is an impressive result, but we need more info to understand how well this would translate to another codebase, and what lessons can be drawn from this experiment. Not every company has ~million dollards in tokens to spend.

View on HN

Good points. Unfortunately, they don't have the people nor the incentive to actually look into that.

Also, let's maybe not call the result impressive until we see what's under the hood.

>Unfortunately, they don't have the people nor the incentive to actually look into that.

These are relatively simple statistics. Some are even trivial. I don't see why it requires any people at all.

It wouldn't even have to be done by OpenAI. Given a list of vulnerabilities, it wouldn't be too hard for third parties to collect these statistics.

> don't see why it requires any people at all. It wouldn't even have to be done by OpenAI. Given a list of vulnerabilities

Who would put together that list unless individuals at OpenAI does it? It's not like we have machines that can think kind of like humans and do a bunch of stuff automagically.

Just go ask some actual kernel maintainers who are being spammed by frontier models daily.

> These are relatively simple statistics.

According to Greg KH 50% of the vulns are flat out wrong, or the patches don't fix the problem, or the scenario is impossible in the real world, or just isn't a security issue.

To be fair that sounds like similar false positive rate to human bug reports, if not better. Although the agentic scale of these reports must consume huge amounts of time.

The kernel has also been removing a bunch of old unmaintained drivers due to these reports.

I have to wonder how many of these 1000 paths are simply dead drivers with security vulnerabilities [1]. Impossible to exploit because nobody uses it, but easy enough to juice up the numbers of "found" vulnerabilities.

[1] https://lwn.net/Articles/1068928/

All the marketing from OpenAI and Anthropic about "we used the model to find X vulnerabilities in Y" without any technical depth whatsoever, as is customary in the security space, basically boils down to "big number scary. model fix."

I said in another comment that I await the technical writeup of the so-called new techniques that they aren't sharing for "safety reasons" but if history is anything to go on, they will never publish a writeup. They set out to get their headline and that's where the work stops.

> These are relatively simple statistics. Some are even trivial. I don't see why it requires any people at all.

They're not here to help the community, they're here to get headlines, and, possibly, replace the community.

If only OpenAI had some sort of cluster of thinking machines they could apply to generating such a report.

Indeed. Yet instead they generate a report that is 75% opinions on how everyone else should spend their money.

My take on it is that until the flood of discoverable vulnerabilities slows down it doesnt make sense to release data that could make it easier for bad guys to find them.

Want the build the stats? Data mine the patches, and infer it yourself, publish it if you want to. That's how some people find bugs that aren't disclosed as explicit security fixes (and not every security issue needs a disclosure and fancy name, especially if it is introduced,found and fixed in a dev cycle before the code is part of a release)

Reply on news.ycombinator.com