[dead]
AI is breaking two vulnerability cultures
171–180 of 188 posts
Re: AI is breaking two vulnerability cultures
#172Earlier quoted context omitted.
Choose to take an availability hit rather than risk a breach.
Presumably you also have positive downstream effects in mind: when "taking the availability hit" feels like more of a live choice, operators feel the pain of running insecure designs more. Do what you describe a couple times, and you'll naturally start thinking things like "dammit, we need to finally get away from shared kernels; this is insane", "maybe we should figure out a way to do this that doesn't involve runni…
"Taking an availability hit" is also an "in the limit" case that mostly serves to illustrate the falsity of "disclose or patch" as a binary. Much more commonly: a fully disclosed vulnerability arms systems teams with enough information to mitigate; pull kernel modules, change permissions, that sort of thing.
Re: AI is breaking two vulnerability cultures
#173Earlier quoted context omitted.
Reminder: the Ksplice patent expires October 1, 2028.
I don't think hot patching holds the same relevance it did in 2010. Much of today's workloads are containerized and run on roughly ephemeral nodes that can be switched out easily- K8s version upgrades force this more or less. We tent to run more and more of-the shelf hardware and worry less about individual node failures now. In-memory updates also not magic , and can be limited as they requires data structure semant…
That’s still a minor part of the overall Internet. Small orgs are still using traditional hosting which who knows how often are updated. I’ve seen clients sites running on managed servers that are a few major versions behind.
Re: AI is breaking two vulnerability cultures
#174Re: AI is breaking two vulnerability cultures
#175Earlier quoted context omitted.
Presumably you also have positive downstream effects in mind: when "taking the availability hit" feels like more of a live choice, operators feel the pain of running insecure designs more. Do what you describe a couple times, and you'll naturally start thinking things like "dammit, we need to finally get away from shared kernels; this is insane", "maybe we should figure out a way to do this that doesn't involve runni…
"Taking an availability hit" is also an "in the limit" case that mostly serves to illustrate the falsity of "disclose or patch" as a binary. Much more commonly: a fully disclosed vulnerability arms systems teams with enough information to mitigate; pull kernel modules, change permissions, that sort of thing.
Maybe some corporations like the "just patch" playbook because it takes less skill to execute or articulate. It might be as much a deprofessionalizarion/commoditization of labor thing as much as anything else.
Re: AI is breaking two vulnerability cultures
#176Earlier quoted context omitted.
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…
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-...
Re: AI is breaking two vulnerability cultures
#177Earlier quoted context omitted.
Right, all I'm saying is that we were asymptotically close many years ago; all that's changed is that nobody can kid themselves about it anymore. The actual policy responses to it, I couldn't say! I've always believed, even when there was a meaningful gap between patching and disclosing, that coordinated disclosure norms were a bad default .
What process or mechanism would you prefer to use instead of coordinated disclosure?
I guess people could download (but not install) encrypted patches with an announced key release date+time, so that by the moment it is disclosed essentially everyone is applying the patch.
Re: AI is breaking two vulnerability cultures
#178One issue with the author's suggestion that AI makes it faster for defenders: the issue was never time to fix, but time to distribute.
My employer is working on a fairly early and small AI platform. Performance issues and other bugs are found regularly. I can usually track it down and have it fixed within an hour. But it's not so easy to distribute that fix. New releases need to be made and there are other changes going into them. The while release needs to be tested (hopefully). We have to update our internal deployments and cloud deployments, which needs careful coordination. Our customers' on-premise deployments are even further behind, often several months.
It takes an hour to fix a bug but months for that fix to reach end users. AI doesn't make that faster.
Re: AI is breaking two vulnerability cultures
#179Earlier quoted context omitted.
Bulk rewrites of everything into Rust with AI assistance?
Rust is overly complex and difficult, Go is simpler and easier and has the memory protection people are obsessed with
Go is not suited for kernel development. Memory safety is not sufficient for the use cases where rust excels.
Re: AI is breaking two vulnerability cultures
#180Earlier quoted context omitted.
I don't think hot patching holds the same relevance it did in 2010. Much of today's workloads are containerized and run on roughly ephemeral nodes that can be switched out easily- K8s version upgrades force this more or less. We tent to run more and more of-the shelf hardware and worry less about individual node failures now. In-memory updates also not magic , and can be limited as they requires data structure semant…
That’s still a minor part of the overall Internet. Small orgs are still using traditional hosting which who knows how often are updated. I’ve seen clients sites running on managed servers that are a few major versions behind.
The small orgs using traditional hosting are not the workloads which would consider in-memory update paths ?
Typically when shops like this do scheduled updates they will happily announce downtime, it just not business critical to have zero planned downtime and also lack the skill / budget to evaluate if a given patch can be applied in-memory or not.
The overlap between those using simper setups you say and those who need in-memory updates doesn't exist?