June brings us the summer solstice, leading to shorter days and longer nights.

There’s also an appsec solstice, except things just get longer – lists of CVEs, top ten lists, lists of JavaScript frameworks, lists of AI frameworks.

And the only kinds of days that get shorter are the number that appsec requires for patching vulns.

Maybe we spend too much time chasing bugs in the dark instead of illuminating better designs.

BadHost, Dead CTFs, Exploding NPMs, and the Verizon DBIR (ep. 385)

We kick off the month with an episode dedicated to appsec news since we ran so many interviews from RSAC at the end of May.

Kalyani Pawar stops by to talk about the parsing problems that led to the BadHost vuln, which exposed tons of LLMs, MCPs, and agents to potential compromise. Then we wonder where to look for security education and practice as more and more LLMs infiltrate the camaraderie of the CTF community.

We talk about the tradeoffs in trust between using public packages vs. having agents write replacements from scratch. In other words, do you reuse an open source solution that’s already addressed your needs? Or do you burn tokens to re-implement a solution from scratch? The situation isn’t quite that dichotomy of decisions, but so many people are looking for excuses to have agents write code that avoiding packages has been a topic of conversation.

Finally, we examine a few appsec details from the Verizon DBIR that reveal how attackers are compromising orgs – and how orgs should use that information to protect themselves.

Scanner Results Are a Starting Point. Here's What Comes Next. (ep. 386)

Most AppSec teams are working through more findings than their teams can validate. But that already feels like a losing proposition and a bad strategy, especially when dealing with dependencies. It’s just a form of BugOps – chasing CVEs because they’re a quantity that can be tracked and reduced.

Somewhere in that process are a few vulns worth worrying about, the ones that are actually exploitable in production with consequences you should care about. This conversation with Federico Kirschbaum explores why automated testing often stops short of the hardest part of the job: proving priority.

We dig into how business logic flaws and authorization vulnerabilities get missed by tools that scan without reasoning, what exploit validation looks like at runtime, and how security engineers are (slowly) preferring to filter findings to those that developers should actually act on.

The segment is sponsored by XBOW.

Why Does It Matter Who or What Created the Code? (ep. 387)

Agents and LLMs are creating and reviewing code. They're a new tool to help developers write software and they're a new abstraction layer for expressing what code should do.

But if we're focused on determining whether code is secure, where do we focus our attention on ensuring a secure outcome?

Matias Madou talks about the challenges of finding metrics and developing benchmarks to help answer these questions. We walk through many of the questions we'd like to see answered and our desire to see appsec finally shift out of a BugOps-style find-and-fix mode into a future of secure design.

How AI Is Reshaping Identity Security at the Infrastructure Layer (ep. 388)

Appsec has seen machine identities from daemons and processes to services, microservices, and cloud accounts. And now we have agents.

Ev Kontsevoy talks about what it means to have engineers and agents interacting in an environment, and why a focus on actions is more effective than roles.

One of the biggest challenges in securing agents alongside all of the other identities that organizations manage is how fragmented that management has become. But a unified engineering view of identities is just a start. Once you're able to shift to a practice where access is granted based on attributes and limited durations, then your environment becomes more resilient to mistakes and unexpected actions, not to mention the security concerns that arise with agents acting on their own.

Reducing Attack Surface & Evaluating Efficiency in Agents (ep. 389)

Squidbleed reveals another vuln that's been lurking for decades, but its real lesson is in managing a codebase’s attack surface. Regardless of whatever programming language you use, removing code is one of the best security steps you can take, followed by changing default configs to turn off uncommon features and ancient protocols.

The Linux kernel's removal of strncpy is another example of managing attack surface by replacing a notoriously misused and ambiguous function with more specific versions that better match the developers intent. It was a six-year journey for the kernel, but one that should remove a class of vulns and, importantly, improve performance.

Then it's on to agents as Tyler Shields and I discuss the newly released OWASP AISVS and yet another example of evaluating LLMs as code reviewers.

The halting problem is a famous example of a decision problem in computing.

It asserts that, given a piece of software, it’s impossible to know if appsec will ever stop making checklists about it.

Keeping Up With the OWASP GenAI Project (ep. 381)

Speed is the most common theme among developers and appsec teams working with LLMs and agents, from trying to keep up with patterns for deploying agents to dealing with more code at a faster pace to how the latest models impact code quality and security. The OWASP GenAI Project is helping organizations keep up with these changes and engaging the appsec community for sharing effective ways to keep systems secure. Scott Clinton shares the latest progress on the project, its roadmap for the year, and how appsec practitioners can shape its future.

Why Basic Security Practices Still Work (ep. 382)

