(gingerly raises head above parapet)
Historically, “we’ve” moved the bar in defense.
- Everything is now in the cloud, accessible 24/7 via APIs whose keys are stored in plaintext alongside code, or via preauthenticated sessions - Everything has ~40 dependencies, each of which has ~40 dependencies, etc, which, combined with a published CVE rate of 1 per 15 minutes (calendar year 2024), means that patching an enterprise before an attacker has an available exploit is expensive (and despite being “measurable”, is unlikely to actually stop an attacker, because CVEs are very much not the only bugs) - Because everything is online now, everyone’s identity is online now, at the very least in the form of historic data breaches (free creds!) - Flawless real-time imitation of humans is now very much a thing, while defences against these attacks are largely absent - Vibe coding is manufacturing vulnerability at faster-than-human speeds
“We’ve” definitely moved the bar. Just not in a direction that’s helpful for the defender.
Having an LLM as the intermediary for everything seems dubious to me. When you’re going downhill, reach for the brake, not the accelerator. LLMs can help though, if used to generate code judiciously within a well structured software engineering framework, where we trade velocity of code creation for greater assurance, for instance, using the LLMs to:
- Generate test cases for everything, integrate them into the pipeline and make sure they’re compulsory - Detect known-bad security patterns - Carry out variant analysis of known-bad security cases - Verify that logging and error handling code is solid - Always nudge toward reducing the amount of code, and reducing - rather than increasing - technical debt
Outside of being careful with the code generation, the LLMs can help with defensive analysis and providing challenge (e.g. they’re surprisingly helpful with threat modelling) and by creating the intermediaries you mentioned, provided (obvs) we’re very, very careful not to create confused deputies, vulnerable admin agents with “forever” admin creds, or “straddling” services that provide a helpful bridge for attackers between logical areas of the system (network, vpc, container/orchestration etc).
I think we’ve now settled to a point in our level of vulnerability where national governments are having to step in with regulation; ransomware is routine, an existential threat to companies and a matter of life and death for the public sector.
We (on this list) already know how to fix this, I think. The “old” defences work, with (imo) empowered, semi-automated vigilance being the best defence. LLMs give defenders strong advantages, but only if the talent, the money and the executive understanding is there. It mostly isn’t there.
I think the answer is societal, rather than technical. We know the technical answers, but they don’t stick, because of the perverse incentives.
This is why I’ve been moving toward regulation (along with others, looking at you Dan Cuthbert). It’s hard, dull, minimal, and takes ages, but it scales. The market will eventually catch up and surface all of this, but for now, we need hackers with clue contributing to the regulatory effort, to keep it reasonable and sane, while giving a measurable improvement. I think that’s how we move the bar in favour of defence, and thank you for coming to my TED talk.
-chris
On 15 Nov 2025, at 21:58, Dave Aitel via Dailydave dailydave@lists.aitelfoundation.org wrote:
How would one actually move the actual bar in defense? A big part of me thinks that you're just not going to patch your way out of the problem. But the number of organizations that you can rely on to actually make a difference seems pretty small? Like even converting every Linux binary to rust would only make sense if you could find a team that could actually maintain and support that code base, which I don't know that you could.
Like in a sense, what you have to do is completely rebuild how you're building software and have the large language model be the intermediary for everything?
Dave _______________________________________________ Dailydave mailing list -- dailydave@lists.aitelfoundation.org To unsubscribe send an email to dailydave-leave@lists.aitelfoundation.org