January brings a new year and a new vision for appsec. Let’s leave behind lists and think less about shifting and more about expanding security.

The Difference Engine (ep. 200, replay)

The first show we posted for 2024 came from the vault. Back in July 2022 Keith Hoodlet came by to help celebrate the 200th episode. Keith started the show with episode 0. Since then he’s been blogging at securing.dev about #appsec (of course) and DevOps. Even though this is a news segment, two of the articles were about careers and career development – and surely still relevant today.

Welcome to 2024 (ep. 268)

In the first show we recorded for 2024, John Kinsella shared his take on “appsec in three words” along with a few favorite responses from last year’s guests. Then we talked about where we hope this year takes appsec and some topics that we hope to move on from. It’ll be no surprise to see more AI and supply chain items in the news. It’ll be even better if those items aren’t about more prompt injection or more shift left – some things can stay in 2023.

Communicating Technical Topics Without Being Boring (ep. 269)

Eve Maler returned with recommendations for communicating technical topics to different audiences. It’s part of the theme of presentations that we covered quite a bit in 2023. This time we focused on the importance of communication skills at work.

Appsec Noise Pollution (ep. 270)

Sandy Carielli is another guest we always love to have on the show. We talked about bad bots and their impact on products and the user experience – where there are items of value there are bots. Sandy also makes the point that value isn’t always in obvious items like concert tickets, limited edition clothing, and credentials. Bots can also drive inauthentic reviews and artificial popularity, which is as relevant to products as it is to politics.

Getting Your First Conference Presentation (ep. 271)

We wrapped up January with one last discussion on delivering presentations. This time Sarah Harvey gave a conference organizer’s perspective. Sarah shared some of her own techniques for crafting slides and giving a coherent conference talk. She also explained how conferences like BSides SF actively support new speakers by offering practice sessions and constructive feedback. Giving constructive feedback is its own skill and one that’s relevant to corporate environments in addition to conferences.

December closed out another year of Application Security Weekly. Thank you to everyone who’s listened! We have more news, more guests, and more fun intros coming in 2024.

More Kindling (ep. 265)

John Kinsella keeps a list of news articles and topics to revisit six months later and the end of 2023 seemed like the right time to check that list out. We reviewed several articles from the past year to see if they elicited a yay or a yawn. Not surprisingly, LLMs were pretty common, followed by memory safety and projects adopting Rust.

Walks Into a Bar... (ep. 266)

We dipped into documentation in a conversation with Heather Flanagan about RFCs. She has deep experience with various standards processes and shared her insights on how standards come about, security considerations, and how standards try to avoid ambiguity. Even if you’re not usually reading RFCs (they’re not all dry and boring!), there are lessons here for all sorts of documentation related to software. Check out the show notes for some of our favorite RFCs.

Search for a Clue (ep. 267)

On our last recorded show of the year Idit Levine talked about making service meshes work for people – primarily as a means to increase observability for SREs, developers, and appsec teams. We talked about when and why organizations move from monorepos to service meshes, as well as when a monorepo should remain a monorepo.

Dead Simple (ep. 154, replay)

Since there was one more Monday in December, we squeezed in an episode from the vault. In June 2021 Seba Deleersnyder joined us to talk about the OWASP Software Assurance Maturity Model. It can be especially useful to small orgs and orgs trying to figure out a roadmap for building secure software.

November turned the podcast to a film noir narrative.

The Case of the Greedy Characters (ep. 262)

A lot of appsec conferences have presentations for appsec audiences -- but that's not often the group that's building apps. What if more developer conferences had #appsec content? We talked with Josh Goldberg, an Open Source developer, about security from the developer's point of view, both as an audience hearing about it and as a presenter talking about it. We discussed the importance of knowing your audience and finding the hooks in security tools and topics that resonate with developers.

The Case of the Menacing Slash (ep. 263)

We had another repeat guest with Karl Triebes, who talked about what 2023 brought to appsec and what appsec teams can bring to 2024. Several of the headline-grabbing attacks were old-school flaws, but that’s also because there’s a lot of legacy code out there. Other attacks were bots doing things users do – just at a bigger scale. In other words, attacks based on scraping and scalping and credential stuffing had nothing to do with input validation. They were all about finding workflows that benefited the attackers, whether an account takeover or hoarding concert tickets.

Shrug & Move On (ep. 160, replay)