If you have to ditch your entire appsec strategy because you expect 2026 to bring more vulns more quickly, then you probably didn’t have a good strategy in the first place. Rob Allen shares how the mentality of “assume breach” doesn’t have to be a defeatist attitude and can instead be a way to change a catastrophic breach into a more contained one. We also talk about proactive security and what an “avoid breach” attitude could look like, including how to apply the macro lessons of default deny and network isolation to writing secure code.

This was a sponsored interview.

The State of AI & AppSec (ep. 383)

This year has seen a growing gap between long-established secure design fundamentals and burgeoning chaos of LLM-driven vuln discovery. Keith Hoodlet returns to share his latest observations on what the recent news about Mythos, models, and harnesses means for appsec. He walks through the problems of misalignment, the potential development doom that looms behind a volume of vulns, and what modern code creation looks like. Along the way we touch on the economics of tokens and the principles behind secure software. Keith gave a preview of his upcoming presentation (May 22nd) on these topics.

AppSec Conversations on Agents, LLMs, and OWASP from RSAC (ep. 384)

We showcase recordings from this year's RSAC Conference.

Scott Clinton, Co-Chair and co-founder of the OWASP GenAI Security Project, shares insights from the project’s latest research, including new landscape guides and evolving approaches to securing generative and agentic AI systems. The conversation explores critical gaps in genAI data security, the rise of agent-assisted development, and the immense growth of the OWASP community and sponsor ecosystem. Looking ahead, he outlines the most urgent risks and priorities shaping AI and agentic security in 2026.

Then Merritt Maxim discusses how AI is affecting Identity and Access Management. Expect to hear this topic a lot throughout 2026, especially as the industry tries to figure out what’s different or special about securing agent identities.

We close with a chat with Janet Worthington about the impact of agents on the SDLC and how orgs are updating their controls to deal with code generated by humans and LLMs alike.

This tax season, give your org an appsec tax refund.

Skip that list of phishing terms.

Remove that password strength calculator.

Hide that hardening guide.

And instead,

Make passkeys palatable,

Deliver smart defaults,

Defeat classes of vulns with a good design.

Like Standard AppSec News, But With AI (ep. 377)

We started off with a roundup of appsec news. Source code leak, but with AI. Supply chain compromise, but with AI. Better CMS design, but with AI.

The AI angle is inescapable, but that doesn't mean appsec fundamentals have changed. As always, John Kinsella highlights the interesting bits and adds advice for teams figuring out how to use LLMs in their workflows.

The axios supply chain compromise was this year's XZ Utils -- a reminder that security still needs to work on making it easier to deploy known solutions and that many of those solutions should be expected as the default state for modern software development.

I try to curate the articles we cover each week along a common theme for discussion.

The theme this week was my (unattainable?) wish to see appsec use vuln discovery as a motivation for building secure software that avoids classes of vulns. For example, if some code has a SQL query built with string concatenation, why not enforce a coding style and policy that requires only parameterized queries? It seems like we still wait for grep, a fuzzer, or an agent to find such patterns instead of avoiding them in the first place.

Securing Software's Journey with the OWASP SPVS (ep. 378)

It’s one thing to write secure code, it’s another to release it into the wild. It's yet another thing entirely to run someone else’s code on your systems.

Farshad Abasi and Cameron Walters created the OWASP SPVS (Secure Pipeline Verification Standard) to organize the steps and processes needed to establish a secure ecosystem for building, releasing, and maintaining software. They explain how it complements other guidance like ASVS, which focuses on the lifecycle of a specific app, and SLSA, which offers similar levels of controls for creating and consuming software artifacts.

They also explain why they went with a full project instead of creating yet one more top 10 list (thank you), why this 1.5 version bump gained over 130 new controls because of AI (whaaat!?), and how to implement effective controls without being overwhelmed by the amount of them.

They're also looking for more feedback and more contributors. Check out the project and see how you can help!

The Human Aspect of Red Teams (ep. 379)

Red team exercises set goals to see if a particular outcome can be accomplished through a simulated attack, but the ultimate outcome should be educating the org about how to improve tools and processes that make attacks more difficult to succeed.

Gwyddon "Data" Owen shares his experience building a red team, creating an exercise, and leveraging the results to improve security. And while the adoption of LLMs will accelerate a red team's activities, there are still plenty of foundational security controls that orgs can establish that would require a red team to be more than just fast, but fast and very, very careful.

Top 10 Web Hacking Techniques of 2025 and a Hint for 2026 (ep. 380)

Portswigger's list of web hacking techniques is a long-running celebration of curiosity and research from the web hacking community. James Kettle shares his thoughts on the entries from 2025 and how he expects LLMs and agents to influence what the list will look like for next year. He also shares some insights on using LLMs for his own blackbox research, giving us a peek into the work he'll be sharing at Black Hat USA this summer.

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.)