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.

What if appsec used the last month of the year to celebrate security lasts?

Like, the last CVE due to a SQL injection.

The last user to be blamed for clicking a link.

Or the last time we have to memorize a top 10 list.

Securing OT Sytems in Tennessee (ep. 359)

For OT systems, uptime is paramount. That’s a hard rule that makes maintaining, upgrading, and securing them a complex struggle. Tomas “Data” Owens and James Cotter discuss how Tennessee is tackling the organizational and technical challenges that come with hardening OT systems across the state.

Making OAuth Scale Securely for MCPs (ep. 360)

The MCP standard gave rise to dreams of interconnected agents and nightmares of what those agents would do with unfettered access to APIs, data, and local systems. Aaron Parecki explains how OAuth’s new Client ID Metadata Document spec provides more security for MCPs and the reasons why the behavior and design of MCPs required a new spec like this.

Developing Open Source Skills for Maintaining Projects (ep. 361)

Open source projects benefit from support that takes many shapes. Kat Cosgrove shares her experience across the Kubernetes project and the different ways people can make meaningful contributions to it. One of the underlying themes is that code is written for other people. That means PRs need to be understandable, discussions need to be enlightening, documentation needs to be clear, and collaboration needs to cross all sorts of boundaries.

OWASP Global Appsec 2025 Interviews (ep. 362)

We wrap up the year with a selection of interviews from the OWASP 2025 Global AppSec Conference! Visit https://securityweekly.com/owaspappsec to watch all of CyberRisk TV's interviews from the conference.

First up, Sebastian Deleersnyder talks about using the OWASP SAMM to assess and improve compliance with the Cyber Resilience Act (CRA). He explains why doing so is good strategy, as the SAMM provides a framework for secure development practices such as secure by design principles and handling vulns.

Then James Manico talks about how the definition of “secure coding” is changing with genAI. He talks about how LLMs and agents are reshaping the way developers learn, apply, and scale secure coding practices — and how new risks emerge when machines start generating the code themselves.

Then Adam Shostack shares some history of threat modeling. He explains its evoluation into the Four Question Framework and how to use it as your org adopts agents and LLMs.

Whether you're launching a formal Security Champions program or still figuring out where to start, you already have allies to call on. Dustin Lehr discusses how identifying and empowering your internal advocates is the fastest, most sustainable way to drive security culture change. These allies are the developers, engineers, and team leads who already “get security” even if their title doesn’t have the word security in it.

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!

Keeping Curl Successful and Secure Over the Decades (ep. 320)

Our month kicked off with curl's continuous curator, Daniel Stenberg, explaining the project's approach to appsec. It has had to deal with bad bug bounty reports from LLMs and inflated CVSS scores from CVEs.

It's also had positive experiences and established itself as a positive model for security, which is especially impressive given its steadfast commitment to C. About 40% of its security bugs are attributable to a memory safety issue. But the library supports a massive set of protocols, many of which date back to ancient or ambiguous RFCs. Dealing with protocol state machines and parsing complex data introduces a whole set of security challenges and the potential for logic flaws.

Curl's longevity is commendable. It’s been going for over 27 years now. The project fosters a wide community of contributors, maintains a consistent standard of quality (of which security is just one part), and has created such a fundamentally useful tool that it's no surprise to find it on billions of devices worldwide – or worlds-wide if you include Mars!

CISA’s Secure by Design Principles, Pledge, and Progress (ep. 321)

CISA has been pushing for more software to be secure by design and secure by default. Jack Cable shared how CISA chose to frame their Secure by Design principles and encourage businesses to improve their software quality.

It's not like vuln classes and countermeasures are unknown. Phrack 54 covered SQL injection vulns in 1998. All the major databases supported prepared statements by 2004. Yet in 2025 we already have a few hundred CVEs for SQL injection (and XSS and a few other usual suspects).

But one of the important qualifiers for "easy" fixes is that they have to be "easy to implement and deploy". Not everyone has Google's budget for appsec.

Redlining the Smart Contract Top 10 (ep. 322)

There's no better place to discover the impact of logic flaws than in the cryptocurrency space, where every token is its own self-funding bug bounty and every contract is a gamble in code correctness.

Shashank went into the details of the 2025 edition of the Smart Contract Top 10, how it has changed over the past two years, and how security improvements in Solidity might change it again (for the better!) in another two years.

