Summarizer

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 running software that runs in God mode", or even "we should see what it takes to port our application to a platform that is more secure by design". When you can't imagine or pretend that when a major vuln is disclosed (a) you've been secure up until the point of disclosure or (b) all you need to do now is apply a patch without thinking too much about what your blast radius just was, you might actually have stronger incentives to think about the design of the overall system so that when similar issues come up, you can avoid having to sweat those outages. It's interesting that "defense-in-depth" gets cited and repeated all the time but the standard attitude about patching still seems to be "what do you mean?? isn't patching the only thing we can do?". How about designing systems so that you can more quickly and easily throw up other kinds of mitigations when you need to? What about designing systems with robust enough notions of graceful degradation that when something crops up for a certain feature you can "just" say "okay, let's turn only that part off for a couple days"? How about getting really, really good at CI/CD so you can more confidently add and deploy mitigations to your application code, or redeploy with a feature flag that lets you temporarily drop an unpatched-and-vulnerable dependency? If you can manage to build a system without the assumption that just patching is always on the table, you might simply end up with better software , which would be pretty cool.

I’m with you until that last sentence, which I’ve been thinking about as “… until AI code testing, vulnerability scanning, and developer support tools help to limit the number of 0-days and vulnerabilities making it into production”. So prevention will be more important than ai-assisted rapid containment or patching, though both of those capabilities will be necessary as part of defense in depth. And some sort of AI-enabled security analysis across the organization’s architecture that is done as part of testing ahead of new software entering production to ID potential vulnerabilities caused by configuration changes or upgrades that modify how systems interact with each other. I’ve been trying to guess the timeframe for seeing improved secure development, but I’m hoping it’s a bit closer to 6 months - 1 year given the speed of AI adoption and AI progression. May be closer to 3 years as you stated. In the meantime, is there more to be done than this (not in order)? - Patch COTS software - re-evaluate the scoring for previous vulnerabilities - set up up containment measures capabilities for systems that can’t be patched / high risk vendors - use frontier model vuln scanning and patching for home grown systems that may have more 0-days than COTS depending on the organization’s capability - limit the number of vendors / simplifying the tech stack. I’d be happy to hear how others are thinking about this.

we simply can't absolve ourselves of responsibility in input and expect a hardened output. It's ABSOLUTELY up to the engineers to have test harnesses and scenarios for testing, vulnerability scanning, etc. Just because we can move faster via prompts doesn't mean we neglect the SDLC. I think there's opportunity to reinvent the pipeline with AI powered tools to assist but the onus is still on the person to ensure they are deploying something that has been tested.

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

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.

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 semantics to not really change and can create its own class of issues/bugs including security ones. While am sure there are still use cases which dictate this type of update, the need is lot less than 15 years ago that the patent expiry will do much to the ecosystem.

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.

Means you wouldn't have to reboot to patch for security updates to the Linux kernel. Assuming someone does something with that.

Bulk rewrites of everything into Rust with AI assistance?

You could have a web of trust where Linux-using organizations each spend $x continuously scanning and patching their own dependencies with AI, and sending each other patches and scans.

> In the extreme I think there's a decent chance projects like Debian might have to radically overhaul or just shut down completely - the whole philosophy of slow and steady with old code just won't work. It may actually be the opposite. Debians steady and professional approach on shipping security patches with very little to no functional difference actually enables us to consider and work on automated, autonomous weekly or faster patches of the entire fleet. And once that's in place and trusted, emergency rollouts are very possible and easy. We have other projects that "move fast and break things" and ship whatever they want in whatever versions they want and those will require constant attention to ship any update for a security topic. These projects require constant human attention to work through their shenanigans to keep them up to date.

We need automated patch and release cycles. So far we've relied on incredibly slow manual processes to accept reports, investigate, verify, patch, and prepare releases. Releasing a fix often takes months. This is way too slow when attackers can just churn out new exploits in hours. We need to iterate on value chain bottlenecks to lower Mean Time To Patch . We should be able to turn around a bug report to a patched product ready for QA testing in 1 hour. Standardize/open source it, have the whole software supply chain use it (ex. Linux kernel -> distros -> products that use distros -> users). With AI there's no reason we can't do this, we're just slow.

On the other hand, automated fast rollouts leads to a crowdstrike type situation where you brick all the computers of the world immediately. Imo we are going to have to rely on more layers of security. Systems that are designed to be secure even in the presence of individual vulnerabilities. This has already been happening for a while on mobile platforms and game consoles. Even physical hardware designed to keep particular secrets /keys even from the kernel.

The crowdstrike situation wasn't due to fast rollouts, it was due to a total lack of testing. You can do fast rollouts, with testing, and a mandatory QA signoff. It's called 'continuous delivery' rather than 'continuous deployment'. I actually don't think more layers of security will fix this. It would be nice if our systems were more secure... but people are, if nothing else, lazy af. Even when adding security isn't a lot of work, people resist it if it "sounds complicated". So I think we're stuck with the status quo. But the big issue now isn't novel bug types, it's the speed in which they're found. Therefore we need to speed up our response.

Sounds like you're expecting the AI-based tools that are finding bugs to also provide fixes. I've been dealing with a bunch of AI-generated (or at least -assisted) vulnerability reports lately. In many cases the reports include proposed patches to fix the issues. It's been..... interesting. In many cases, the analysis provided in the report has been accurate and helpful. In some cases, the proposed patches have also been good, and we've accepted them with minimal or no changes. In other cases, despite finding a valid issue, and even providing a good analysis of the problem, the AI tool's suggested patch has been, quite simply, wrong. Careful review from somebody who really _understands_ the code -- and the wider context in which it is operating -- is still absolutely necessary. That's not always going to happen in an hour.

Yes, that's why I specified "patched product ready for QA testing". It speeds up the development cycle by making a first pass and ensuring it basically works before passing it to a developer for manual review and a QA tester to ensure the fix doesn't break anything else. Both dev and QA are still in the feedback loop and can make changes until it's ready for release

what could go wrong? :DDD imagine patching everything up automatically and it's a malware everything cooked

Maybe it is about time for Linux to get a real CD/CI and start using AI extensively. Not just for vulnerabilities, having a nice agents|skills|etc.md definitions would encourage new devs to contribute instead of dealing with an overworked maintener repeating the same thing for n time.