Hacker News new | past | comments | ask | show | jobs | submit
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.

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.
loading story #49155107
loading story #49155728
loading story #49156638
loading story #49156518
loading story #49155083
loading story #49155817
loading story #49155212
loading story #49157050
loading story #49156729
loading story #49156028
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.

They’re not bad if you give up on being able to reproduce arcane bugs. Don’t pin versions, pull everything from latest, CVEs are just a rebuild. Certainly not an amazing idea, but it solves the problem of the day.

The funnier, Kafakaesque problem of the day is interactions with mandatory cooldown periods on new versions because of supply chain risks.

I’ve had a couple tickets get stuck because the CVE scanner says I have to update, but the cooldown enforcer says the version hasn’t been out long enough.

>Don’t pin versions

In enterprise software..... I only dream of work where some ancient version isn't pinned because 200 person hours are need to adapt the code to newer versions.

And the update versus cooldown are fun. Can't win either way you go.

> Don't pin versions, pull everything from latest

Rebuild broke half your tests. People are exploiting the CVE against your system right now. Good luck!

loading story #49161697
loading story #49158409
In our organisation, my security team spend the majority of our effort weeding out unexploitable CVEs - which are the majority of them. But the volume is growing year on year - I don't know how sustainable it's going to be.
Sounds like a good job for AI. I do fear that the future will involve deploying AI do deal with the mountain of slop produced by other AI's.
loading story #49161652
Snyk routinely tells us that we need to upgrade urgently because they found a vulnerability in the Windows version of a package. We run everything in Linux.
CVEs sucked even before LLMs. CVSS is an ass-covering exercise, not an importance signal. Everything is "critical" all the time.
Which is precisely why I do not celebrate when Microsoft or other companies say they released "their biggest set of security vulnerability fixes ever" because there's a good chance that most of them are hallucinations or non-critical issues erroneously considered zero-days or critical.

What actually needs to be done is human review, vetting, and approval of those. Otherwise, it's just unknown/unnecessary/potentially dangerous changesets in high quantities.

loading story #49158453
> I do know that LLMs have been discovering a lot of legit CVEs,

And that's great! Now the human in the loop can verify the accuracy of each finding and take responsibility for moving it forward.

> and I will lay odds that the blackhats are leveraging them to the max.

We just need more humans in the loop to do that more quickly, each putting their own reputation on the line with each CVE they determine to be legit.

AI doesn't stand for "accountability irrelevant", even though most people act like it does.

loading story #49158184
Basically nothing is real nowadays unless you verify it for yourself.
This is an issue with CVEs not LLMs
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
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.

loading story #49154780