The Application Security Podcast

Latest Episodes:

Stephen de Vries -- Threat Modeling with a bit of #Startup Aug 20, 2018

Show notes

What developers need from a threat model is often a clear set of requirements they can implement. Stephen de Vries explains how that perspective shaped IriusRisk and his move from security consulting into building a product company. He and Chris discuss reusable threats and countermeasures, the role of OWASP ASVS, and the need to translate guidance into instructions that make sense in an issue tracker. They also examine why spreadsheets and separate security systems create friction, and how existing testing and design habits can provide a bridge into security. Stephen’s startup experience frames a broader conversation about making threat modeling repeatable: reuse what is known, focus human attention on the difficult parts, and meet developers inside their normal workflow.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Stephen de Vries:
→ Stephen de Vries on LinkedIn
→ IriusRisk

Mentioned in this episode:
→ OWASP Application Security Verification Standard
→ OWASP Proactive Controls
→ OWASP Web Security Testing Guide

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Threat modeling and startup lessons with Stephen de Vries
00:34 Stephen’s development and security background
05:01 Starting a security product company
06:35 From building a product to building a company
07:48 Threat modeling as a route to security requirements
10:41 Reusing common threats and countermeasures
12:00 Connecting requirements management and threat modeling
13:43 Turning ASVS into actionable developer guidance
14:16 Meeting developers in their existing tools
15:33 Removing spreadsheet and email friction
17:00 Building on testing and design habits
18:41 Connecting everyday risk thinking to security
20:06 Behavior-driven testing and useful OWASP resources

Julien Vehent -- Securing DevOps Aug 14, 2018

Show notes

Can security become a normal part of DevOps without turning every release into an audit? Julien Vehent, author of Securing DevOps, shares what his team learned protecting Firefox services at Mozilla. He explains why security engineers belong inside product teams, how short checklists translate large security requirements into work developers can actually complete, and where creativity still matters. Julien challenges the idea that everything must be automated, showing how automation frees specialists to investigate the problems that require judgment. The conversation follows real examples involving Content Security Policy, bug bounties, website security grades, and testing in delivery pipelines. He closes by describing continuous security as a feedback loop that turns operational lessons into better requirements, controls, and engineering practices.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Julien Vehent:
→ Julien Vehent’s website

Mentioned in this episode:
→ Securing DevOps by Julien Vehent
→ Mozilla HTTP Observatory
→ ZAP
→ SSL Labs Server Test

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Securing DevOps with Julien Vehent
01:54 Julien’s security origin story
04:51 Defining DevOps as engineering practices
06:33 The practical story behind Securing DevOps
07:32 Making security a natural part of building software
10:28 Putting security inside the product team
13:11 Turning security requirements into checklists
16:11 Leaving developers room for creativity
17:15 Where manual security work still belongs
21:23 Mozilla’s experience with CSP and bug bounties
25:12 Observatory, SSL Labs, and pipeline testing
26:35 Continuous security as a feedback loop
30:31 Learning security by building real systems
32:39 Room to improve DevOps security

Christian Folini -- CRS and an Abstraction Layer Aug 07, 2018

Show notes

How can one open-source rule set protect applications across competing products and very different architectures? Christian Folini explains the relationship between the ModSecurity engine and the OWASP Core Rule Set, including the attacks generic rules can detect and the limits of a web application firewall. Recorded at AppSec Europe, the conversation explores a gathering of vendors and contributors working to improve compatibility, feedback, and the project’s future. Christian describes the proposed abstraction layer that could separate security rules from a particular engine and bring detection closer to application code. He also discusses funding, testing, false positives, and integrating protection into continuous delivery. The result is a practical look at both the engineering and community work behind widely deployed open-source defenses.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Christian Folini:
→ Christian Folini on LinkedIn
→ Christian Folini’s website

Mentioned in this episode:
→ OWASP Core Rule Set
→ ModSecurity

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Christian Folini and the Core Rule Set
01:38 From medieval history to application security
02:39 How CRS fits with the ModSecurity engine
03:42 Attack coverage and a WAF’s limits
06:06 Bringing vendors together at AppSec Europe
08:39 A common abstraction layer for security rules
12:57 Funding and contributing to open source
15:30 More outcomes from the CRS gathering
17:46 CRS in continuous integration and runtime protection
19:42 Could CRS run inside an application runtime?
20:40 Moving security decisions closer to the code
23:50 Where to learn more and contribute

Sean Wright -- Google Chrome and the Case of the Disappearing HTTP Jul 30, 2018

Show notes

What changed when Chrome began labeling ordinary HTTP pages as not secure, and why did that decision provoke resistance? Application security practitioner Sean Wright explains the browser changes in their 2018 context and makes the case for protecting every website with TLS. He separates encrypted transport from trust in a website, examines how unencrypted traffic can be read or modified, and discusses the objections that complicated wider HTTPS adoption. The conversation covers accessible certificate options such as Let’s Encrypt, the role of Cloudflare, and the usability benefits of safer browser defaults. Sean also explains how HTTP Strict Transport Security and preload lists address downgrade opportunities. It is a useful historical discussion of the shift from optional encryption toward an HTTPS-first web.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Sean Wright:
→ Sean Wright’s blog
→ Sean Wright’s portfolio

