The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult.

But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

▲ flerchin an hour ago | parent | next [-]

The vast majority of CVEs are not exploitable, basically noise. I suspect that the overwhelming majority of the CVEs being generated by LLMs are either noise of the sort in the linked article or noise of the sort that is not exploitable.

▲ jmull 4 minutes ago | parent | next [-]

Yes, the CVE system is broken. LLM-generated CVEs is making it even worse.

I suppose all these fake issues and the many more that have absurdly elevated severities could be considered an attack on the system itself, stripping it of credibility.

▲ cogman10 an hour ago | parent | prev | next [-]

This is what I truly don't like about the CVE system.

One such example is CVE-2023-45853 [1]. Zlib included in it's source an extra set of utilities and add-ons. One such utility, MiniZip, had a buffer overflow vulnerability. BAM, 8.8 CVE (was a 9, looks like they pulled it back a bit). But not one that the 99% of applications using zlib would ever be vulnerable to because almost nobody used the MiniZip utility. It was so unused that the solution for zlib was to simply remove it.

I know about this one particularly because our security policy required us to do a BUNCH of pointless updates for it since zlib is in just about everything.

[1] https://app.opencve.io/cve/CVE-2023-45853

▲ stabbles 37 minutes ago | parent | next [-]

In the Spack package manager [1] we're trying to work around this with directives:

    deprecated("@:1.3 +minizip", reason="cve", severity="high")

So, you can define conditional deprecation, and the dependency resolver can still pick up `zlib ~minizip` (i.e. with a variant/component disabled).

Deprecation on versions only isn't the right granularity.

[1]: https://github.com/spack/spack/pull/52372

▲ post-it 42 minutes ago | parent | prev | next [-]

But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.

	▲	cogman10 36 minutes ago \| parent \| next [-]
		Well that's the thing, to build the utilities required extra flags which were pretty rarely enabled. You can, in most distros, ultimately install minizip as a separate package but few do. It's not that useful of a utility. Most people will likely just grab the full blown "zip" application https://infozip.sourceforge.net/Zip.html . Though on linux, even more people are simply using tar with a zlib extension. That's the `tar.gz` files.
	▲	PunchyHamster 13 minutes ago \| parent \| prev [-]
		if the tool isn't ran it can't be exploited CVE should just be far more granular instead of flagging alert for anything using zlib

▲ dncornholio 32 minutes ago | parent | prev [-]

If the solution was to remove an unused dependency, I think this CVE isn't silly at all.

▲ bluGill an hour ago | parent | prev | next [-]

The majority these days seems to be real issues, but probably not exploitable. The latest LLMs are very good at reading code and finding issues where the code is wrong. They are somewhat less good at finding exploits - both because finding exploits is harder than finding code that is clearly wrong (even if not exploitable), and also because the better ones are intentionally made to not create exploits (since they don't know if you are a good or bad - they assume bad.

However if I was writing this response just one year ago I would instead be saying: the majority off LLM CVS are noise where the code is correct, and often they are writing up for code that doesn't even exist.

Which is to say I suspect the repo in question was generated with a year-old LLM, since they act like that. The new ones [mostly?] are much better.

Still, if a modern LLM points out something you should fix it. Even if we can't figure out how to exploit it today that doesn't mean we won't figure it out in the future.

▲ pbronez an hour ago | parent | prev [-]

I once had a customer threaten to reject a delivery over a CVE. I dug into it. The CVE was that an Ocaml PostgreSQL client didn’t implement an authentication feature.

I convinced the customer to accept the delivery by pointing out that (1) our app had zero lines of ocaml and (2) the feature had been implemented in the ocaml driver since the CVE was issued.

▲ jodacola 17 minutes ago | parent | prev | next [-]

I'm sending all my condolences out to everyone who is in a corporate environment using tools like Veracode or Snyk to automatically assess for CVEs and block merges or deployments based on "findings".

My experience in such environments leads me to believe this is going to be a rough ride for those heavily locked-down enterprises, because depending on the environment, an exception of "this CVE was hallucinated by AI" is probably going to be difficult to get accepted, and when it does, starts to become its own avenue for exploitation and adds even more noise and confusion to the mix.

▲ pornel 4 minutes ago | parent | prev | next [-]

CVEs sucked even before LLMs. CVSS is an ass-covering exercise, not an importance signal. Everything is "critical" all the time.

▲ gedy 27 minutes ago | parent | prev | next [-]

I think in both cases, the LLM use needs to be handled by someone experienced with the domain. We are seeing this over and over with product development, writing, images, etc. Without good people driving this it's just noise

▲ ymir_e 2 hours ago | parent | prev [-]

Edits for clarity: seems like this was a controversial take, which I find pretty interesting.

I believe people took this comment as LLMs being better than security aware engineers who have the time to spend building solid systems.

This wasn't the point, the reality outside "established" tech companies is that software security can be lackluster.

There often simply isn't enough resources to check old software for basic vulnerabilities, outdated packages with known issues, there might be a manager who insists on a certain solution. Or that certain services are on "maintenance mode", but rarely get checked since they're on a certain part of the internal network.

If they are able to properly scan their full software stack for CVE issues, they cannot deal with a flood of CVEs.

----

We're in a transition period where AI will eventually make software much more secure than it ever was.

These noisy CVEs will probably lead to agents verifying vulnerabilities before humans review them.

The problem with agent reviews from what I can think of is:

- cost to use LLMs to review things

- not necessarily easy to plug-and-play in repos: (domain knowledge + vulnerability knowledge)

- especially with anthropic: able to use models defensively, without hitting guardrails

The last one is the most interesting one to me. How does the AI providers know if you're a "good or bad" guy? And does it matter if open source models is catching up?

We're in a kind of cyber arms race wether we like it or not.

▲

rghammt an hour ago | parent [-]

Currently we either get AI promo vulnerability dumps like from Chrome with pretty graphs that no one checks or false positives.

Where is this one now that was hyped everywhere?

https://news.ycombinator.com/item?id=49133889

The GitHub submitter could no longer reproduce the issue and the LKML post has no replies:

https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...

▲

bluGill an hour ago | parent [-]

All the big maintainers I know of disagree. Curl for example is getting overwhelmed with real issues that LLMs are finding. A year ago most LLM found issues where false positives (the code is correct), or hallucinations (the code in question doesn't even exist) - but that has changed and now LLMs are finding real issues in code. Many different projects have reported the same rules.

	▲	ymir_e 22 minutes ago \| parent [-]
		Absolutely. I'm not sure how universal this is, but I saw George Hotz tweeted something about Mythos not being such a big deal since he's able to find security issues without a claimed $20,000 in token spend per vulnerability. The reality is that humans aren't perfect, so we do not make "perfect programs". It is also possible to test it yourself to see how good LLMs are at finding software issues: Find any open source project that isn't huge, then have Kimi 3 review it for potential issues. You will find code "issues". Most of the time it won't be detrimental for security, but often there are code paths that are not "accounted for", or you're able to bypass a type of check by interacting with the software in a strange way.