We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are.
LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are dealing with probabilities in a situation where certainties, not probabilities, matter, you’re going to get dinged on credibility massively when your LLM-based “AI” gets the probabilities wrong at best, or in this case, claims a line of code generates a vulnerability when it is, in fact, a code comment.
LLMs are text-prediction engines. They are not Artificial Intelligence, and shouldn’t not be treated in any form or fashion as if they possess intelligence. What bothers me about this entire situation is that presumably the folks that relied on the LLM-based “AI” to generate these vulnerabilities knew (or should have known) enough about their tool to know this would happen, but did not.
Now, we all pay the consequence, to the tune of hundreds of thousands if not millions of dollars of wasted productivity from teams that have to deal with the resulting fall-out of this usage of “AI”.
A human must verify everything an LLM presents as fact. Everything. If you don’t, we all pay the price. LLMs do not remove the onus of responsibility on the human being, if anything they amplify it because LLMs can generate lots more output more quickly that needs to be verified than humans can.
Unfortunately people sometimes get defensive against this take. But I think treating the LLM as you described can make you a better LLM user and help get better output. It helps understand the failure modes better, and moderate one’s reliance on them. Just like how we should do for every tool we work with.
Yes, I've found that reminding yourself of how they actually work helps keep you on guard against LLM-patterned mistakes. Especially things like carefully considering what parts of the current task likely fall outside the distribution of corpus + RL data (as much as that can be guessed).
Turing-completeness is a necessary pre-requisite for being able to fulfill the requirements of a Turing machine, nothing more. In the same way that cell division is a necessary condition for life, but cell division does not mean a given life form itself is sentient.
Intelligent life-forms can generate probabilistic outputs based on inputs, but being able to generate probabilistic outputs based on inputs is not what makes us intelligent.
> but being able to generate probabilistic outputs based on inputs is not what makes us intelligent.
???
Of course it is. The brain is mechanically not capable of doing anything other than that.
Do you believe the brain is something other than a bundle of probabilistic physical interactions? Or are brains not the source of what we call intelligence?
OK. A more pointed question. What do you know about intelligence that allows you to exclude LLMs with CoT from the category of intelligent systems with certainty?
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.
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.
Reminds me of the time our “security” team fought with me for a year to fix an issue in a third-party dependency that was failing their scanners. The issue was only a problem for and intentionally left in to not break support for Internet Explorer 6 on Windows XP, neither of which anyone at the company had used in 10 years, and everyone using this software was on a Mac anyway.
My condolences to anyone who’s got to deal with all these slop-y CVEs on one side and brain dead security teams on the other.
Isn't the real difficulty in how vulnerabilities can be mixed? A given vulnerability might be extremely hard to execute, but very damaging. Another vulnerability might be easier to execute, but it can't do much. But if the second one can be used to trigger the first one, you then have attack surface area of the second vulnerability with the damage of the first one.
Even if some individual case can be shown to be safe from being combined, can we identify such cases with enough confidence to justify using it reduce severity warnings?
Thats not enough. This problem pops up everywhere people do CVE analysis. If a tertiary part of some library is hit by some arbitrary CVE, why should that affect the core functionality people actually use? If I use ChaCha20, and that's bundled in a library with md5.do I care that their md5 library has a vulnerability? No, not really.
If you keep driving the "seperate the packages" angle you end up with is-odd, and that not a nice play to be either.
Even more than that, a lot of vulnerabilities require untrusted input to exploit, but the library or executable is usually only used with trusted input. For example, suppose the chacha20 function had a vulnerability that was exploitable with a malicious secret key, but you only call it with your own, definitely not malicious, key. The vulnerability doesn't impact you, but your security policy might still require you to update. And no amount of splitting the package will help with that.
I have concluded that even though I won't use that key, I still want the issue fixed. You never know if the key I randomly choose next year is the vulnerable one. Worse, you never know if someone else won't make a bug that allows outsiders to select a key...
At least for native binaries it's not too hard to write a scanner that extracts symbols from the binaries and checks them against the symbol names of the vulnerable code. If the code is properly dead and got pruned by the linker, it cannot cause any problems.
Yes it can cause you troubles, even if you don't link to it. Just having a vulnerability scanner (incorrectly) flag it can cause you numerous problems.
Say you distribute your application to a customer and link against libzip, and that customer points to the minizip 8.8 CVE above and says "if you don't fix this vulnerability our scanner is flagging, we are required to stop using your product", that'll cause you plenty of problems even though you don't use nor provide any way to reach the vulnerable code.
That sort of blind CVE adherence is so common in the industry that it's usually easier to do meaningless updates than fight back.
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.
I think this presents a highly fascinating scenario:
1. A vulnerability that presents itself very rarely
2. If it presents itself, it is fatal to the organization
So, few targets are affected, but the outsized effect means that the overall economic impact is not insignificant. How does one keep track of that?
One method is to use a sort of "kirchhoff's law" approach, similar to google page rank. The electrical analogy would be:
- the attacker has a high potential, let's say 1000V. that attacker is the root of a rose tree, going from top to bottom, branching out towards the bottom.
- nodes impossible to exploit present edges with infinite resistance
- nodes that can be exploited present finite resistance (perhaps very low)
- once a node is exploited, its node branches out to other things that now become accessible and may or may not be exploited
- real economic impact presents a connection to ground, measured as 1/($economic impact) ohms resistance
Once you have a structure like that, you can measure the hypothetical current that would be flowing, and measure the severity of such exploits.
Sometimes a single path through a complex system can blow up vital, important parts, and this could be one way to measure it in some sort of objective manner.
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.
That's the worst case scenario right there: so many fake reports that the real vulnerabilities can no longer be reported properly and fixed quickly. Assuming some LLMs really are capable of finding serious vulnerabilities (which in my experience is absolutely the case : just let a good model run on your security code base and see for yourself) that means that we can more easily find vulnerabilities, but it's much harder to report them and be taken seriously - so the incentive to exploit such vulnerabilities instead has become much, much higher.
> The vast majority of CVEs are not exploitable, basically noise.
This is not true if you consider security-in-depth. Many of them are exploitable on their own but maybe not in combination with other issues that are as yet unknown or known but not patched everywhere.
As a simple example a local privilege escalation issue that is not exploitable on a device that only I ever have access to, essentially becomes a remote root access flaw if you have untrusted or unreliable users (clients with accounts for instance) on the system. This works on a finer grain too, seemingly minor issues spread through the kernel and user space can add up to a serious exploit.
This is the most common "not exploitable" CVE I have to deal with at work all the time. Things like buffer overruns when passing headers, but my server shouldn't be accessible to the public Internet anyway, and if it is, then we have much bigger problems. So yes it's technically exploitable IF other safeguards fail, but the reason it's irrelevant is that if those other safeguards fail, we are in deep shit anyway.
Or you can just fix the issue that way if IT screws up you are not vulnerable. Or maybe next year you will decide it is useful to connect to the internet.
But if you have proper risk-based vulnerability management, you should already have classified that CVE as a lesser priority. This is something that modern LLMs should in theory make a lot easier, although I’m unsure if workflows exist to continuously build a proper architectural understanding of your systems, at least at a feasible cost.
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.
> I suspect the repo in question was generated with a year-old LLM
I suspect there are a lot of people running inexpensive models that are searching for vulnerabilities across a lot of projects, probably in an automated way (ex with openclaw or similar) in the hopes of winning a bounty and/or noteriety.
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.
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.
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.
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.
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.
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.
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.
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.
1. George Hotz exhibits strong signs of Dunning-Kruger in most things he does nowadays.
2. Even in exploit development, his original field, he might be able to find vulnerabilities in mature, well-maintained software with security programs. But would he charge $20k or more for that service? Say it with me, Claude: “Absolutely!”
Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.
That is exactly why many big projects are migrating to becoming CNA, so that randos can’t get assigned unqualified CVEs which nobody has looked at or validated.
Apparently RedHat is a CNA of last resort, so it might be possible to get your project under Redhat’s scope and go through them without having to be a CNA yourself.
That's nonsense. The goal is and always has been to undermine the CVE system because Greg does not believe in the system. The kernel is the only project that marks CVEs to fixes, it's the only project that considers every bug to be a "Security" bug, and it has a multi-decades long history of telling the security world to fuck off - all consistent with what I've said.
No one else has the process that the kernel has, despite plenty of people having software that's deployed in very similar ways.
There's zero question - this is ideologically motivated, not a genuine good-faith attempt to leverage the system.
Make a case then. My case is that Greg has, for decades, said that he hates the CVE system and rejected it and that the kernel objectively labels CVEs based on fixes (not the standard at all, CVEs are for vulns), etc. I can point to so many objective pieces of evidence to support my claim.
You seem to have a vague, leading question. If you want to say something about "other groups" or ideologies, go ahead.
It's been a problem for awhile. Daniel Stenberg has talked about it numerous times on his/curl's blog for the last 4 years. They became their own CNA to try and control it, they opened a hackerone with rewards, but now removed the rewards because it got flooded with AI generated slop daily.
So the agents started doing something useful after a period of filling mailing lists and bug bounties with slop. Sound good, but that's not entirely a good thing. The volume of good reports is a burden as well, and it's likely that long-lasting open source C/C++ projects have legitimate vulnerabilities unpatched. But we don't have any new maintainers, I think.
The real question is will [when will] these vulnerabilities get fixed faster than they can be found. LLMs are finding a lot of real bugs that have existed without being noticed for 20+ years. It is generally expected [hoped] that in a short time all those 20 year old bugs will be fixed and LLMs will settle down to just things introduced in the last month (or perhaps this pull request) and thus be manageable.
First, is there any reason they have to? The LLM makers are aware of this problem and doing things to stop it. Maybe they will start saying "I can't find anything". Already they refuse to provide some exploits.
Second, most people are not prompting for a CVE, they are asking to review and find issues if any. Which sometimes finds a CVE, but in my experience it sometimes does say "looks good".
One can hope that will put pressure on the industry to design a better system than CVEs. The signal noise ratio was already terrible before LLMs, I cannot imagine that will still be a meaningful system in 10y.
But I’m too cynical to not consider all the middlemen who benefit from the status quo
I'm very curious what organisations would have such a policy. I can't imagine it being viable for any size of org without significant self-deception (or banning the use of all open source at which point CVEs are moot anyway).
> I'm very curious what organisations would have such a policy.
I would humbly suggest any org of any size that has insurance cover that covers anything tech related (e.g. data loss/recovery, cyber etc.) has a very good look at the small print.
Over the last few years insurers have aggressively been adding "no vulnerability patch, no claim" exclusion clauses.
Yeah, policies like this are often not coming from engineering directly but often through other parts of the company like legal, or even sales from contract negotiations. Not that it's entirely comparable, but I was at AWS when the big log4j vulnerability happened, and the handling for it was not left up to individual engineering teams, which I don't think would surprise anyone.
At a large enough company, processes for handling things like security vulnerabilities will have a lot of stakeholders with incentives that are not necessarily perfectly aligned.
Many orgs (esp w ISO27000) have a vulnerability management policy that involves patching at least critical CVEs within a short timeline. Tools like trivvy make it possible to do the scans…
I've been in such an org, & I've led initiatives to set up automated detection at very large scale. We started by issuing tickets to teams to resolve CVEs within varying timelines - ranging from a 24hr fix to 6 months - connected to the CVSS score. It wasn't viable.
- Firstly, you quickly realise how irrelevant CVSS scores are - initiatives like First's EPSS are designed to fix this but they aren't there yet
- Secondly, you need to begin implementing localised heuristics to determine exploitable code paths. This has generally been incredibly difficult to do reliably - LLMs have started to make it easier, but it's expensive.
- Lastly, you need to factor in consideration of actionable remediation pathways. A dependency upgrade for critical infrastructure might contain breaking changes that take months to fix, or two competing CVEs might be present in interdependent versions of transitive dependencies in your sbom tree.
Most orgs aren't applying any of the above three filters to reduce their CVE remediation burden, & even if they are, it's still too high to make zero a viable target.
In reality, most orgs aren't doing comprehensive detection to begin with - if you haven't discovered all of your CVEs, your remediation burden is going to be a lot more manageable.
> - Firstly, you quickly realise how irrelevant CVSS scores are
Even if you factor in the environmental score? I realize it's a lot more work, but it basically allows you to tune the score to get any value you want.
Imagine a YAML parsing library that can cause an out-of-memory exception if you give it a YAML file greater than 3 megabytes.
If you're an online service where untrusted users can submit arbitrary YAML, and an out-of-memory exception is a severe problem, then it's severity 10.
If you're an online service that doesn't use yaml in any way, but your web framework bundled the library as a transitive dependency because yaml is one of their five supported configuration options, then it's severity 2.
The problem is figuring out which of those situations you're in takes a load of time - and the flow of CVEs is endless, as CVE numbers are given out like candy at halloween. Often it's quicker to just update to the latest version of the YAML library.
I have been given a list by security. "We had an automated tool scan that machine. It reported these. Fix anything medium severity and above.
Never mind that some of them involved vulnerabilities in some part of the bluetooth stack (servers in our datacenter don't even have bluetooth). But they just didn't care
This does make some sense if it's considered a valid fix to document that you have verified that Bluetooth is disabled on the servers and therefore not vulnerable. But that assumes that the scanning tool can be told about this kind of fix, so that it stops warning about it, which I guess it might not.
No, but if you don't patch them you need to convince an auditor that they are not a problem. Often patching is easier.
I'm working on such a problem now - we are using an old web browser (no longer supported) to show help on one system. That is web pages were generate internally, with no links elsewhere, and no provision for the user to enter a URL. It is still easier port to a newer supported browser than to convince the auditors that that we are not exploitable. Sure it is obvious that everything is internal and we won't write html that exploits bugs, but nobody wants to convince an auditor of that.
Any org large enough to have separated the people responsible for the security exposure of the organisation from the developers with familiarity of what's deployed is likely to have done exactly this.
The thing you have to remember is that CVEs can be a) scanned for without exerting mental effort, and b) counted.
SOC2 CC7.1 [1] requires a vulnerability scanner, findings tracked with tickets, assigned severities according to a documented risk-based system, severity-based SLAs for remediation, and that the SLAs mostly be complied with or have tracked exceptions.
However it doesn't mandate any particular SLA, or the details of how risks are to be evaluated.
Organisations get to write their own policy, and they don't need to commit to patching every CVE within 24 hours or anything like that.
For one thing, bigcorps in regulated areas like it a lot. They push hard to get it required by the regulations (in practice if not directly). Although it's quite inefficient, it becomes a regulatory moat. A cost they can bear that potential upstart competitors cannot.
Many large organizations like banks have requirements like this and they solve it through a mix of automatic scanners, e.g. Trivvy, and self-deception as not all systems are actually scanned in any sufficiently large org.
> I'm very curious what organisations would have such a policy
Do you provide SOC2, HIPAA, GDPR, or similar certifications to your b2b customers? Then your tech stack undergoes an annual audit, and in your audit you will need to provide a paper trail for every single vulnerability in your stack.
In practice, this means that your audit compliance software (something like Vanta.com) is going to be setup to mandate every CVE in the whole stack is patched within SLA.
ITAR has no such hard requirements. Might be some orgs that tell themselves they're attempting this under ITAR but they're not doing it in any comprehensive way.
The only thing within ITAR that I'm aware of concerning itself with software supply chain is SP 800-218 requirements & that's just a load of open-to-interpretation weasel words about having CVE detection & automations in place & some defined plans for reducing the number of vulns. Pretty sure that component of it is even eligible for self-assessment.
Yes and no. ITAR (and other laws like it) are self assessment and don't specifically say thing thing.
However your interpretation / self-assessment is subject to various reviews/audits. These days the reviewers are not going to be kind to someone who just says "not an issue", they will demand strong justification. Most organizations take the view that is is easier to fix all CVEs than try to pass audits.
Thus by the letter of the law you are correct. However to meet the letter of the law without fixing CVEs is generally seen as harder than thus fixing CVEs. So the effect is ITAR (and similar laws) force you to fix CVEs.
Whatever you say, chief. I worked in that environment for quite a while, and maybe on a technicality you're right, the effect outcome is that you will do it if not for all your customers that will require it.
If by "terrible" you mean "amazing". Imagine being able to tear down an entire Jenga tower of bullshit corpospeak, and replace it with actual security.
It’s honestly not great. The security guys are completely exasperated at my job, we’re wasting time having with these. You take the scam really, investigate for a bit, write up a DNF with justification, they go and up date records, and we all just kinda hope that someone updates the scans so it stops showing up.
Something is going to give, and I suspect that the optimistic open filling is going to get canceled.
I think this will give a lot of ammunition for people on both sides, but the thing is we have made software so complex, ofc a lot of it is inherent, that we can't even tell if the vulnerability is hallucinated or not.
I find it getting closer and closer to the nonsensical 50 page mathematical proofs built with computer assited tools, that been driving reason for abstract proof systems so that we can break down such complicated examples into something simpler that we can feed into a system to help us verify.
I feel like for some reason we have built the output machine before we could even build the actual output verification machine. And aren't ready to accept that we should all move towards building some kind of system to better help verify the "truth" produced by these AI systems.
I am now very convinced that human built and proven to work verification systems for LLM outputs are more important than ever, but I just don't see any company or team working towards it.
Trillion dollar systems shipping to production code that is hardly understood by any one without any verification what really could go wrong. Honestly I really truly hope nothing goes wrong.
To note I am not anti-AI but I want to be able to have my LLM outputs be verified by more than just me under a tighter and tighter deadlines, accepting worse and worse slop just because it would less cost to me to accept the PR and then fix it in prod.
LLMs aren't sustainable software development, they are delusional slop factories if we aren't able to actually make sure the outputs have any amount of correctness.
With humans it worked because all 10 of us could in some ways verify each others outputs, and had trust in the fact that our timelines included the time for reviews.
nonexistent functions being referenced is pretty bad, I haven’t had that issue since like opus 4. Shows either complete lack of oversight and/or using a bargain basement model (so no even having financial skin in the game). Most likely both
> The cited code didn't even exist in those versions or referenced unrelated logic.
> When testing the PoC payloads they didn’t work (not triggering any crash).
I think the future is pretty obvious, if this isn't being done on projects already: you need to automate these checks and reject automatically
LLM: You're absolutely right. I didn't actually run the check. Good catch! One sec let me do that now... yep I ran the check and it definitely repro'd this time.
Could be just me but I would be quite careful running these PoC's, especially since the CVE's mostly seem nonsensical. I suppose these CVE's could be targeting some kind of PoC execution instead of actual bug reporting? (I didn't look at the code in depth).
Why is the repo even mixing CVE's for "schreibfaul1 ESP32-audioI2S" and "SQLite"? Is mixing CVE's for different products in one repo common practice?
There is no specific practice for a repo full of bug reports. Having a repo full of bug reports is already unusual. Normally you report a bug against the software that has a bug, not by creating a file in your own repo.
I've created bug reports to open source projects that have related files in my repo. Then I can just list the reproduction instructions like:
1) arrange xxx, such that yyy.. or git clone this repo where this is set up.
2) ..
I thought that might have been quite helpful not just to the person I'm sending the bug report to, but also to myself when I need to evaluate if the bug has been fixed.
> Over the past few days, a newly created GitHub repo (programmervuln/cveadvisory-) published a batch of SQLite vulnerability advisories (as part of other 50+ CVEs which we believe are also LLM slop except from one). NVD quickly flagged these as critical, and CISA's ADP agreed.
These two sentences seem incompatible to me. A brand new actor can just say some stuff and cause major disruptions in this way?
As a non-expert in this field, I feel we have introduced more “stochasticity”. Before, We had to deal with some human error/ misunderstanding for most part but now we have to deal with power of condensed human expertise along with homogenized flaws.
Thankfully I’m seeing other people mention that this article itself seems AI-generated. While there's less proof, i suspect that the actual analysis was done by an llm as well. So while i like to dunk on hallucinations as much as the next guy, who's to say this analysis doesnt have them too?
(for the record, i think the cve's are probably bogus, i just think there's an inherent problem with debunking slop with slop)
We need to further emphasize the importance of responsibility when using LLM tools to produce output for others. It's great to use them for refactoring and bug discovery, but keep in mind that it's your responsibility to analyze it and iterate on it with AI. It makes your code better and develops technical expertise.
The "Hey, analyze that codebase, find all dangerous CVEs, and write a README for the PoCs, so I can post it online for others to analyze, and if I'm lucky, I'll get a paycheck or a title to add to my resumé" approach might work in 0.1% of cases, but it will generate a ton of slop for the community to drown in.
I also think GPTZero and other AI detectors have far more false positives than correct guesses. I tried it on several texts & messages I wrote before 2019, and it flagged them as 80% AI-generated.
In that case, it's reasonable to assume that AI also generated the README text for each discovered CVE. In other cases, however, we should be more cautious.
> All advisories in this repo seem AI generated when testing them with Gptzero
I pasted this blog post from "Analysis Matrix" to the end in Gptzero, and it also says the blog post was AI-generated (71% chance of AI, 29% chance of AI-Human mix).
There should be some sort of defamation lawsuit possible when people publicly publish trash repos or reports like this. If you were writing a competing product in a safe language you’d love to see such FUD.
The comment is making fun of a Claude-ism where it becomes super “honest” about stuff.
It’s a joke but there is an underlying real effect where this type of language is psychologically manipulative and I would guess makes people believe LLMs output more than if it didn’t use “honest” (or “load bearing” or whatever super serious important sounding word).
Or maybe they didn't train it that way to be manipulative (although it's certainly a plausible explanation) but simply as an accidental artifact of trying to make it give honest answers?
LLM-generated images sometimes includes text from the prompt as literal text in the image, so perhaps this is the same sort of artifact? If they've told it to be honest, it responds by talking about being honest instead of actually being honest, because it has no actual understanding of anything.
We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are.
LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are dealing with probabilities in a situation where certainties, not probabilities, matter, you’re going to get dinged on credibility massively when your LLM-based “AI” gets the probabilities wrong at best, or in this case, claims a line of code generates a vulnerability when it is, in fact, a code comment.
LLMs are text-prediction engines. They are not Artificial Intelligence, and shouldn’t not be treated in any form or fashion as if they possess intelligence. What bothers me about this entire situation is that presumably the folks that relied on the LLM-based “AI” to generate these vulnerabilities knew (or should have known) enough about their tool to know this would happen, but did not.
Now, we all pay the consequence, to the tune of hundreds of thousands if not millions of dollars of wasted productivity from teams that have to deal with the resulting fall-out of this usage of “AI”.
A human must verify everything an LLM presents as fact. Everything. If you don’t, we all pay the price. LLMs do not remove the onus of responsibility on the human being, if anything they amplify it because LLMs can generate lots more output more quickly that needs to be verified than humans can.
Many people with no skills are taking advantage of the LLM craze to artificially inflate their own value. I see it every day on LinkedIn.
People that previously have barely any experience in tech, now being hired in AI startups because they are good bullshitters.
Countless directors and managers are now cosplaying as engineers. I've seen so many myself and that's just my tiny slice of this engineering world
Unfortunately people sometimes get defensive against this take. But I think treating the LLM as you described can make you a better LLM user and help get better output. It helps understand the failure modes better, and moderate one’s reliance on them. Just like how we should do for every tool we work with.
Yes, I've found that reminding yourself of how they actually work helps keep you on guard against LLM-patterned mistakes. Especially things like carefully considering what parts of the current task likely fall outside the distribution of corpus + RL data (as much as that can be guessed).
This is the right conclusion for completely wrong reasons haha. I love hn.
Apophatic intelligence? "We don't know what intelligence is, but LLMs with CoT are certainly not it despite being Turing-complete."
Watching for unexpected failure modes is surely worth it.
Turing-completeness is a necessary pre-requisite for being able to fulfill the requirements of a Turing machine, nothing more. In the same way that cell division is a necessary condition for life, but cell division does not mean a given life form itself is sentient.
Intelligent life-forms can generate probabilistic outputs based on inputs, but being able to generate probabilistic outputs based on inputs is not what makes us intelligent.
> but being able to generate probabilistic outputs based on inputs is not what makes us intelligent.
???
Of course it is. The brain is mechanically not capable of doing anything other than that.
Do you believe the brain is something other than a bundle of probabilistic physical interactions? Or are brains not the source of what we call intelligence?
OK. A more pointed question. What do you know about intelligence that allows you to exclude LLMs with CoT from the category of intelligent systems with certainty?
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.
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
In the Spack package manager [1] we're trying to work around this with directives:
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
Also a buffer overflow in user space for a tool not serving internet traffic is not a big deal.
Reminds me of the time our “security” team fought with me for a year to fix an issue in a third-party dependency that was failing their scanners. The issue was only a problem for and intentionally left in to not break support for Internet Explorer 6 on Windows XP, neither of which anyone at the company had used in 10 years, and everyone using this software was on a Mac anyway.
My condolences to anyone who’s got to deal with all these slop-y CVEs on one side and brain dead security teams on the other.
same things happens with npm and CVEs, most of the ones that bubble up aren't even called in my application so are no applicable.
go lang has a scanner [0] which only shows issues when the code actually calls the effected functions.
[0] https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
Isn't the real difficulty in how vulnerabilities can be mixed? A given vulnerability might be extremely hard to execute, but very damaging. Another vulnerability might be easier to execute, but it can't do much. But if the second one can be used to trigger the first one, you then have attack surface area of the second vulnerability with the damage of the first one.
Even if some individual case can be shown to be safe from being combined, can we identify such cases with enough confidence to justify using it reduce severity warnings?
IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.
Thats not enough. This problem pops up everywhere people do CVE analysis. If a tertiary part of some library is hit by some arbitrary CVE, why should that affect the core functionality people actually use? If I use ChaCha20, and that's bundled in a library with md5.do I care that their md5 library has a vulnerability? No, not really.
If you keep driving the "seperate the packages" angle you end up with is-odd, and that not a nice play to be either.
Even more than that, a lot of vulnerabilities require untrusted input to exploit, but the library or executable is usually only used with trusted input. For example, suppose the chacha20 function had a vulnerability that was exploitable with a malicious secret key, but you only call it with your own, definitely not malicious, key. The vulnerability doesn't impact you, but your security policy might still require you to update. And no amount of splitting the package will help with that.
I have concluded that even though I won't use that key, I still want the issue fixed. You never know if the key I randomly choose next year is the vulnerable one. Worse, you never know if someone else won't make a bug that allows outsiders to select a key...
At least for native binaries it's not too hard to write a scanner that extracts symbols from the binaries and checks them against the symbol names of the vulnerable code. If the code is properly dead and got pruned by the linker, it cannot cause any problems.
Yes it can cause you troubles, even if you don't link to it. Just having a vulnerability scanner (incorrectly) flag it can cause you numerous problems.
Say you distribute your application to a customer and link against libzip, and that customer points to the minizip 8.8 CVE above and says "if you don't fix this vulnerability our scanner is flagging, we are required to stop using your product", that'll cause you plenty of problems even though you don't use nor provide any way to reach the vulnerable code.
That sort of blind CVE adherence is so common in the industry that it's usually easier to do meaningless updates than fight back.
They should be in separate packages so you won't force yourself to patch CVEs in the parts you don't use?
But could an attacker with access to zip tools exploit it to get a root shell? Probably not, but maybe.
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.
I think this presents a highly fascinating scenario:
1. A vulnerability that presents itself very rarely
2. If it presents itself, it is fatal to the organization
So, few targets are affected, but the outsized effect means that the overall economic impact is not insignificant. How does one keep track of that?
One method is to use a sort of "kirchhoff's law" approach, similar to google page rank. The electrical analogy would be:
- the attacker has a high potential, let's say 1000V. that attacker is the root of a rose tree, going from top to bottom, branching out towards the bottom.
- nodes impossible to exploit present edges with infinite resistance
- nodes that can be exploited present finite resistance (perhaps very low)
- once a node is exploited, its node branches out to other things that now become accessible and may or may not be exploited
- real economic impact presents a connection to ground, measured as 1/($economic impact) ohms resistance
Once you have a structure like that, you can measure the hypothetical current that would be flowing, and measure the severity of such exploits.
Sometimes a single path through a complex system can blow up vital, important parts, and this could be one way to measure it in some sort of objective manner.
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
You do not run it as root, all you get is the possibility to crash or execute code. Nodes that handle such things are all heavily locked down.
>all you get is the possibility to [...] execute code
Anyone who's ever done even a beginner CTF knows that achieving code execution is a big deal.
reminds me of the cvss scoring system. that thing is great at telling a story. for better or worse XD.
If the solution was to remove an unused dependency, I think this CVE isn't silly at all.
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.
That's the worst case scenario right there: so many fake reports that the real vulnerabilities can no longer be reported properly and fixed quickly. Assuming some LLMs really are capable of finding serious vulnerabilities (which in my experience is absolutely the case : just let a good model run on your security code base and see for yourself) that means that we can more easily find vulnerabilities, but it's much harder to report them and be taken seriously - so the incentive to exploit such vulnerabilities instead has become much, much higher.
Yes. This was the case long before LLMs sprayed the tire fire with gasoline. See e.g. this 2021 gem from Dan Abramov (React's creator) https://overreacted.io/npm-audit-broken-by-design/
> The vast majority of CVEs are not exploitable, basically noise.
This is not true if you consider security-in-depth. Many of them are exploitable on their own but maybe not in combination with other issues that are as yet unknown or known but not patched everywhere.
As a simple example a local privilege escalation issue that is not exploitable on a device that only I ever have access to, essentially becomes a remote root access flaw if you have untrusted or unreliable users (clients with accounts for instance) on the system. This works on a finer grain too, seemingly minor issues spread through the kernel and user space can add up to a serious exploit.
This is the most common "not exploitable" CVE I have to deal with at work all the time. Things like buffer overruns when passing headers, but my server shouldn't be accessible to the public Internet anyway, and if it is, then we have much bigger problems. So yes it's technically exploitable IF other safeguards fail, but the reason it's irrelevant is that if those other safeguards fail, we are in deep shit anyway.
Or you can just fix the issue that way if IT screws up you are not vulnerable. Or maybe next year you will decide it is useful to connect to the internet.
But if you have proper risk-based vulnerability management, you should already have classified that CVE as a lesser priority. This is something that modern LLMs should in theory make a lot easier, although I’m unsure if workflows exist to continuously build a proper architectural understanding of your systems, at least at a feasible cost.
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.
> I suspect the repo in question was generated with a year-old LLM
I suspect there are a lot of people running inexpensive models that are searching for vulnerabilities across a lot of projects, probably in an automated way (ex with openclaw or similar) in the hopes of winning a bounty and/or noteriety.
Most bounty programs are aware of this. Many projects have closed their bounty program in response to that type of attack.
CVE-2026-4I5109 - Your kitchen drawer contains forks, which can maim and/or kill. An attacker with kitchen access could access the drawer. See...
CVE-1972-404: The code is written in C. ^_^
>The vast majority of CVEs are not exploitable
Perhaps in isolation. The issue is when you can chain exploits to bypass multiple layers.
Not exploitable, or not exploitable in isolation?
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.
Are you trying to say LLM’s are tuned to only discover unexploitable bugs?
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.
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.
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.
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.
CVEs sucked even before LLMs. CVSS is an ass-covering exercise, not an importance signal. Everything is "critical" all the time.
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.
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-...
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.
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.
I'm sure if somebody hired him for a pentest it'd cost more per vulnerability found.
I think his point was more that he didn't believe it was difficult to find these issues.
Could be Dunning-Kruger, but if AI models continue to get better this trend will surely continue.
1. George Hotz exhibits strong signs of Dunning-Kruger in most things he does nowadays.
2. Even in exploit development, his original field, he might be able to find vulnerabilities in mature, well-maintained software with security programs. But would he charge $20k or more for that service? Say it with me, Claude: “Absolutely!”
Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.
That is exactly why many big projects are migrating to becoming CNA, so that randos can’t get assigned unqualified CVEs which nobody has looked at or validated.
Apparently RedHat is a CNA of last resort, so it might be possible to get your project under Redhat’s scope and go through them without having to be a CNA yourself.
What are the requirements to become a CNA?
This is what the Linux kernel is currently attempting since becoming a CNA. edit: "This" being to sabotage the CVE system via DoS, to be clear.
What do you mean? It isn't a DoS to assign every single bug fix a CVE! Every single bug is making someone vulnerable in some way.
That's nonsense. The goal is and always has been to undermine the CVE system because Greg does not believe in the system. The kernel is the only project that marks CVEs to fixes, it's the only project that considers every bug to be a "Security" bug, and it has a multi-decades long history of telling the security world to fuck off - all consistent with what I've said.
No one else has the process that the kernel has, despite plenty of people having software that's deployed in very similar ways.
There's zero question - this is ideologically motivated, not a genuine good-faith attempt to leverage the system.
Or maybe it's ideologically motivated that other groups only identify certain bugs as security bugs?
Make a case then. My case is that Greg has, for decades, said that he hates the CVE system and rejected it and that the kernel objectively labels CVEs based on fixes (not the standard at all, CVEs are for vulns), etc. I can point to so many objective pieces of evidence to support my claim.
You seem to have a vague, leading question. If you want to say something about "other groups" or ideologies, go ahead.
> What do you mean?
No analysis is being done in the linux kernel to assess vulnerability.
> It isn't a DoS to assign every single bug fix a CVE!
On people who care about this, it is, not in the project itself though.
> Every single bug is making someone vulnerable in some way.
Not every bug is making someone vulnerable. (docs bugs, test bugs) behavioral changes, performance improvements, the list goes on.
It's been a problem for awhile. Daniel Stenberg has talked about it numerous times on his/curl's blog for the last 4 years. They became their own CNA to try and control it, they opened a hackerone with rewards, but now removed the rewards because it got flooded with AI generated slop daily.
https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/ https://daniel.haxx.se/blog/2025/04/24/how-the-cna-thing-is-...
And this year, some of the reports suddenly got good and meaningful. https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/
So the agents started doing something useful after a period of filling mailing lists and bug bounties with slop. Sound good, but that's not entirely a good thing. The volume of good reports is a burden as well, and it's likely that long-lasting open source C/C++ projects have legitimate vulnerabilities unpatched. But we don't have any new maintainers, I think.
The real question is will [when will] these vulnerabilities get fixed faster than they can be found. LLMs are finding a lot of real bugs that have existed without being noticed for 20+ years. It is generally expected [hoped] that in a short time all those 20 year old bugs will be fixed and LLMs will settle down to just things introduced in the last month (or perhaps this pull request) and thus be manageable.
Won't an LLM, prompted for a CVE report, always hallucinate one even if it isn't there? Why would they "settle down"?
Two different points.
First, is there any reason they have to? The LLM makers are aware of this problem and doing things to stop it. Maybe they will start saying "I can't find anything". Already they refuse to provide some exploits.
Second, most people are not prompting for a CVE, they are asking to review and find issues if any. Which sometimes finds a CVE, but in my experience it sometimes does say "looks good".
This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?
One can hope that will put pressure on the industry to design a better system than CVEs. The signal noise ratio was already terrible before LLMs, I cannot imagine that will still be a meaningful system in 10y.
But I’m too cynical to not consider all the middlemen who benefit from the status quo
I'm very curious what organisations would have such a policy. I can't imagine it being viable for any size of org without significant self-deception (or banning the use of all open source at which point CVEs are moot anyway).
> I'm very curious what organisations would have such a policy.
I would humbly suggest any org of any size that has insurance cover that covers anything tech related (e.g. data loss/recovery, cyber etc.) has a very good look at the small print.
Over the last few years insurers have aggressively been adding "no vulnerability patch, no claim" exclusion clauses.
Yeah, policies like this are often not coming from engineering directly but often through other parts of the company like legal, or even sales from contract negotiations. Not that it's entirely comparable, but I was at AWS when the big log4j vulnerability happened, and the handling for it was not left up to individual engineering teams, which I don't think would surprise anyone.
At a large enough company, processes for handling things like security vulnerabilities will have a lot of stakeholders with incentives that are not necessarily perfectly aligned.
Many orgs (esp w ISO27000) have a vulnerability management policy that involves patching at least critical CVEs within a short timeline. Tools like trivvy make it possible to do the scans…
I've been in such an org, & I've led initiatives to set up automated detection at very large scale. We started by issuing tickets to teams to resolve CVEs within varying timelines - ranging from a 24hr fix to 6 months - connected to the CVSS score. It wasn't viable.
- Firstly, you quickly realise how irrelevant CVSS scores are - initiatives like First's EPSS are designed to fix this but they aren't there yet
- Secondly, you need to begin implementing localised heuristics to determine exploitable code paths. This has generally been incredibly difficult to do reliably - LLMs have started to make it easier, but it's expensive.
- Lastly, you need to factor in consideration of actionable remediation pathways. A dependency upgrade for critical infrastructure might contain breaking changes that take months to fix, or two competing CVEs might be present in interdependent versions of transitive dependencies in your sbom tree.
Most orgs aren't applying any of the above three filters to reduce their CVE remediation burden, & even if they are, it's still too high to make zero a viable target.
In reality, most orgs aren't doing comprehensive detection to begin with - if you haven't discovered all of your CVEs, your remediation burden is going to be a lot more manageable.
> - Firstly, you quickly realise how irrelevant CVSS scores are
Even if you factor in the environmental score? I realize it's a lot more work, but it basically allows you to tune the score to get any value you want.
Imagine a YAML parsing library that can cause an out-of-memory exception if you give it a YAML file greater than 3 megabytes.
If you're an online service where untrusted users can submit arbitrary YAML, and an out-of-memory exception is a severe problem, then it's severity 10.
If you're an online service that doesn't use yaml in any way, but your web framework bundled the library as a transitive dependency because yaml is one of their five supported configuration options, then it's severity 2.
The problem is figuring out which of those situations you're in takes a load of time - and the flow of CVEs is endless, as CVE numbers are given out like candy at halloween. Often it's quicker to just update to the latest version of the YAML library.
> Tools like trivvy make it possible to do the scans...
Only if you didn't rip trivvy out of your organisation when it had two supply chain compromises within a month of each other earlier this year
Yikes. Man, there’s a market opening for someone to redistribute open source projects with supply chain assurances!
I have been given a list by security. "We had an automated tool scan that machine. It reported these. Fix anything medium severity and above.
Never mind that some of them involved vulnerabilities in some part of the bluetooth stack (servers in our datacenter don't even have bluetooth). But they just didn't care
This does make some sense if it's considered a valid fix to document that you have verified that Bluetooth is disabled on the servers and therefore not vulnerable. But that assumes that the scanning tool can be told about this kind of fix, so that it stops warning about it, which I guess it might not.
If I remember correctly, we had to patch or provide justification for CVEs flagged by tools like AWS Inspector for SOC2 as well.
So you didn't have to patch all of them.
No, but if you don't patch them you need to convince an auditor that they are not a problem. Often patching is easier.
I'm working on such a problem now - we are using an old web browser (no longer supported) to show help on one system. That is web pages were generate internally, with no links elsewhere, and no provision for the user to enter a URL. It is still easier port to a newer supported browser than to convince the auditors that that we are not exploitable. Sure it is obvious that everything is internal and we won't write html that exploits bugs, but nobody wants to convince an auditor of that.
Any org large enough to have separated the people responsible for the security exposure of the organisation from the developers with familiarity of what's deployed is likely to have done exactly this.
The thing you have to remember is that CVEs can be a) scanned for without exerting mental effort, and b) counted.
SOC2 CC7.1 [1] requires a vulnerability scanner, findings tracked with tickets, assigned severities according to a documented risk-based system, severity-based SLAs for remediation, and that the SLAs mostly be complied with or have tracked exceptions.
However it doesn't mandate any particular SLA, or the details of how risks are to be evaluated.
Organisations get to write their own policy, and they don't need to commit to patching every CVE within 24 hours or anything like that.
[1] https://www.compliancebase.org/controls/soc-2/cc7-1
It's quite common in enterprisey environments.
For one thing, bigcorps in regulated areas like it a lot. They push hard to get it required by the regulations (in practice if not directly). Although it's quite inefficient, it becomes a regulatory moat. A cost they can bear that potential upstart competitors cannot.
It's more common than many think https://old.reddit.com/r/kubernetes/comments/1vb3x2c/where_a...
Many large organizations like banks have requirements like this and they solve it through a mix of automatic scanners, e.g. Trivvy, and self-deception as not all systems are actually scanned in any sufficiently large org.
> I'm very curious what organisations would have such a policy
Do you provide SOC2, HIPAA, GDPR, or similar certifications to your b2b customers? Then your tech stack undergoes an annual audit, and in your audit you will need to provide a paper trail for every single vulnerability in your stack.
In practice, this means that your audit compliance software (something like Vanta.com) is going to be setup to mandate every CVE in the whole stack is patched within SLA.
ITAR
ITAR has no such hard requirements. Might be some orgs that tell themselves they're attempting this under ITAR but they're not doing it in any comprehensive way.
The only thing within ITAR that I'm aware of concerning itself with software supply chain is SP 800-218 requirements & that's just a load of open-to-interpretation weasel words about having CVE detection & automations in place & some defined plans for reducing the number of vulns. Pretty sure that component of it is even eligible for self-assessment.
Yes and no. ITAR (and other laws like it) are self assessment and don't specifically say thing thing.
However your interpretation / self-assessment is subject to various reviews/audits. These days the reviewers are not going to be kind to someone who just says "not an issue", they will demand strong justification. Most organizations take the view that is is easier to fix all CVEs than try to pass audits.
Thus by the letter of the law you are correct. However to meet the letter of the law without fixing CVEs is generally seen as harder than thus fixing CVEs. So the effect is ITAR (and similar laws) force you to fix CVEs.
Whatever you say, chief. I worked in that environment for quite a while, and maybe on a technicality you're right, the effect outcome is that you will do it if not for all your customers that will require it.
This was my first thought, this could be terrible if used offensively.
The best defense I can imagine is to have an agent reproduce the issues before a human sees it, but even that will cost money.
If by "terrible" you mean "amazing". Imagine being able to tear down an entire Jenga tower of bullshit corpospeak, and replace it with actual security.
Steps to patch a hallucinated CVE:
It’s honestly not great. The security guys are completely exasperated at my job, we’re wasting time having with these. You take the scam really, investigate for a bit, write up a DNF with justification, they go and up date records, and we all just kinda hope that someone updates the scans so it stops showing up.
Something is going to give, and I suspect that the optimistic open filling is going to get canceled.
Those organizations will have to adapt to new reality, ie, that some CVEs are not real.
Nothing new about that
All organisations also have exceptions to policies. This one would be one
Yes, but getting an exception approved can be a huge pain in some places.
If you work with the government, you don’t really have this luxury
You'd be surprised...
Not really. LLMs can hallucinate the patches too :-)
Create the referenced but non-existent file and then fix it /s
I think this will give a lot of ammunition for people on both sides, but the thing is we have made software so complex, ofc a lot of it is inherent, that we can't even tell if the vulnerability is hallucinated or not.
I find it getting closer and closer to the nonsensical 50 page mathematical proofs built with computer assited tools, that been driving reason for abstract proof systems so that we can break down such complicated examples into something simpler that we can feed into a system to help us verify.
I feel like for some reason we have built the output machine before we could even build the actual output verification machine. And aren't ready to accept that we should all move towards building some kind of system to better help verify the "truth" produced by these AI systems.
I am now very convinced that human built and proven to work verification systems for LLM outputs are more important than ever, but I just don't see any company or team working towards it.
Trillion dollar systems shipping to production code that is hardly understood by any one without any verification what really could go wrong. Honestly I really truly hope nothing goes wrong.
To note I am not anti-AI but I want to be able to have my LLM outputs be verified by more than just me under a tighter and tighter deadlines, accepting worse and worse slop just because it would less cost to me to accept the PR and then fix it in prod.
LLMs aren't sustainable software development, they are delusional slop factories if we aren't able to actually make sure the outputs have any amount of correctness.
With humans it worked because all 10 of us could in some ways verify each others outputs, and had trust in the fact that our timelines included the time for reviews.
nonexistent functions being referenced is pretty bad, I haven’t had that issue since like opus 4. Shows either complete lack of oversight and/or using a bargain basement model (so no even having financial skin in the game). Most likely both
They couldn't even be bothered to use a non-AI image.
Taking security theatre to a whole new level.
Somewhat related: https://sqlite.org/cves.html
> The cited code didn't even exist in those versions or referenced unrelated logic. > When testing the PoC payloads they didn’t work (not triggering any crash).
I think the future is pretty obvious, if this isn't being done on projects already: you need to automate these checks and reject automatically
Great idea! We can use LLM to do this.
LLM: I ran the check and it repro'd
> Did you really?
LLM: You're absolutely right. I didn't actually run the check. Good catch! One sec let me do that now... yep I ran the check and it definitely repro'd this time.
> I hate my job
That is if it didn't completely delete the repo in the first place. Consider yourself lucky
Could be just me but I would be quite careful running these PoC's, especially since the CVE's mostly seem nonsensical. I suppose these CVE's could be targeting some kind of PoC execution instead of actual bug reporting? (I didn't look at the code in depth).
Why is the repo even mixing CVE's for "schreibfaul1 ESP32-audioI2S" and "SQLite"? Is mixing CVE's for different products in one repo common practice?
There is no specific practice for a repo full of bug reports. Having a repo full of bug reports is already unusual. Normally you report a bug against the software that has a bug, not by creating a file in your own repo.
I've created bug reports to open source projects that have related files in my repo. Then I can just list the reproduction instructions like:
1) arrange xxx, such that yyy.. or git clone this repo where this is set up. 2) ..
I thought that might have been quite helpful not just to the person I'm sending the bug report to, but also to myself when I need to evaluate if the bug has been fixed.
Damn, dunno why I've always assumed that if something gets a CVE, then some authority has reproduced and verified it.
Shouldn't it be CNA's job? Why would anything get a number if it hadn't been verified?
The current system is radically overwhelmed and has been seeing cuts over the last few years.
> then some authority has reproduced and verified it.
No, the system puts a lot of trust into the submitter.
> Over the past few days, a newly created GitHub repo (programmervuln/cveadvisory-) published a batch of SQLite vulnerability advisories (as part of other 50+ CVEs which we believe are also LLM slop except from one). NVD quickly flagged these as critical, and CISA's ADP agreed.
These two sentences seem incompatible to me. A brand new actor can just say some stuff and cause major disruptions in this way?
> This incident demonstrates a systemic issue with automated vulnerability ingestion
But they make X-Ray which does automated vulnerability indexing and matching dependencies to CVEs.
Llm are great at things that are repeatable. Otherwise they are just like us - great at believable bullshit… a sign of true intelligence
You're absolutely right...
It's not actually vulnerable.
You're absolutely right. I made a critical error. It's NOT vulnerable.
It' actually vulnerable.
You're absolutely right. I made a critical error. It IS vulnerable.
It's not actually vulnerable.
You're absolutely right. I made a critical error. It's NOT vulnerable.
Hilariously, this comment tripped the LLM writing filter and was auto-deaded. I vouched for it.
As a non-expert in this field, I feel we have introduced more “stochasticity”. Before, We had to deal with some human error/ misunderstanding for most part but now we have to deal with power of condensed human expertise along with homogenized flaws.
A critical rating on a vuln that doesn't exist is wild. The triage cost still lands on the maintainers.
Wild catch. This highlights just how critical precise dependency vetting is for core database engines.
Thankfully I’m seeing other people mention that this article itself seems AI-generated. While there's less proof, i suspect that the actual analysis was done by an llm as well. So while i like to dunk on hallucinations as much as the next guy, who's to say this analysis doesnt have them too?
(for the record, i think the cve's are probably bogus, i just think there's an inherent problem with debunking slop with slop)
Great article!
We need to further emphasize the importance of responsibility when using LLM tools to produce output for others. It's great to use them for refactoring and bug discovery, but keep in mind that it's your responsibility to analyze it and iterate on it with AI. It makes your code better and develops technical expertise.
The "Hey, analyze that codebase, find all dangerous CVEs, and write a README for the PoCs, so I can post it online for others to analyze, and if I'm lucky, I'll get a paycheck or a title to add to my resumé" approach might work in 0.1% of cases, but it will generate a ton of slop for the community to drown in.
I also think GPTZero and other AI detectors have far more false positives than correct guesses. I tried it on several texts & messages I wrote before 2019, and it flagged them as 80% AI-generated.
In that case, it's reasonable to assume that AI also generated the README text for each discovered CVE. In other cases, however, we should be more cautious.
Wild catch. This highlights just how critical precise dependency vetting is for core database engines."
In the mean time, my very real vulnerability reports are not even acknowledged because maintainers are busy handling this kind of nonsense.
> All advisories in this repo seem AI generated when testing them with Gptzero
I pasted this blog post from "Analysis Matrix" to the end in Gptzero, and it also says the blog post was AI-generated (71% chance of AI, 29% chance of AI-Human mix).
The irony of writing an article about slop reports and then defacing it with a giant unrelated slop image at the top.
I had the impression that the code review done and text formatting by the jfrog was mostly driven by Claude too..
just ran this article that ran a cve through gptzero.. through gptzero
-GPTZero AI Detection
-Model 4.8b
-We are moderately confident this text is a mix of AI and human
-63/88 Sentences likely AI generated
Sad days ahead.
I mean you didn’t even have to do that, you could tell just by the AI generated header image.
imagine being a maintainer and having to write "this code does not exist" in a CVE response
can anyone explain what value does the ai slop image at the top add to this blog post?
There should be some sort of defamation lawsuit possible when people publicly publish trash repos or reports like this. If you were writing a competing product in a safe language you’d love to see such FUD.
It might be possible, but we'll only find out if a lawsuit actually takes place.
Honest take, this is a critical CVE.
And for such a load-bearing infrastructure component, fixing this is not just imperative, it's urgent.
Scout's honor!
How so? All 6 of the CVEs covered in the article did not actually exist when investigated
The comment is making fun of a Claude-ism where it becomes super “honest” about stuff.
It’s a joke but there is an underlying real effect where this type of language is psychologically manipulative and I would guess makes people believe LLMs output more than if it didn’t use “honest” (or “load bearing” or whatever super serious important sounding word).
Or maybe they didn't train it that way to be manipulative (although it's certainly a plausible explanation) but simply as an accidental artifact of trying to make it give honest answers?
LLM-generated images sometimes includes text from the prompt as literal text in the image, so perhaps this is the same sort of artifact? If they've told it to be honest, it responds by talking about being honest instead of actually being honest, because it has no actual understanding of anything.
The whole RLHF process is structured to train models to be manipulative, no matter what you thought you were training them for.
> accidental artifact of trying to make it give honest answers?
If it's not giving honest answers that implies it's purposely being deceitful, which it isn't capable of. Right?
You're absolutely right, I have hallucinated this. Would you like to find some real CVEs next?