Mentioned in this episode:
→ Let’s Encrypt
→ HSTS Preload List
→ HTTPS Everywhere — retired browser extension

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Chrome, HTTP, and Sean Wright
01:49 Sean’s route from development into security
03:23 What TLS protects
04:11 Why every website needs encrypted transport
05:34 The controversy around HTTP warnings
07:45 How unencrypted traffic can be modified
08:46 Misinformation and objections to HTTPS
10:34 Let’s Encrypt and accessible certificates
16:20 Safer defaults and usable security
20:22 HSTS headers and preload protection
22:38 Resources for understanding the change

Conclusion: All the Pieces You Need for an #AppSec Program Jun 12, 2018

Show notes

Which practices belong in a complete application security program? The Season 3 finale answers by assembling clips that move from early development decisions through testing, resilience, and runtime detection. Kevin Greene explains shifting left, Robert Hurlbut defines security champions, Pete Chestna distinguishes SAST, DAST, IAST, and RASP, and Megan Wu describes burnout and its warning signs. Jim Manico presents the OWASP Cheat Sheet Series, David Habusha explains software composition analysis and the Equifax example, and John Melton closes with OWASP AppSensor. Chris and Robert use the clips to show that AppSec is not one tool or one team; it is a connected set of technical practices, community roles, and sustainable working habits.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Chris Romeo and Robert Hurlbut:
→ Chris Romeo on LinkedIn
→ Robert Hurlbut on LinkedIn

Mentioned in this episode:
→ OWASP Cheat Sheet Series
→ OWASP AppSensor
→ OWASP Dependency-Check
→ National Vulnerability Database
→ OWASP Cheat Sheet Series

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Building a complete AppSec program
00:50 Kevin Greene on shifting left
04:58 Robert Hurlbut on security champions
06:38 Pete Chestna on SAST, DAST, IAST, and RASP
10:16 Megan Wu on recognizing burnout
12:50 Jim Manico on the OWASP Cheat Sheet Series
17:35 David Habusha on software composition analysis
20:45 Could SCA have prevented Equifax?
22:44 John Melton on OWASP AppSensor
28:05 Closing Season 3

Martin Knobloch -- OWASP, Reach Out; We Are Known and Misunderstood Jun 05, 2018

Show notes

OWASP is widely recognized, but do people understand the community behind its famous Top 10? Martin Knobloch, serving as the foundation’s board chair when this conversation was recorded in 2018, explains what the organization does and how volunteers make it work. He traces his journey from industrial control programming into software security, then describes board responsibilities, chapter leadership, and the educational value of OWASP projects. Chris and Robert explore how an open community handles disagreement, measures its impact, and reaches people outside its existing circle. Martin reflects on the organization’s growth, the role of staff, and the value of conferences for meeting contributors. His closing challenge is straightforward: reach out, share useful resources, and help more people participate in application security.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Martin Knobloch:
→ Martin Knobloch on LinkedIn

Mentioned in this episode:
→ OWASP Foundation
→ OWASP Web Security Testing Guide
→ OWASP ASVS

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Understanding the OWASP community
01:31 Martin’s security origin story
04:06 What the OWASP board chair does
07:53 OWASP’s mission and purpose
08:52 The educational value of the Testing Guide
11:04 The scale and passion of the volunteer community
14:48 Working through community disagreements
16:34 Measuring impact beyond OWASP
19:45 How OWASP changed as it grew
21:20 Supporting growth with staff and leadership
23:25 Projects Martin is working on
24:24 Why attend an OWASP conference?
28:44 A challenge to reach out

Devin McMasters -- Bug Bounty with a Side of Empathy May 29, 2018

Show notes

A bug bounty can create a productive relationship with security researchers—or damage trust on both sides. Devin McMasters joins Chris to explain how organizations can design programs that produce useful findings while treating researchers fairly. He compares crowdsourced security with traditional penetration testing, discusses public and private programs, and describes the operational maturity required before inviting outside reports. The conversation covers vulnerability types, payout budgets, incident-response workflows, reputation, and common program mistakes. Devin repeatedly returns to empathy: companies may set the final rules, but researchers invest real time and may depend on rewards, so clear communication and respectful decisions are essential to a sustainable bug bounty program.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Devin McMasters:
→ Devin McMasters on LinkedIn

