This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?
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).
SQLite Critical CVEs or LLM Slop?
41–50 of 406 posts
Re: SQLite Critical CVEs or LLM Slop?
#42Earlier quoted context omitted.
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 - Second…
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.
Re: SQLite Critical CVEs or LLM Slop?
#43The irony of writing an article about slop reports and then defacing it with a giant unrelated slop image at the top.
Re: SQLite Critical CVEs or LLM Slop?
#44Re: SQLite Critical CVEs or LLM Slop?
#45Re: SQLite Critical CVEs or LLM Slop?
#46Re: SQLite Critical CVEs or LLM Slop?
#47Earlier quoted context omitted.
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).
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…
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
Re: SQLite Critical CVEs or LLM Slop?
#48Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.
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://da…
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.
Re: SQLite Critical CVEs or LLM Slop?
#49[flagged]
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.
Re: SQLite Critical CVEs or LLM Slop?
#50Honest take, this is a critical CVE.
How so? All 6 of the CVEs covered in the article did not actually exist when investigated
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).