We covered Cloudflare’s EmDash project as an example of the kind of appsec future I’d like to see. EmDash is the “spiritual successor to WordPress” that has one very specific design choice that caught my eye – sandboxing plugins.

You can’t look at a WordPress plugin without tripping over an XSS, SQL injection, or RCE. Their vulns are ubiquitous and boring. I think we’ve only ever covered maybe two of them on the podcast. WordPress core is relatively secure, but that feels like faint praise when the core can’t protect itself from a plague of plugins with poor security.

Unlike WordPress, where plugins essentially execute unconstrained within the boundaries of the core, EmDash plugins must explicitly state the capabilities they need and are restricted to those capabilities. The article shows an example of a plugin that sends an email. That example highlights several positive security benefits:

• Plugin capabilities are static and inspectable at install time. They can’t dynamically modify themselves or mutate unexpectedly.
• Capabilities not declared are denied. It feels trite to use a phrase like, “Default deny is good” in 2026, but it’s effective and should be the expectation for any component that must have a security boundary.
• Capabilities are simple, expressive, and granular. There are eleven right now, with human-friendly names and the contexts they grant access to.

In WordPress, you have to go through a list of worries about every plugin. What does it actually do? What content, files, or tables does it touch? What network calls does it make? Answering those questions typically relies on grep and trust – the plugin’s reputation and popularity. And those questions need to be asked and answered on every point release considering that a trusted author’s account might be compromised to push a malicious update.

Ember doesn’t erase those concerns, but it definitely minimizes them. It’s much more confidence building to be able to inspect a manifest for “network:fetch” or “network:fetch:any”.

(As an aside, Cloudflare also explains how their Workers, built on top of V8 isolates, are designed for performance and security. That security design also makes them “resistant to the entire range of Spectre-style attacks”, which is another wonderful example of avoiding a vuln class altogether. What I appreciate most about that write-up is how it presents a threat model, then discusses the high-level architecture and processes used to address those threats.)

Of course, there’s some self-interest in Cloudflare creating a project like this. It highlights the security architecture they’ve invested in for their platform – which, obviously, I’m a fan of (this site runs on Cloudflare pages). EmDash also introduces first-class support for the new x402 standard for "internet-native payments." Given that x402 originated from Coinbase, its current state translates to microtransactions with blockchains and stablecoins.

But if financial transactions are going to be part of a CMS, I’d much rather see them on a platform with the plugin security design of EmDash rather than WordPress.

Oh, and yeah, I read through the article a few times to make sure it wasn’t an April Fools’ joke based on its publication date. It’s also coincidentally authored by two Matts – Matt “T.K” Taylor and Matt Kane. They’re not as famous as the Matt of Automattic that owns WordPress.com (the commercial side and contributor to the open-source wordpress.org, who took a quite antagonistic turn towards the open source ethos). I very much prefer the future of CMS design like what EmDash has done.

And that’s why I like EmDash as an example of the future of appsec. It doesn’t even have to be called appsec – and likely won’t. It’s secure software engineering. It’s a project that identified common security failures, evaluated solutions, and created a design that eliminated or minimized broad types of flaws.

I’d rather read this kind of architecture discussion than read about yet another XSS.

(Post adapted from the original one on LinkedIn.)

Agents and LLMs have gained favor as the method for finding flaws, but how would we measure their economics and efficiency against a decade of successful fuzzing? As methods for bug hunting, they're neither mutually exclusive nor so overlapping as to be redundant. So how would we design a process for deciding which one to run and when?

Fuzzing has had a great success! "As of May 2025, OSS-Fuzz has helped identify and fix over 13,000 vulnerabilities and 50,000 bugs across 1,000 projects."¹

I've always loved fuzzing as a way to find software quality problems. Some of those problems have security impacts, others are implementation mistakes. All of them are crashes that should be fixed. They have a high signal on the quality spectrum.

Megacycles and Megavolume

In the past six months or so, we've seen a big attention shift to LLMs finding flaws across open source projects from the Linux kernel to memory misuse in C-based projects to fun findings in Vim and Emacs. We've shifted from burning CPU cycles for fuzzing to burning GPU cycles for agents.

Clearly, the UX and onboarding steps to run an agent against a codebase is far superior to using a fuzzer – write a sentence or two and you're done. I'll never diminish the importance of UX for any tool, especially in security.

But it still makes me wonder about how to evaluate the economics and efficiency of running a fuzzer vs. an agent (or collection thereof) against a codebase. There's a one-time investment in instrumenting a project with a fuzzer, followed by much lower maintenance and letting it run. And the nature of fuzzing is more likely to trigger memory safety issues, although it still has the potential for other classes of vulns like path traversal and security boundaries with weak logic.

Megacost or Microexpense

Is there any research on cost comparisons of fuzzing vs. LLMs? Any good papers on token costs related to running agents as code reviewers? I've tracked a few articles about CTF-style research by agents that puts token costs at around ~$10 per run per file (with ~3-4 runs to guarantee a finding) and the average AIxCC costs at around $152 per competition task.