Mentioned in this episode:
→ Bugcrowd
→ HackerOne

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Bug bounties with empathy
01:41 Devin McMasters’s developer background
05:16 What a bug bounty program does
06:01 Why organizations run bug bounties
07:50 Building a relationship with researchers
09:57 Bug bounty versus penetration testing
12:21 The findings a bounty can uncover
14:37 Payouts and program budgets
17:20 Public and private bug bounties
18:08 Operational maturity before launch
19:59 Reputation in the researcher community
22:03 Incident response and remediation workflows
24:06 Common bug bounty mistakes
25:03 Applying empathy to program decisions
28:00 Final takeaways

Apollo Clark -- Malicious User Stories May 22, 2018

Show notes

How do you turn a security requirement into something a development team can build and test? Apollo Clark explains malicious user stories: short descriptions of what a particular attacker should not be able to accomplish. Speaking at the Source Conference in Boston, he connects these stories to business goals, regulatory requirements, and automated tests in a delivery pipeline. Apollo then steps back to define DevOps through values, feedback, and continuous learning rather than a shopping list of tools. The discussion follows those ideas into practical automation with Gauntlt, reusable security checks, containers, and infrastructure deployment. He shares lessons from working with executives and engineers, arguing that security succeeds when teams agree on outcomes and translate them into repeatable technical practices.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Apollo Clark:
→ Apollo Clark on GitHub

Mentioned in this episode:
→ Gauntlt
→ The DevOps Handbook
→ Terraform

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Malicious user stories with Apollo Clark
01:41 Apollo’s security origin story
03:14 From user personas to malicious user stories
05:12 Writing testable attacker-focused outcomes
05:50 Translating regulations into security stories
07:22 Integrating the stories into DevOps
08:37 Defining DevOps through values and the three ways
11:59 Putting security into automated delivery
13:00 OWASP contributions and Gauntlt
15:35 Running security checks with containers
19:10 Gauntlt’s direction and practical limitations
19:39 Automating infrastructure deployment
20:38 Start with what your organization values

Megan Roddie -- Neurodiversity in Security May 15, 2018

Show notes

Could familiar hiring and management practices be keeping talented people out of security? Megan Roddie draws on her own experience to discuss neurodiversity and the strengths autistic people can bring to security teams. Recorded at the Source Conference in Boston, the conversation explores deep focus, sustained curiosity, communication differences, and the assumptions that can shape interviews. Megan explains why rigid job descriptions may discourage capable applicants and why managers should learn how each person works rather than rely on a single model of a good employee. Robert also shares his perspective as a parent. Together they discuss clearer expectations, two-way communication, and recognizing individual strengths, offering a practical invitation to make security workplaces more welcoming and effective for different kinds of minds.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Megan Roddie:
→ Megan Roddie-Fonseca on LinkedIn

Mentioned in this episode:
→ DEF CON
→ Black Hat

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Neurodiversity in security with Megan Roddie
01:30 Why Megan brought this topic to the conference
02:08 Megan’s security origin story
03:29 Understanding neurodiversity and autism
05:14 Strengths that different minds bring to security
06:43 Addressing employers’ concerns
07:58 Supporting strengths and individual needs
09:54 Reaching candidates through better hiring practices
12:50 When rigid job descriptions discourage applicants
13:53 Managing through clear two-way communication
16:18 Final advice for inclusive teams

Chase Schultz -- AppSec and Hardware Apr 27, 2018

Show notes

Where does application security end when software controls bootloaders, firmware, processors, and connected devices? Chase Schultz joins Chris for a wide-ranging discussion of the boundary between AppSec and hardware security. They examine secure coding in embedded systems, trusted boot, firmware signing, coprocessor supply chains, ASLR, and the no-execute bit before unpacking Meltdown and Spectre. Chris explains how speculative execution and processor caches created paths to sensitive memory, while Chase connects the mitigations to defense in depth and threat modeling. The episode shows that familiar software-security practices still matter near the hardware, even when vulnerabilities ultimately require changes to operating systems, microcode, or silicon.

The Application Security Podcast is brought to you by Security Journey.

About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey

Connect with Chase Schultz:
→ Chase Schultz on LinkedIn

Mentioned in this episode:
→ Meltdown and Spectre
→ U-Boot
→ Docker

Follow the Application Security Podcast:
➜ Home
➜ X
➜ LinkedIn
➜ YouTube
➜ Instagram
➜ Facebook

Chapters:
00:00 Where AppSec meets hardware
01:44 Chase Schultz’s security origin story
06:23 Old AppSec problems in new connected devices
07:47 Microarchitecture attacks and processor optimizations
08:48 Secure coding for hardware and firmware
11:20 Coprocessor supply chains and bootloaders
14:24 Trusted boot and firmware signing
16:37 ASLR, no-execute, and hardware defenses
17:20 How Meltdown and Spectre work
21:46 Speculative execution and access to memory
23:29 Kernel memory, containers, and cloud impact
24:46 Mitigating flaws that live in processors
26:11 Address space layout randomization
28:18 Could threat modeling have found the problem?
30:44 Closing thoughts

Our TOPPODCAST Picks

Follow Us

Stay Connected

The Application Security Podcast

Related Podcasts

Links

Stay Connected