I appreciate this particular Top 10 list because it's not repetitive of all the others and its entries are domain-specific to crypto. Shashank provided lots of technical background and real examples across familiar appsec flaws like integer overflows and reentrancy problems. More importantly, he talked about the logic problems behind oracle manipulations and flash loan attacks.

Crypto is rife with rug pulls, scams, and questionable tokens. But it's also a great learning space for classes of attacks that aren't memory safety flaws or the dusty XSS and SQL injection of the web.

Thanks again to Shashank for making this topic accessible and engaging!

Finding a Use for GenAI in Appsec (ep. 323)

Sure, LLMs are helping devs write code, but is it secure code? How are LLMs helping appsec teams?

Keith Hoodlet returned to talk about those questions and put the capabilities of LLMs into perspective.

There are notable areas where LLMs prove to be helpful assistants, like having better contextual seeds to craft a fuzzing corpus. There are areas where LLMs could quite directly prove their value in bug bounty hunting. But there are also areas where we've been underwhelmed (so far!) by the generic LLM responses to threat modeling and security reviews.

We also discussed the importance of reading beyond the headlines of research papers in order to avoid hype and better understand what's improving – and what's not – in terms of code generation and security capabilities.

I always enjoy talking with Keith. Regardless of how much of a future we'll have with appsec toasters, he'll always be a human I turn to for insights in this area.

Avoiding AppSec’s Worst Practices (ep. 324)

We entertained some foolish notions about the worst ways to approach appsec. But out of that chaos emerged some debate about tracking tons of vulns, using LLMs, and what secure design means.

Does vibe coding need vibe appsec? Do those words mean anything? Why does infosec love bad metaphors? What's the best direction to shift? What are we even shifting in the first place?

Shout out to Jackie McGuire and Adrian Sanabria for joining John Kinsella and me in this discussion.

We didn't get a chance to finish our top ten list of emojis to use in LinkedIn posts, so this recap will have to be several paragraphs, a bunch of links, and a ton of thank yous to everyone who's been watching the show!

Go is giving devs a better tool against traversal attacks.

We didn't get the chance for a news segment in this week's Application Security Weekly podcast, but I still wanted to highlight an article that stood out to me.

Path traversal is one of my favorite appsec flaws. It's trivial to demonstrate, easy to understand, and its related security principles lead down many ... paths.

The simplest payloads rely on classic characters like dot-dot-slash (../). From there you can steer a discussion into web-related concepts like percent encoding (%2f), overlong UTF-8 encoding (%c0%af), normalization of slashes, and programming language abstractions over a file system. Once you're onto the file system, you can hit areas of OS behavior differences, symbolic links, sandboxing, and more normalization concepts.

Then as you refine simple payloads into attack scenarios, you have opportunities that span file reads to leak useful info, file writes to clobber and create files, and file execution to run arbitrary commands. You can even sneak in a discussion of race conditions and TOCTOU-style attacks.

And now Go has defenses for devs to deal with files with the new "Traversal-resistant file APIs" in the 1.24 release.

With this API, a developer sets a root location in which file operations must be constrained. No file paths or symlinks will be able to reach outside of that root, regardless of how clever a traversal payload it might have.

This is great news for devs writing new code that has to interact with the file system. This is the kind of API that establishes a more secure design (with a few caveats) that's resistant to mistakes and misunderstandings.

That last part is key to me when looking at an API. It doesn't have flags that change its behavior between a safe vs. unsafe mode, it addresses a common need, and it's extremely simple.

It's also good news for existing code that was potentially insecure or that relied on other packages for secure file system access. Now it's possible to make that existing code secure and reduce the amount of dependencies you rely on.

(Admittedly, changing one secure implementation to another secure implementation rarely gets a high priority, but I will always like the idea of removing code and reducing dependencies when possible.)

However, the Go blog post includes caveats that show just how pernicious this vuln class remains. It notes that the underlying OS and environment may still have inconsistencies, such as Node.js remaining vulnerable to TOCTOU attacks when using these functions. Such is the life of APIs on top of APIs.

I'll continue to experiment with more news commentary like this one. In the meantime, catch up on more news and the latest episodes at the podcast's home.

p.s. Speaking of OS support. The Go blog post mentions Plan 9(!?) lol. Does anyone actually use that? The design philosophy of Plan 9 is that everything is a file, so it's totally relevant to traversal. But wow that's an OS I've not heard mentioned for several decades.