The Application Security Podcast

Latest Episodes:

Mike Goodwin -- The OWASP Threat Dragon Jun 27, 2017

Show notes

Threat modeling is easier to adopt when its tools fit the way developers already work. Mike Goodwin joins Chris and Robert to introduce the early OWASP Threat Dragon project and explain why he wanted an accessible alternative to tools tied to a single operating system. They walk through creating diagrams, recording threats, and keeping models alongside application code in GitHub. Mike describes his plans for automated threat suggestions, workflow integration, and reminders that keep models from becoming stale. The discussion also considers collaboration, combining feature-level models, and what new users need to understand about STRIDE. This archive conversation documents the project’s initial ambitions and invites developers to help shape a simpler, more integrated approach to threat modeling.

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 Mike Goodwin:
→ Mike Goodwin on GitHub
→ OWASP Threat Dragon

Mentioned in this episode:
→ Threat Dragon source code
→ Microsoft Threat Modeling Tool

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

Chapters:
00:00 Meet Mike Goodwin and OWASP Threat Dragon
01:19 A cloud migration sparks an interest in security
02:59 What Threat Dragon is designed to do
04:31 Why build another threat modeling tool?
06:17 The limitations of a Windows-only workflow
07:17 Creating a model in Threat Dragon
12:15 Threat generation and future capabilities
13:39 Keeping threat models beside code in GitHub
15:50 Connecting models to developer workflows
20:18 What organizations need from modeling tools
21:30 Concurrent editing and combining models
24:02 STRIDE and the knowledge new users need
25:00 The early roadmap toward beta and version one
27:18 Giving feedback and contributing

Mark Willis -- I Just Like Static Analysis. Static Analysis is My Favorite Jun 19, 2017

Show notes

Static analysis can help developers find security flaws early, but buying a scanner does not create an effective program. Mark Willis joins Chris and Robert to explain how he fits testing into the software development lifecycle and works with developers to make results useful. They discuss choosing tools for the actual codebase, tuning recurring false positives, and evaluating products before committing to them. The conversation weighs scan coverage against the pace of DevOps and considers when dynamic testing and a deeper penetration test are appropriate. Mark also describes finding developers who want to become security champions and helping them build their skills. The recurring theme is collaboration: useful testing depends on context, timely feedback, and respect for the people fixing the code.

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 Mark Willis:
→ Mark Willis at RSA Conference

Mentioned in this episode:
→ OWASP
→ OWASP Testing Guide

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

Chapters:
00:00 Static analysis and developer collaboration with Mark Willis
01:12 Mark’s journey from development into security
07:19 Empathy for the people writing the code
10:42 Placing static analysis in the SDLC
14:23 Tuning tools and reducing false positives
16:27 Evaluating scanners before buying
19:20 Static analysis at DevOps speed
23:02 What dynamic scanners can and cannot do
28:05 Working within the testing and release window
31:13 Choosing applications for deeper penetration testing
33:43 Helping developers move into security
36:51 Learning with the OWASP Testing Guide

Eric Johnson -- Continuous Integration in .NET Jun 14, 2017

Show notes

Security testing loses value when its results arrive outside the developer’s normal workflow. Eric Johnson joins the podcast to explain how continuous integration can make security checks part of building and delivering software, with a particular focus on .NET. He discusses connecting automated tools to development pipelines and using feedback where engineers already work. Eric then introduces Puma Scan, an open-source security analyzer built on the Roslyn compiler platform, and describes how compiler-aware rules can identify insecure code while developers are editing it. The conversation compares that approach with older .NET analysis options and considers how the wider community can contribute. It is a practical look at reducing the distance between writing code, finding a flaw, and fixing it.

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 Eric Johnson:
→ Eric Johnson on LinkedIn
→ Puma Scan

Mentioned in this episode:
→ Roslyn (.NET Compiler Platform)
→ Jenkins
→ OWASP ZAP
→ Find Security Bugs
→ Brakeman

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

Chapters:
00:00 Continuous integration and .NET security with Eric Johnson
02:53 Eric’s development and security background
04:57 Teaching application security
08:17 Bringing security checks into continuous integration
10:05 Using the tools developers already rely on
12:59 Why focus on .NET and Roslyn?
15:13 Building security rules and Puma Scan
18:26 Using Puma Scan inside Visual Studio
21:25 Filling the open-source .NET scanning gap

Matt Clapham -- The Technical Debt Ceiling Jun 06, 2017

Show notes

Every software organization accumulates technical debt, but security debt raises the cost and risk of every future change. Matt Clapham joins Chris at the Converge conference to explain how startups and enterprises incur debt through rushed decisions, flawed architectures, outdated dependencies, and products that outlive their original assumptions. They distinguish general technical debt from security-specific consequences, examine the effect on development and operations, and discuss ways teams can keep the problem visible. Matt argues for deliberate limits—a technical debt ceiling—supported by refactoring, dependency maintenance, prioritization, and clear ownership. The goal is not zero debt, but a sustainable level that does not prevent teams from improving or securing the product.

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 Matt Clapham:
→ ProdSec on X
→ Converge Detroit

