[dead]
SQLite Critical CVEs or LLM Slop?
201–210 of 407 posts
Re: SQLite Critical CVEs or LLM Slop?
#202We 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 credi…
Every day I wake up and open HN. “LLM has made legitimate mathematical discoveries” —> Wow the rate of progress is amazing. Highly upvoted. “LLM does something not good” -> Does everyone else not realize LLMs are just dumb next token predictors? Highly upvoted. So tired of this discourse and this site.
Would be nice to get high karma commenter votes count only ..
Re: SQLite Critical CVEs or LLM Slop?
#203Earlier quoted context omitted.
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?
How do you know there's not a teapot orbiting the sun?
You’re right to point that out. The load-bearing seam of your logical retort is the hidden assumption that the teapot is in outer space, not at peace on a kitchen stovetop here on earth. I am sorry I had not considered this fact. \s
Re: SQLite Critical CVEs or LLM Slop?
#204[flagged]
Re: SQLite Critical CVEs or LLM Slop?
#205So a so-called vulnerability has:
- cited code not exist, and
- PoC not work.
How would any serious system allow it become a big deal?
Re: SQLite Critical CVEs or LLM Slop?
#206Earlier quoted context omitted.
> 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…
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.
This sounds like a piss poor implementation of zero trust on your part.
Security is an onion, you have lots of layers because layers peel off and fail all the time. With your current setup a single foothold gives an attacker all the lateral movement they need for full exploitation of every single thing you own blowing past the other layers.
Re: SQLite Critical CVEs or LLM Slop?
#207We 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 credi…
We can chalk this up as another example of over-exhuberance by what folks believe humans can accomplish vs. what they actually are.
Flesh-based “brain” 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 flesh-based brain 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.
Humans are prediction engines. They are not Pure Intelligence, and shouldn’t not be treated in any form or fashion as if they possess pure intelligence. What bothers me about this entire situation is that presumably the folks that have relied on the flesh-based “brains” to generate these vulnerabilities knew (or should have known) enough about their "tool" to know this would happen, but did not: To err is to be human.
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 over reliance on fallible “brains".
A human must verify everything another human presents as fact. Everything. If you don’t, we all pay the price. Using a human does not remove the onus of responsibility on the human being in charge, if anything they amplify it because humans work for peanuts in some countries, and can generate lots more output more quickly that needs to be verified by the humans in charge.
Re: SQLite Critical CVEs or LLM Slop?
#208We 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 credi…
[flagged]
[deleted]
Re: SQLite Critical CVEs or LLM Slop?
#209Earlier quoted context omitted.
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"…
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…
>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.
Re: SQLite Critical CVEs or LLM Slop?
#210We 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 credi…
> 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”. Brandolini's principle in action. It takes 10 times more energy to refute BS than to generate it. A related analogy to computing: it is easy to generate propositions, but hard to test if a given proposition is satisfia…
> Brandolini's principle
I much prefer the alternative name: the Bullshit Asymmetry Principle.