The month’s third episode took us to the vault for an episode from August 2021 where Maggie Jauregi talked about firmware security. She shared tips on getting into hardware and firmware security on a small budget – something that can broaden the community of researchers in this area. She talked about that community and how welcoming it’s been. Hacking is a creative endeavor and it’s fun to interact with physical devices, whether it’s triggering a glitch with walkie talkies like in her first DEF CON presentation or playing with Raspberry PI and Arduinos.

The Case of the Race Condition (ep. 264)

We ended the month with a conversation on starting things – like starting an appsec program and starting an appsec career. Akira and John shared their questions and insights on how to decide when to specialize, when a startup might consider hiring for an appsec role, and how to figure out if you want that role to take on more engineering or more security testing responsibilities. While there was an unspoken theme of maturity models, there was quite a fun theme of music and being a virtuoso!

October was the month when tales of terror were timely and horror marked our days to Halloween.

Creating Presentations and Training That Engage an Audience (ep. 257)

We started with a topic that instills fear into everyone at some point – public speaking. Lina Lau returned to give us examples of how she crafts and delivers presentations. We talk about what kinds of presentations keep our attention and the kinds that put us to sleep. Not only does Lina excel at delivering engaging presentations, she puts those skills to work in creating multi-day training courses for incident responders.

Lina first joined us back in February of this year to give an incident responder’s view of appsec. Check out episode 230.

Don't Fear the Repo (ep. 258)

Our second week brought another returning guest, Janet Worthington. She covered the conversations she’s had with developers and appsec teams about tools like SCA and SAST. More importantly, she highlighted that how those tools are used is really a side-effect of a good DevSecOps program. Trust and the “no look pass” is one part of a good program. Seeing DevSecOps teams focus their attention on design – securing what they sell – is a much better indicator of success than forever focusing on finding and fixing flaws.

It was just over a year ago that Janet joined us to talk about appsec education in universities. Check out episode 213.

Scary Stories (ep. 259)

Week three was OT. Huxley Barbee gave us some background on how insecure OT devices have been in the last few decades. But we also turned to what might help OT devices be more secure for the next few decades. It’s still hard to emulate and test many of these systems, which limits the amount of security researchers that take the time to understand and test them. It’s also still hard to find development toolchains that provide robust security feedback and testing. We’ve seen great improvements for C and C++ code with features like LLVM’s sanitizers. Hopefully we’ll see those and more applied to these OT devices as well.

Jump Scares (ep. 260)

Then Dan Moore returned to talk about the secure by design and secure by default aspects of OAuth and WebAuthn. I was curious about how OAuth added more capabilities and extensions to deal with new design patterns like single-page apps and the proliferation of mobile apps. The two standards aren't directly comparable in terms of problems they solve, but they share many goals in making adoption easier by developers and countering certain threats to users. There’s also a lesson in what they don’t cover, like account recovery, and why that remains an area that attackers continue to successfully exploit.

Camp Crystal Lake Breach Notification (ep. 261)

Our show just before Halloween covered an appropriately scary topic – how security tools must evolve. Dan Kuykendall talked about the struggle of scanners to keep up with modern app designs and why being beholden to industry categories isn’t providing modern dev teams with the solutions they need. That took us into dev leadership and how to inspire security teams to build effective tools.

I mostly don't care about known vulns in dependencies. I appreciate code quality and want to maintain a recency of at least 1-2 semver minor versions for packages. But so many of those vulns are distractions that don't require prioritization over normal maintenance -- things like XSS in unused code paths, reDoS, malicious config files, and exploit scenarios that require the planets to align in a great conjunction.

I'd rather know about one version to upgrade to than a list of security issues with questionable impact whose remediation spans a range of versions. I also wish scanners would roll up findings into a single "apply this patch" recommendation.

What I wish existed was a scaleable, well-supported scanner that enumerated all runtime dependencies and let me define alerting rules based on:

• the distance from the most recent semver minor version
• the distance from the most recent semver major version
• the days since that most recent major/minor version
• the days until a known EOL such as tracked in endoflife.date

Then for the dimension of known vulns I'd prioritize the CISA KEV along with malicious packages, i.e. packages delivered from a trusted source, but whose contents have been compromised. For the latter, think of packages obtained from trusted package repos, such as XZ Utils or an NPM package that included a malicious commit.

Yes, not every package follows a clean semver, but I'd love to bury the patch-all-the-vulns mentality that comes from being able to identify every single CVE in existence and instead raise a regular maintenance routine that accommodates the meaningful vulns.

We can even keep the SCA tool category -- just call it Semver Creation Analysis or maybe Semver Curation Approach instead. ;)