Hacker News Reader

Comment by JumpCrisscross | Hacker News Reader

> people were already diffing kernel commits and figuring out which ones were security fixes

With skill, and usually not consistently and systematically. With AI, anyone can do this to any software.

> not sure shorter embargoes really help

Why 90 days versus 2 years? The author is arguing the factors that set that balance have shifted, given the frequency of simultaneous discovery. The embargo window isn’t an actual window, just an illusion, if the exploit is going to be found by several people outside the embargo anyway.

> cheaper exploit generation probably makes coordinated disclosure more important

I agree. But it also makes it less viable. If script kiddies can find and exploit zero days, the capacity to co-ordinate breaks down.

There was always a guild ethic that drove white-hate (EDIT: hat) culture. If the guild is broken, the ethic has nothing to stand on.

View on HN

> With skill, and usually not consistently and systematically.

How do you know? If the people who like to crow about vulnerabilities aren't doing it, it doesn't mean that the people who are actually in a position to exploit them systematically and effectively aren't doing it.

Those embargoes have always been dangerous, because they create a false sense of security. But, as you point out...

> With AI, anyone can do this to any software.

Yep. Even if it hadn't been true before, it's clear that now you just have to assume that everybody relevant will immediately recognize the security impact of any patch that gets published. That includes both bugs fixed and bugs introduced.

... and as the AI gets better, you're going to have to assume that you don't even have to publish a patch. Or source code. Within way less time than it's going to take people to admit it and adjust, any vulnerability in any software available for inspection is going to be instant public knowledge. Or at least public among anybody who matters.

>any vulnerability in any software available for inspection is going to be instant public knowledge. Or at least public among anybody who matters.

Shouldn't this naturally lead to a state where all (new) code is vulnerability-free? If AI vulnerability detection friction becomes low enough it'll become common/forced practice to pre-scan code.

Finding a vulnerability by looking at the diff that fixed it is very different than just looking through the code.

They're saying to do that scan to every diff before release, to see if it finds anything.

I believe their point was that:

"How likely is this diff a patch for an existing vulnerability?"

Seems to be an easier question to answer than

"Are there any new vulnerabilities introduced by this diff?"

In other words identifying that a patch is for a vulnerability is typically easier than finding the vulnerability in the first place.

If the diff will just be fed to LLMs regardless then what is easier is probably a moot point.

The point is that even if all code commits are scanned as safe by ai, black hats can still analyse the commits and diffs to find vulnerabilites for people who havent patched yet.

Scanning every commit doesnt automatically make everyone in the world patch immediately, vulns can still be found from commits and diffs and used against those who havent patched yet.

Look at GP to my comment again, the one I was clarifying: they're not talking about black hats or any other kind of hacker, they're talking about the original developers and preventing such vulnerabilities from existing in the first place.

Yes I am aware, however that still does not stop anybody examining your commits and diffs to find vulnerabilities.

Do you assume ai will just stop at a certain level? Or is it possible that it will keep increasing in intelligence? If the latter, then isnt it possible that even if you are auto checking all your commits, next week a more advanced ai model might be released that finds vulns in your old commits, even though they were checked by (an inferior) ai?

Blinding saying that auto checking commits will make you safe from ai based attacks and vulnerability free is just madness.

The diff yields the patched code which is used to produce the exploit.

> it'll become common/forced practice to pre-scan code.

You'd think.

But then you'd think people would do a lot of other things too. I hope, I guess.

The other danger is that "the cloud" may become even more overwhelmingly dominant. Which of course has its own large security costs.

Remeber (to you both) extrapolation is a perilous business.

Obligatory xkcd https://xkcd.com/605/

> How do you know?

We know because we could see the effects of the average rate of vulnerabilities discovery and exploitation, and it's definitely going up very fast. Until recently, vulnerabilities were relatively hard to find, and finding them was done by a very restricted group of people world-wide, which made them quite valuable. Not any more.

That's correlation, not causation.

It could equally be argued that the AI slop that's being produced makes for a lot more vulnerabilities being shipped. The bigger target makes for the easier discovery.

But don't we know that some of the vulnerabilities being discovered predate ai coding?

Certainly, and some discoveries have been attributed to AI (I was reading that mozilla firefox were praising mythos recently)

But that's not accounting for all of the discoveries, not at all.

I've also seen the npm people talking about the surge in AI code overwhelming the ability to properly review what's being distributed, and a large number of vulnerabilities being attributed to that

It's likely varies enormously between projects. Linux remains extremely low in slop, and the vulnerabilities being fixed are quite old, so it's improving. Many vibe coded projects are very sloppy, and are adding a lot of vulnerabilities.

Total number of vulnerabilities likely goes up over time weighting all projects equally, but goes down over time weighting by usage.

