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. 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.
James is the CEO of DryRun Security, where he and his team built a team of AI-powered Contextual Security Agents that dryrun your code before it gets merged. They enforce policy, detect vulnerabilities (including logic flaws most tools miss), and provide real insight that appsec & eng teams need.
He draws on lessons from distributed systems and Promise Theory to show how explicit commitments between agents lead to security, resilience, and trust at scale. Over his career, he’s built application security programs, advanced DevSecOps practices, and helped organizations reimagine how security fits into fast-moving engineering environments.
James has taught 1M+ professionals through his popular DevOps courses on LinkedIn Learning and has delivered talks at leading conferences, including RSA Conference, OWASP, and SXSW. He lives in Austin, TX, and keeps trying to make the perfect smoked brisket.
Security Weekly listeners save $100 on their RSAC 2026 All Access Pass! RSAC 2026 Conference will take place March 23rd to March 26th in San Francisco. To register using our discount code, please visit securityweekly.com/rsac26 and use the code 56U5SECWEEKLY! We hope to see you there!
Mike Shema
- Using go fix to modernize Go code – The Go Programming Language
This is the kind of language tooling that appeals to me as effective appsec. Using
go fixmakes code more readable for humans and modernizes it in ways that the compiler can better optimize. I would also argue that an additional outcome of those two benefits is that code can become more secure by reducing mistakes. Just because Go has good memory safety guarantees doesn't mean it can't have other types of security flaws.The other reason I grabbed this article is how the Go maintainers point out that LLMs were producing code with disfavored and outdated styles because that's what they were trained on. In other words, your LLM would produce suboptimal code and code that was inherently legacy from the start.
I'd love to see other languages bring this kind of concept into their tooling. Transforming code based on the AST is reliable and, as I noted at the top, code that's easier to read by humans is easier to secure and maintain.
- Making frontier cybersecurity capabilities available to defenders Anthropic
This is a natural followup to Anthropic's article about the 500 vulns it found that we covered back in episode 370.
Like the previous article, it's vague on details. Those 500 vulns were all memory safety issues. And it's hard to tell how many were really just a grep for
strcat(or similar) accompanied by an LLM-generated patch that swaps it out withstrncator some sort of trivial refactor.There's obviously tons of hype and excitement for what this promises. It'll be more revealing when we see how it fares with other vuln classes and real areas of risk within a codebase.
- Carelessness versus craftsmanship in cryptography – The Trail of Bits Blog
I wanted to include this less for the cryptography and more for the points about creating a secure default and handling security issues.
It's no surprise that devs adopting a library will use defaults from that library's code and documentation. Even in the cryptography world we've seen examples of implementations using a "random" choice of cryptographic material taken directly from examples within an RFC's appendix.
But the goal of appsec should be helping devs avoid repeating mistakes and working with projects to create secure defaults in such a way that avoids or minimizes mistakes by a user -- whether the end user of the app that's created or the developer incorporating that project into their own app.
- Secure Your OSS Project: A Guide to the OpenSSF Baseline Badge
A lot of the criteria cover processes related to how the project is managed. The most detailed technical aspects get into matters related to cryptographic controls around confidentiality and integrity. In other words, does the software and its SDLC use encrypted communications and verify hashes?
Having secure practices as part of the SDLC is important and necessary. What I would wish for a list of best practices like this is guidance or examples on how to automate more of them to make security less burdensome. I'm basically wishing for some sort of best-practices-as-code, but no one is going to add another acronym like BPAC to their secure development training. These features need to be part of the platforms supporting the software.