A critical step in an evaluation of efficiency would be to normalize that cost between agents and fuzzing. Using per repo is too coarse. Per file or per LOC might be better since it's more granular. But AIxCC's per task might be best in terms of findings, assuming that "task" can be sufficiently defined. It's also imporant to note that AIxCC had several mixed approaches, from "AI-first with traditional validation" to "systems rooted in fuzzing...and enhanced them with LLMs."²

I'd love to find any updated resources or references on this economic aspect of agents.³ Let me know where I should be looking!

Discovery vs. Analysis

I noted that fuzzers have high signal. If they cause an app to crash, that's a bug to be fixed. But that bug isn't necessarily one that impacts security (aside from the generic availability problem of crashing). LLMs, on the other hand, have the potential to craft an exploit for a bug. Having an exploit adds context that helps prioritize and better understand the consequences of a bug.

But here's where I'd also distinguish what audience is taking in that context and what action they expect to take. There's a difference between an org trying to figure out how to keep thousands of dependencies up to date and a project owner improving their own code quality. Not that project owners don't have their own priorities and time pressures, but sometimes a bug takes less time to fix than it does it thoroughly analyze it.

I'd rather development teams focus on fixing bugs and refactoring their architecture to reduce their attack surface and eliminate classes of vulns. Yet I begrudgingly acknowledge that security teams want some sort of analysis about bugs. Not that they always need such an analysis, but they sure seem to want them from CVEs.

Where I'll most closely watch the discovery vs. analysis distinction is in the Linux kernel. The kernel devs have a very specific attitude towards bugs:

...due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.

Criteria and Considerations

So after all this preamble, which one wins? What does it even mean to win? How do we design a process that's cost-effective and efficient with fuzzers and agents and tokens and processors?

I no longer toy with the hypothesis that fuzzing is cycle-for-cycle more cost-effective than agents at discovering bugs. It feels like the ship has sailed in terms of agents being embraced for security.

Thus, I'll combine discovery and analysis and reframe the question to, "What's a cost-effective method of identifying software quality issues?"

• What are the operator costs to establish and maintain a harness for fuzzing, for agents?
• What's the operator UX for using a fuzzer, an agent?
• What are the CPU costs to execute a fuzzer, an agent?
• What is the cost per LOC? Is LOC even a good denominator?
• What constraints detract from either approach's success? e.g. a fully compiling app for fuzzers vs. a single file (or even PR!?) for agents, code complexity that fuzzing is mostly agnostic to vs. context windows for agents, programming languages and compiled vs. interpreted languages

Notably, my personal criteria cares less about volume (although I do care about variety of vuln classes), because I want to avoid the trap of maximizing a CVE count. Chasing vulns without a strategy to avoid them is just BugOps.

Quality as Consequence

All of the previous criteria are about economics and efficiency of finding bugs. But my actual success criteria boils down to a simpler motivating question:

"What fosters better software design that improves code quality and reduces the prevalence of vuln classes?"

Finding bugs is important, exploiting them can be fun, but for me the most rewarding thing is preventing them in the first place.

(Post adapted from my original one on LinkedIn on April 6, 2026.)

March meandered through C code, mused about secure design, marked a new top ten list, made space for machines, and finally descended into a bit of madness. And every single moment was fun!

Modern AppSec That Keeps Pace with AI Development (ep. 372)

As more developers turn to LLMs to generate code, more appsec teams are turning to LLMs to conduct security code reviews. One of the biggest themes in all the discussion around LLMs, agents, and code is speed — more code created faster. And with that volume comes more vulns.

James Wickett shares why speed continues to pose a challenge to appsec teams and why that’s often because teams haven’t invested enough in foundational appsec principles.

One of the traps in appsec is getting caught up in the volume of security bugs and conflating an acceleration of finding and fixing those vulns with a security strategy. Proactive security that eradicates vuln classes (or makes them very hard to introduce) is always going to be more effective than eternally chasing individual bugs.

Making Medical Devices Secure (ep. 373)

Medical devices are a special segment of the IoT world where availability and patient safety are paramount. Tamil Mathi explains why many devices need to fail open — the opposite of what traditional appsec approaches might initially think — and what makes threat modeling these devices interesting and unique. He also covers how to get started in this space, from where to learn hardware hacking basics to reviewing firmware and moving up the stack to the application layer.

This is one of those episodes that highlights the breadth of industries that appsec covers and why context about the intention of features and the needs of users is so important to threat modeling. Having to design a device where availability is paramount and critical to patient safety requires different tradeoffs than reducing the latency and protecting payment credentials for an online purchase.

Creating Better Security Guidance and Code with LLMs (ep. 374)

What happens when secure coding guidance goes stale? What happens when LLMs write code from scratch? Mark Curphy walks us through his experience updating documentation for writing secure code in Go and recreating one of his own startups.

One of the themes of this conversation is how important documentation is, whether it's intended for humans or for prompts to LLMs. Importantly, LLMs don't innovate on their own – they rely on the data they're trained on. And that means there should be good authoritative sources for what secure code looks like. It also means that instructions to LLMs need to be clear and precise enough to produce something useful.