Is there evidence serious vulnerabilities are the result of vibe coding already? I haven’t seen any so if you have some references, please share.

Security researcher Dor Zvi and his team at the cybersecurity firm he cofounded, RedAccess, analyzed thousands of vibe-coded web applications created using the AI software development tools Lovable, Replit, Base44, and Netlify and found more than 5,000 of them that had virtually no security or authentication of any kind. Many of these web apps allowed anyone who merely finds their web URL to access the apps and their data. Others had only trivial barriers to that access, such as requiring that a visitor sign in with any email address. Around 40 percent of the apps exposed sensitive data, Zvi says, including medical information, financial data, corporate presentations, and strategy documents, as well as detailed logs of customer conversations with chatbots.

https://www.wired.com/story/thousands-of-vibe-coded-apps-exp...

That’s quite different. Vibe coded apps are not normally even meant to be secure, it’s meant to be used by the creator only. Bad app security is not the same as a vulnerability. A vulnerability would be a library providing some functionality it claims is secure, but in reality it’s not.

These are very clearly vulnerabilities in the normal sense of the word, and if a security bug means that an app that was supposed to be only accessible to the creator is open to the world that's still quite bad (though the blast radius is small).

If you limit to vulnerabilities that get CVEs, however, https://vibe-radar-ten.vercel.app has 34 in March alone including https://www.sentinelone.com/vulnerability-database/cve-2025-...

I mean - you're spot on - which is why I'd be more inclined to ask for actual metrics rather than feels/vibes, and I'd be very clear that the information I was basing my thinking on has enormous pitfalls.

This is the basis for "correlation points to possibly fertile grounds for an investigation"

> That's correlation, not causation.

Pragmatically, correlation *is* evidence of causation in favour of the best explanation, until somebody finds a better explanation.

> It could equally be argued that the AI slop that's being produced makes for a lot more vulnerabilities being shipped.

This is also true, and does not exclude the other, because for the moment the vast majority of production software in the world (and therefore the bulk of enticing targets) was written before AI. If LLM software will become prevalent in commercial setups, then LLM-generated code will eventually become the majority of targets.

> Pragmatically, correlation is evidence of causation in favour of the best explanation, until somebody finds a better explanation.

Uh, no.

Correlation is only ever one thing - cause for investigation.

Everything based on correlation alone is speculation.

You can speculate all you like, I have zero issue with that, but that's best prefaced with "I guess"

edit: Science captures this perfectly, and people misunderstand this so fundamentally that there is a massive debate where people who think they are "pro science" argue this so badly with theists that they completely hoist themselves with their own petard.

Science uses the term "theory" because all of our understanding is based on "available data" - and science biggest contribution to humanity is that it accepts that the current/leading THEORY can and will be retracted if there is compelling data discovered that demonstrates a falsehood.

So - because I know this is coming - yes science is willing to accept some correlation - BUT it's labelled "theory" or "statistically significant" because science is clear that if other data arises then that idea will need to be revisited.

Very often you only have limited time for investigation and you have to act now. Action is almost always based on educated guesses.

You have moved from "We know" to "We have an educated guess" which is the right way to couch things.

However I wanted to also point out that relying only on educated guesses can lead us into a position where we are "papering over the cracks" or "addressing the symptoms", not the "underlying cause"

Yes, sometimes that's all that can be done, but, also, sometimes it can be more damaging than the cause itself (thinking in terms of the cause continuing to fester away, whilst we think it's 'solved')

> You have moved from "We know" to "We have an educated guess"

No. You kept blabbering about "science" when most uses of knowledge are not about science. The original topic was also definitely not "science": it was about having a reasonable opinion about whether, empirically, the rate of discovery of vulnerabilities is increasing or not.

Trying to reframe this as 'not science' after being caught on a logical fallacy doesn't change the record. You started with a definitive claim ('We know') to shut down a question. When challenged on the lack of causation, you pivoted to 'educated guesses.'

My point remains: if we misattribute the cause of the rising vulnerability rate (discovery vs. creation), our 'educated guesses' will lead to solutions that address the symptoms while the underlying problem continues to fester. Calling precision 'blabbering' is exactly how we end up with the 'false sense of security' mentioned earlier.

Exhibit A:

ragall 2 hours ago | root | parent | prev | next [–]

> How do you know?

Exhibit B:

ragall 2 hours ago | root | parent | next [–]

Very often you only have limited time for investigation and you have to act now. Action is almost always based on educated guesses. reply

> people were already diffing kernel commits and figuring out which ones were security fixes With skill, and usually not consistently and systematically. With AI, anyone can do this to any software.

I would like to see actual evidence of this, not.. vibes

I mean, this reeks of "Anyone is a Principal developer now" when the truth is there is still work to do.

“White-Hat”

I'm here for white-hate culture. You should, you should know better.

Reply on news.ycombinator.com