Avoiding Appsec’s Worst Practices – ASW #324

Excellent writeup on the mechanics of the vuln, how Wiz researchers chose to focus on this area, and (spoiler alert) a final caution that "…nginx -t should be considered harmful."

We already have decades of human-generated insecure code, but with LLMs we can recreate those decades within days. But we don't have great rubrics for immediately evaluating insecure vs. secure code, hence the whole appsec industry.

Even so, it's good to see efforts at quantifying how LLMs impact code quality. If a premise of LLMs writing code is to save time for developers, that premise needs to be tested against the confidence and trust that devs can have in that generated code. If a dev shifts from writing lines of code to reading, understanding, and correcting lines of code from an LLM, their time still needs to be used productively and efficiently.

I love this kind of writeup that goes into technical details of a vuln, while also discussing the broader concepts behind those details and drawing parallels to previous work.

Ian Beer of Google Project Zero walks through the discovery, guesswork, and analysis behind an exploit that broke through iMessages' Blast Doors.

We covered the FORCEDENTRY writeup back three years ago, back in the so very ancient episode 191.

This blog post makes similar arguments to one we covered a few weeks ago about not writing yet another jailbreak paper (episode 321). To quote from this post, "Jailbreaks and prompt injections, while attention-grabbing, often fail to translate into meaningful risks without broader system vulnerabilities."

The post provides a few motivating questions to use when thinking about threat models and security test scenarios, but that list is just a seed for thinking about the larger implications of how a system is using an LLM.

Kudos for transparency in a postmortem. This post contains a clear rundown of events, miscommunications, and re-evaluations for the recent Next.js vuln (which we also covered last week).

It includes some pretty concrete actions, which are far more illustrative of how a company can take security seriously.

It also includes this sentence that's indicative of the challenge of creating software that's secure by design and secure by default -- "We do not recommend Middleware to be the sole method of protecting routes in your application."

In other words, how do you convey intent and discourage misuse?

Or, in even simpler and more meme-able words, "Your developers were so preoccupied with whether or not they could, they didn't stop to think if they should."

Expect the phrase, "We are OPSEC clean", to have a regular appearance at infosec conferences for the rest of 2025.

But this does give us a chance to talk about the intersection of secure designs, UX, and threat models. Check out the 404 Media article about the specific threat modeling challenge for this situation.

Also check out how the news outside of the infosec world talks about Signal and threat models to the general public. It's a reminder that when cybersecurity awareness month finally arrives, that people don't care about taxonomies of attacks, they care about staying secure while getting on with their life.

From the post, "…FLS provides a structured and detailed reference for Rust’s syntax, semantics, and behavior, serving as a foundation for verification, compliance, and standardization efforts."

It may not be the most exciting topic nor the most important to many devs, but it helps address potential barriers to adoption by "…describing Rust in a way that aligns with industry requirements, particularly in high-assurance domains."

More insights into macOS internals. This is good news because it shows how an OS can expose critical security events to tools without having to bring those tools into the kernel. In this way, tools can observe and even intervene if they believe a user is taking an action against their own interests.

Technical one-page articles on cybersecurity and IT topics.

Mega bonus points for the art and relying on human artists.