This was also fun because Mark did a live demo where he prompted an agent to recreate one of his startups – going from a $20 million investment to less than $50 in tokens!

Why Proactive Security Is Far Better Than Patching (ep. 375)

So much (too much!) of appsec’s efforts are consumed by vuln management and a race to patch security flaws. I see that as a symptom of the ease of scanning and the volume of CVEs. It’s something that’s easy to measure, both in finding and fixing, but easy to measure turns into an easy distraction. Erik Nost walks through the principles behind proactive security, why the concept sounds familiar to secure by design, and why organizations still struggle with creating effective practices for visibility.

I don’t think it’s a waste of time to find flaws in code, but I wish the appsec conversations were more heavily weighted towards identifying root causes and sharing software patterns for preventing those flaws in the first place. Which is basically saying we need better ways to emphasize and evaluate secure designs.

Developing the Skills Needed for Modern Software Development (ep. 376)

The future of secure software is going through a mix of skills expected of humans and skills files created for LLMs. We might even posit that appsec as a discipline will fade (and that might not even be a bad thing!). Keith Hoodlet describes the skills he was looking for in building teams of security researchers and why there's still an emphasis on the ability to learn about and understand how software is built.

But figuring out what skills will get you hired and what skills are valuable to invest in still feels daunting to new grads and others entering the security industry. We discuss where the role of appsec seems to be heading and a few of the security and software fundamentals that can help you follow that direction.

I’ve always wished that February was cybersecurity awareness month. It’s the shortest month, an inconsistent month, and a month with several pronunciations -– all the attributes of security guidance!

But it also has a day that celebrates love. Like a love for secure code.

So, whether you have a type, whether your love is constant or variable, and whatever language you use, don’t put your trust into some Zodiac star sign,

Base it on principles from secure by design.

Focusing on Proactive Controls in the Face of LLM-Assisted Malware (ep. 368)

Everyone is turning to LLMs to generate code, including attackers. Thus, it’s no great surprise that there are now examples of malware generated by LLMs. We discuss the implications of more malware with Rob Allen and what it means for orgs that want to protect themselves from ransomware.

This was a sponsored interview.

Bringing Strong Authentication and Granular Authorization To GenAI (ep. 369)

When it comes to agents and MCPs, the interesting security discussion isn’t that they need strong authentication and authorization, but what that authn/z story should look like. Where does it get implemented? Who implements it? What standards does it rely on? Dan Moore shares the useful parallels in securing APIs that should be brought into the world of MCPs — especially because so many of them are still interacting with APIs.

AppSec News about LLMs Writing & Analyzing Secure Code (ep. 370)

One premise of appsec is figuring out effective ways to answer, “What security flaws are in this code?”

The nature of the question doesn’t really change depending on who or what wrote the code. In other words, LLMs generating code really just means there’s mode code to secure. So, what about using LLMs to find security flaws? Just how effective and efficient are they?

We talked with Adrian Sanabria and John Kinsella about the latest appsec articles that show a range of results from finding memory corruption bugs in open source software to spending an inordinate amount of manual effort validating persuasive, but ultimately incorrect, security findings from an LLM.

Helping Users with Practical Advice to Protect their Digital Devices (ep. 371)

Journalists put a lot of effort into collecting information and protecting their sources, but everyone can benefit from having a digital environment that’s more secure and more privacy protecting.

Runa Sandvik shares her experience working with journalists and targeted groups to craft plans for how they use their devices and manage their information. She makes the point that the burden of security should not be just for users — platforms and software providers must be evaluating secure defaults and secure designs that improve protections for everyone.

It’s a new year! Which means more new intros, more discussions about the principles of secure design, and more coverage of how LLMs are changing what appsec means.

The Upsides and Downsides of LLM-Generated Code (ep. 364)

Developers are adding LLMs and agents to their code creation toolboxes, using them to assist with writing and reviewing code. Chris Wysopal talks about the security downsides of relying on LLMs and how appsec needs to adapt to dealing with a faster pace and higher volume of code to review.

Secure By Design Is Better Than Secure By Myth (ep. 365)

Not all infosec advice is helpful. Bad advice wastes time, makes people less secure, and takes focus away from making software more secure. Bob Lord talks about his efforts to tamp down hacklore — the security myths and mistakes that crop up in news stories and advice to users.

He talks about how these myths come about, why they’re harmful, and how they’re related to the necessity of building software that’s secure by design. Find out more about his efforts at Stop Hacklore!

The Week's Appsec News (ep. 366)

MongoBleed and a recent OWASP CRS bypass show how parsing problems remain a source of security flaws regardless of programming language. We talk with Kalyani Pawar about how these problems rank against the Top 25 CWEs for 2025 and what it means for relying on LLMs to generate code.

Supply Chain Security (ep. 367)

Supply chain security remains one of the biggest time sinks for appsec teams and developers, even making it onto the latest iteration of the OWASP Top 10 list. Paul Davis shares strategies to proactively defend your environment from the types of attacks that target supply chains and package dependencies.

We also discuss how to gain time back by being smarter about how to manage packages and where the responsibility for managing the security of packages should be.