Mentioned in this episode:
→ Converge Detroit
→ OWASP Dependency-Check

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

Chapters:
00:00 Defining the technical debt ceiling
01:41 Technical debt in IoT and application security
02:58 People, process, and technology causes
05:19 How enterprises accumulate debt
06:58 Technical debt versus security debt
08:08 The impact of a flawed foundation
09:59 Reducing and managing technical debt
12:16 Third-party software and dependency risk
13:30 Products that never update components
16:25 Additional strategies for sustainable systems
18:20 Setting a practical debt goal
19:17 Resources and final recommendations

Chris and Robert -- Controversy within the OWASP Top 10 RC May 30, 2017

Show notes

Why did the 2017 OWASP Top 10 release candidate provoke such a strong reaction? Chris and Robert walk through the proposed categories, compare them with earlier editions, and examine the project’s role as both awareness document and de facto testing target. They discuss merged and removed risks, injection, authentication, sensitive data, XML external entities, access control, cross-site scripting, insecure deserialization, components with known vulnerabilities, and insufficient attack protection. The hosts question whether new categories are sufficiently general, whether tools and frameworks already address some risks, and how modern APIs and microservices affect the list. The episode preserves the uncertainty of a release-candidate debate while helping listeners understand the technical and governance questions behind a widely used standard.

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 Top 10
→ OWASP Top 10 2017
→ OWASP AppSensor Project
→ OWASP Top 10 A9 (Using Components with Known Vulnerabilities)

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

Chapters:
00:00 The controversial OWASP Top 10 candidate
01:25 The Top 10’s history and influence
03:17 How tools use the list
05:08 Reaction to the 2017 release candidate
06:36 Merged and renamed categories
08:01 Removed risks
09:20 Framework protections and remaining responsibility
11:13 Injection and authentication
13:47 Which risks apply beyond web applications
15:14 Cross-site scripting and browser defenses
16:46 Access control must be consistent
18:37 Automating security verification
20:20 Insufficient attack protection
22:01 Application-level detection and response
23:53 Insecure deserialization
25:48 Components with known vulnerabilities
27:09 APIs, microservices, and attack surface
29:00 Security through obscurity
31:00 Final assessment of the candidate

Brook S.E. Schoenfield -- Security in the Design and Architecture May 22, 2017

Show notes

Fixing vulnerable code is only part of application security; a flawed design can survive every code-level check. Brook S. E. Schoenfield joins Chris and Robert at RSA Conference to explain what security architects do and how they reason about systems before and during implementation. He connects threat modeling to architecture, business priorities, and the practical limits on what a team can change. The discussion explores collaboration between architects and developers, the value of empowering engineering teams, and the communication skills needed to make security advice useful. Brook also reflects on learning from experience and offers a path for people who want to become security architects. The emphasis is on understanding the system and its people well enough to make better design decisions.

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 Brook S.E. Schoenfield:
→ Brook Schoenfield
→ Brook Schoenfield on LinkedIn

Mentioned in this episode:
→ IEEE Center for Secure Design
→ FAIR Institute
→ Cyber Kill Chain (Lockheed Martin)

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

Chapters:
00:00 Security in design and architecture with Brook Schoenfield
02:41 Brook’s security origin story
06:23 Understanding the application security design problem
08:24 What a security architect does
11:24 Connecting architecture and threats
16:59 Turning experience into a better approach
26:08 Working within business priorities and constraints
33:08 Helping developers and architects collaborate
34:01 Organizational structures and shared ownership
43:28 Empowering teams with lightweight security practices
46:26 Becoming a security architect

Conclusion: The End…of Season 1 Jan 25, 2017

Show notes

What defined the first season of the Application Security Podcast? Chris and Robert revisit clips that established the show’s early themes: thinking like an attacker, building security community, practicing threat modeling, collaborating during penetration testing, learning reverse engineering, and finding a path into the profession. Adam Shostack explains why “think like an attacker” can exclude developers, Chris describes internal security communities, Tony UcedaVélez introduces PASTA, and the hosts revisit lessons about testers working with development teams. Jon McCoy defines reverse engineering, while Tracy Maleeff shares career-transition advice and reading recommendations. The finale is both a retrospective and a statement of direction: application security improves when technical methods, empathy, learning, and community reinforce one another.

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:
→ PASTA Threat Modeling
→ Cybersecurity Canon
→ The Cuckoo's Egg
→ Adam Shostack
→ Tony UcedaVelez
→ Jon McCoy
→ BSides

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

