Appsec still deals with ancient vulns like SQL injection and XSS. And now LLMs are generating code along side humans. Sandy Carielli and Janet Worthington join us once again to discuss what all this new code means for appsec practices. On a positive note, the prevalence of those ancient vulns seems to be diminishing, but the rising use of LLMs is expanding a new (but not very different) attack surface. We look at where orgs are investing in appsec, who appsec teams are collaborating with, and whether we need security awareness training for LLMs.
Resources:
Sandy advises security and risk professionals on application and product security, with a particular emphasis on the collaboration among security and risk, product management, application development, operations, and business teams. Her research covers topics such as proactive security design, protecting modern and emerging application architectures, protection of applications in production environments, and embedding security throughout the product lifecycle.
Janet Worthington is a Senior Analyst for Security & Risk at Forrester. Janet covers product security, software supply chain, Open Source security, and DevSecOps. Janet’s background is in product management and application security.
Mike Shema
- OWASP AI Testing Guide
It's a lot of mapping between threat modeling references and OWASP lists, which is good for standing out as far more than just a list of prompt injection techniques, but makes for some dense reading. The current draft feels more like it's growing into an LLM-styled ASVS more so than a testing guide, but that's just quibbling about its focus rather than its content.
Check out the current draft at the project's GitHub repo.
- Guest Post: How I Scanned all of GitHub’s “Oops Commits” for Leaked Secrets
How to turn a "for" loop and grep into $25k. Ok, it's more technically interesting than that and it's obviously valuable work. And it shows that simple security ideas are still worth exploring!
- [FYI] Buckle up, Buttercup, AIxCC’s scored round is underway!
I'm continuing to follow the AIxCC project to see what LLMs can do to reliably find and fix flaws. The finding part seems to largely rely on LLMs guiding fuzzers (which seems like a smart choice!). But I haven't been paying as much attention to the fixing side of things.
- [FYI] Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development | CISA
Mostly I'm just including this to highlight how CISA points out engineering principles and iterative adoption to memory safe languages. It's easy to be reductive and say, "Just rewrite in [whatever]", but the truth is that CISA is extolling the virtues of risk-based decision making for architecture changes and acknowledging that lots of code will never be rewritten. It's neither giving up nor trying to do the impossible; it's trying to add considerations around memory safety to ongoing engineering and architecture discussions within orgs.
- [FYI] Security Best Practices – Model Context Protocol
- Ubuntu disables Intel GPU security mitigations, promises 20% performance boost
This reminds me of the CCC talk back in December 2024 about "Ten Years of Rowhammer" and the flippyr.am project looking at the prevalence of and risk of this memory side-channel attack.
Rowhammer shares the side-channel principle with Meltdown and Spectre, but where Rowhammer clobbers DRAM to infer the values of nearby memory, Spectre (and similar) relies on the behavior of CPUs to fetch values from memory in anticipation of their use (as in speculating what branch code may take and the value in memory that code will need). I threw these two together here because these discussions of whether the security trade-offs are commensurate with the flaws' underlying risks and attack scenarios.
And, to be clear, Ubuntu is removing this specific mitigation in the GPU because it's addressed elsewhere in the kernel. They're shifting security barriers, not dismantling them entirely.
- Critical Command Injection Flaw in iOS Simulator MCP Server Exposes Development Environments
The article does a good job of explaining the flawed code path and describing potential attacks. The whole problem boils down to "Use Safe APIs: Prefer execFile() over exec() when possible".
What surprises (or disappoints) me is that this is new code that is introducing an old vulnerability despite having a trivial, secure alternative. It's just coincidental that it's related to an MCP server. The underlying flaw is something that an IDE, linter, or some other basic dev tool should be raising red flags about and preventing. Maybe one day...
Check out a different command injection mentioned a days earlier on the same blog.