Chapters:
00:00 Looking back at Season 1
02:00 Adam Shostack on thinking like an attacker
04:45 Why that phrase can exclude developers
06:38 Chris Romeo on security community
09:33 Tony UcedaVélez on PASTA threat modeling
11:05 Why penetration testing matters
12:26 Testers and developers working together
13:14 Jon McCoy on reverse engineering
15:19 Tracy Maleeff on entering security
16:39 Learning through books and history
17:17 The Cuckoo’s Egg and closing recommendations
18:21 Closing Season 1

Rafal Los, James Jardine, and Michael Santarcangelo -- #DtSR and What Makes a Good Security Consultant? Jan 12, 2017

Show notes

What separates a useful security consultant from someone who merely arrives with answers? Rafal Los, James Jardine, and Michael Santarcangelo of the Down the Security Rabbit Hole podcast join Chris and Robert to examine consulting from external and internal perspectives. They compare technical ability with empathy, listening, confidence, communication, and the willingness to admit uncertainty. Each guest shares career lessons, including working yourself out of a role by making the client stronger, building durable relationships, and staying focused on the work you do best. The group also discusses specialization, referrals, and advice for people entering consulting. Their shared conclusion is that expertise matters, but a consultant creates value by understanding context, helping others succeed, and earning trust.

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 Rafal Los, James Jardine, and Michael Santarcangelo:
→ Rafal Los on X
→ James Jardine on X
→ Michael Santarcangelo on X

Mentioned in this episode:
→ Down the Security Rabbithole Podcast

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

Chapters:
00:00 What makes a good security consultant
02:20 Michael’s view of successful consulting
03:45 Rafal’s external-consultant perspective
05:22 James on consulting from inside organizations
07:26 Empathy as a professional skill
09:19 Technical skills versus soft skills
13:34 Career origin stories and second chances
16:00 Working yourself out of a job
18:12 Lessons from James Jardine
20:02 Listening, confidence, and handling uncertainty
22:11 Consulting across different client contexts
25:05 Focus, specialization, and referrals
29:27 Advice for people entering consulting
31:55 Creating opportunities for new talent
33:43 Final recommendations
36:25 Closing thoughts

Adam Shostack -- Think like an Attacker or Accountant? Jan 04, 2017

Show notes

What does “think like an attacker” actually ask a developer to do? Adam Shostack joins Chris and Robert to challenge a familiar instruction that can leave capable engineers feeling excluded from security work. He describes an experience that changed his approach and explains why developers’ knowledge of their own systems should be the starting point for threat modeling. The conversation examines the difference between persuading people that security matters and giving them a concrete way to practice it. Chris and Robert add examples from development teams, while Adam extends the discussion to infrastructure and operations. They close with practical ways to ask better questions, build a shared understanding of a system, and make security thinking accessible without demanding a new identity.

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 Adam Shostack:
→ Adam Shostack

Mentioned in this episode:
→ Start With Why

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

Chapters:
00:00 Rethinking “think like an attacker” with Adam Shostack
01:25 Adam’s security origin story
03:34 Why the hacker mindset instruction can fail
07:15 When security conversations make developers feel excluded
08:02 Rethinking how security is taught
11:22 Giving teams a practical way to participate
14:16 Treating developers as experts in their own systems
17:08 Explaining why security matters
20:37 A developer’s perspective on security thinking
22:26 Applying the approach beyond software teams
25:49 Practical actions for more inclusive security work

Jon McCoy -- The Mindset to Reverse Engineer Dec 21, 2016

Show notes

How does a developer learn to take software apart and use that knowledge to build it more securely? Jon McCoy joins Chris and Robert to discuss reverse engineering, the habits of a breaker, and the connection between offensive research and everyday development. He explains what reverse engineering means, describes experiments with malware and .NET applications, and shows how familiar practices such as unit testing can incorporate security thinking. The conversation explores framework protections, how much coding knowledge penetration testers need, and the role of local developer and security communities. Jon’s advice for newcomers is practical: choose an application, inspect how it works, and learn by experimenting. The episode emphasizes curiosity and repeated hands-on work as foundations for deeper software understanding.

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 Jon Mccoy:
→ Jon McCoy on X
→ Jon McCoy on GitHub

Mentioned in this episode:
→ NDC Conferences
→ DEF CON
→ Metasploit

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

Chapters:
00:00 Reverse engineering with Jon McCoy
01:53 Why a developer became interested in security
02:27 What reverse engineering means
03:24 Teaching security through familiar developer practices
04:06 Adding security thinking to unit tests
05:00 Malware experiments and the breaker mindset
07:56 Helping others learn to break software
11:22 Security in the .NET framework
14:39 How much code should a penetration tester know?
17:45 Learning through developer and security communities
19:47 A first month of learning to reverse engineer
21:26 Resources and hands-on experimentation

Our TOPPODCAST Picks

Follow Us

Stay Connected

The Application Security Podcast

Related Podcasts

Links

Stay Connected