The Application Security Podcast

Latest Episodes:

Pete Chestna -- SAST, DAST, and IAST. Oh My! Feb 15, 2018

Show notes

Buying more scanners does not automatically create a better application security program. Pete Chestna explains SAST, DAST, IAST, runtime protection, and composition analysis, then connects those technologies to the developers who must use their results. Starting from a listener’s question about false positives, he explores speed, accuracy, workflow integration, and the difference between a real flaw and an accepted risk. Pete offers a gradual approach for a new program: understand the application inventory, establish a baseline, train developers, and improve one weakness category at a time. For more mature teams, he discusses combining metrics, preventing new vulnerabilities, and retaining human testing where tools fall short. His central argument is that effective programs develop secure developers, with secure software following from that capability.

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 Pete Chestna:
→ Pete Chestna on LinkedIn

Mentioned in this episode:
→ Veracode
→ Brakeman

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

Chapters:
00:00 Making sense of AppSec testing tools
00:47 Pete’s security origin story
03:01 SAST, DAST, IAST, RASP, and SCA explained
07:25 Tool maturity and deployment models
09:08 Developer concerns: speed, accuracy, and integration
12:51 Compensating controls and risk decisions
14:18 Security knowledge and developer motivation
16:37 Starting a new AppSec program
18:05 Baseline measurement before enforcement
20:34 Improving one weakness category at a time
23:46 Preventing new vulnerabilities
25:06 The goal is secure developers
26:43 Combining data in a mature program
28:43 Where penetration testing still adds value
31:18 Open-source testing tools and tradeoffs

Irene Michlin -- We Are Not Making It Worse Feb 09, 2018

Show notes

When a team is already ten sprints into a product, stopping to threat model everything can sound impossible. Irene Michlin explains an incremental approach: examine the next change, keep the discussion bounded, and make sure new work does not make the system worse. Drawing on her experience as a developer and security practitioner, she describes how short exercises build confidence and how threat modeling improves testing and shared architectural understanding. Chris and Robert explore what to do about existing security debt, how to record threats in the team’s normal work tracker, and where security stories and acceptance criteria fit. Irene also discusses whiteboards, the Microsoft Threat Modeling Tool, and STRIDE, emphasizing a repeatable thinking habit that can keep pace with agile development.

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 Irene Michlin:
→ Irene Michlin on LinkedIn

Mentioned in this episode:
→ Microsoft Threat Modeling Tool

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

Chapters:
00:00 Incremental threat modeling with Irene Michlin
01:21 Irene’s path from development into AppSec
05:05 Security products still need product security
06:41 The wider benefits of threat modeling
09:04 Starting with the next sprint’s changes
11:24 Handling existing security debt
13:46 Teaching a lightweight modeling process
17:21 Using a timer to build confidence
18:28 Keeping threats in the team’s work tracker
20:19 Security stories and acceptance criteria
23:16 Defining done for security work
24:24 Choosing tools for fast threat modeling
27:06 Using STRIDE as a foundation
29:07 Adding context-specific threats

Bill Sempf -- Insecure Deserialization Feb 02, 2018

Show notes

What happens when data arriving at an application is allowed to recreate objects and trigger unexpected behavior? Bill Sempf joins Chris and Robert to unpack insecure deserialization, a new category in the 2017 OWASP Top 10. He explains serialization through familiar programming examples and describes the research questions that drew him into the topic. The conversation follows attacks across language ecosystems, discusses the possible impact of accepting untrusted serialized objects, and considers ways to reduce exposure. Bill also shares how an assessor might recognize serialized data, investigate application behavior, and use an intercepting proxy during testing. Alongside his work in the .NET security community, this archive conversation captures practitioners working through a difficult vulnerability class and debating the limits of their tools and assumptions.

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 Bill Sempf:
→ Bill Sempf’s developer profile

Mentioned in this episode:
→ OWASP Top 10 project repository
→ ZAP
→ Burp Suite

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

Chapters:
00:00 Insecure deserialization with Bill Sempf
01:14 Bill’s security origin story
06:54 Filling gaps in .NET security guidance
08:05 Why deserialization entered the 2017 Top 10
10:48 Researching examples across platforms
12:22 Serialization and deserialization explained
15:54 The impact of malicious serialized objects
17:35 Reducing deserialization risk
23:09 ViewState and framework considerations
24:37 Debating .NET and language-specific behavior
27:29 Recognizing serialized data during an assessment
28:53 Investigating with intercepting proxies
30:31 What testing tools can find

Chris and Robert -- Security Champions Jan 26, 2018

Show notes

What is a security champion, and how can an organization build a program that lasts? Chris and Robert compare definitions, alternative titles, and the qualities that make a champion effective. They explain why interest and influence often matter more than formal authority, why champions can come from development, testing, product, or other roles, and how the network supports a secure development lifecycle. The conversation connects champions to security culture, two-way communication, and scalable expertise. It also covers program mechanics: role definitions, goals, training, recognition, management support, and a dependable operating cadence. Rather than treating champions as unpaid security staff, Chris and Robert describe a community that helps teams make better decisions while keeping responsibility shared across the organization.

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:
→ Do you have Security Champions in your company?

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

Chapters:
00:00 All things security champions
01:18 How the idea has evolved
03:19 A programmatic definition
05:40 Champions in the secure development lifecycle
07:21 Alternative names and the meaning of champion
10:06 Who makes an effective champion
12:32 Start with genuine interest
14:15 Influence across teams
16:52 Champions as a driver of security culture
18:57 Two-way communication and community
21:04 Management support and recognition
23:30 Role definitions, goals, and training
25:05 Building a sustainable program

Kevin Greene -- Shifting left Jan 19, 2018

Show notes

Moving a security scanner earlier in the pipeline is not the same as building security into development. Kevin Greene explains what shifting left should mean and why rapid delivery exposes weaknesses in both security strategy and testing tools. Drawing on his work across industry, government research, and MITRE, he argues for capturing practitioners’ experience so teams can apply it repeatedly rather than depend on individual intuition. Chris and Robert explore that idea through threat modeling, architectural decisions, and adversary knowledge. Kevin discusses the Common Architectural Weakness Enumeration, CAPEC, and ATT&CK as ways to connect design choices with realistic failure and attack scenarios. The conversation challenges teams to improve the thinking behind their automation and bring developers usable security knowledge before problems become expensive defects.

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 Kevin Greene:
→ Kevin E. Greene’s website

Mentioned in this episode:
→ MITRE CAPEC
→ MITRE ATT&CK

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

Chapters:
00:00 Shifting left with Kevin Greene
02:05 Kevin’s security origin story
05:43 Security across government and industry
07:39 What shifting left should mean
11:42 Why DevOps security efforts struggle
12:40 Strategy and the limits of testing tools
17:04 What it means to codify intuition
22:02 Turning experience into threat modeling knowledge
24:24 Architectural decisions and CAWE
26:55 Using CAPEC and ATT&CK
29:00 Bringing adversary knowledge into development

Conclusion: OWASP is for everyone Dec 05, 2017

Show notes

Why does OWASP matter beyond its famous Top 10 list? The Season 2 finale revisits guests who demonstrate the breadth of the foundation’s work. John Melton explains AppSensor, Andrew van der Stock and Brian Glas discuss Top 10 governance and data, Mike Goodwin walks through Threat Dragon, Jim Manico and Katy Anton explain Proactive Controls, Tanya Janca and Nicole Becher introduce DevSlop, and Tin Zaw describes ModSecurity. The clips connect guidance, tools, standards, training applications, and community participation. Chris and Robert frame the episode as an invitation: OWASP is not reserved for established security experts. Developers, testers, project leaders, documenters, and newcomers can all learn from the projects and contribute to making them more useful.

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 AppSensor
→ OWASP Threat Dragon
→ OWASP Top 10 Proactive Controls
→ OWASP DevSlop
→ Pixi (DevSlop)
→ OWASP ModSecurity Core Rule Set
→ Microsoft Threat Modeling Tool

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

Chapters:
00:00 Season 2 and the breadth of OWASP
00:50 John Melton on OWASP AppSensor
04:55 Andrew van der Stock and Brian Glas on Top 10 governance
09:54 Balancing data for the OWASP Top 10
12:55 Mike Goodwin on OWASP Threat Dragon
14:24 The Threat Dragon workflow
17:14 Jim Manico and Katy Anton on Proactive Controls
23:12 Tanya Janca and Nicole Becher on DevSlop
27:25 Tin Zaw on ModSecurity
30:19 OWASP is for everyone

Brian Andrzejewski -- Containers Again Oct 24, 2017

Show notes

Containers make deployment repeatable, but insecure images, excessive privileges, and unmanaged secrets can travel with them. Brian Andrzejewski shares lessons from introducing containers in a government environment and developing a more deliberate security approach. He explains why early choices such as SSH access need reconsideration, how orchestration changes operations, and why teams need policies for the images they trust. Chris and Robert explore running without unnecessary privileges, read-only filesystems, vulnerability checks, and the difference between protecting the container infrastructure and the application inside it. Brian also discusses secrets, maturity models, and the role of benchmarks and guidance. The conversation offers a practical progression from experimenting with Docker to operating containers with consistent controls, visible dependencies, and a plan for ongoing maintenance.

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 Brian Andrzejewski:
→ Brian Andrzejewski on LinkedIn

Mentioned in this episode:
→ Docker
→ Docker Hub
→ CIS Docker Benchmark
→ NIST SP 800-190 — Application Container Security Guide

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

Chapters:
00:00 Container security with Brian Andrzejewski
00:46 Brian’s security origin story
03:33 Introducing containers in a government environment
05:33 SSH access and disposable containers
06:28 Moving toward orchestration
07:47 Policies for trusted container images
11:30 Privileges and read-only filesystems
12:55 A maturity model for container security
16:43 Dependency inventory and CVE checks
17:56 Rebuilding and checking running containers
19:53 Application security inside containers
22:32 Handling secrets
23:36 Lessons for teams getting started
26:43 Benchmarks and resources

Tin Zaw -- ModSecurity and #AppSec Oct 17, 2017

Show notes

A web application firewall can buy time during a vulnerability crisis, but only if somebody understands and maintains its rules. Tin Zaw explains ModSecurity and the Core Rule Set, starting with where a WAF sits between users and an application. He distinguishes the rule engine from the rules themselves, describes embedded and proxy deployments, and explains how detection, blocking, and logging serve different purposes. The conversation uses the Apache Struts vulnerabilities as an example of virtual patching while a team prepares a software update. Chris and Robert also ask about writing signatures, sharing rules, tuning false positives, and the risks of adding another component to the stack. Tin closes with practical starting points for learning and contributing to open-source application protection.

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 Tin Zaw:
→ Tin Zaw on LinkedIn

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

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

Chapters:
00:00 ModSecurity and application security with Tin Zaw
01:11 Tin’s security origin story
02:33 Contributing to OWASP projects
03:59 What a web application firewall does
04:42 Embedded and proxy WAF deployments
06:32 The ModSecurity engine and Core Rule Set
08:27 Using and extending security rules
09:31 Detection, blocking, logging, and virtual patching
11:19 Responding to an Apache Struts vulnerability
13:18 Writing signatures from vulnerability information
14:40 Sharing rules with the community
15:36 Tuning false positives and maintaining the WAF
17:37 Why choose an open-source WAF?
18:30 Managing the WAF’s own attack surface
19:59 Getting started and finding resources

Aditya Gupta -- The Exploitation of IoT Oct 10, 2017

Show notes

Why can an IoT product look secure in one component and still fail as a complete system? Aditya Gupta, founder of Attify, joins Chris and Robert at AppSec USA to examine the gaps between hardware, firmware, radio communications, mobile applications, and web dashboards. He explains how fragmented development teams and unfamiliar protocols create security blind spots, and why authentication and secure design need attention before devices ship. The conversation covers resource constraints, firmware updates, physical access, and the way extracting information from one device can enable attacks against many others. Aditya also discusses practical learning resources and encourages developers to understand their entire product architecture rather than assuming that securing individual pieces will secure the whole.

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 Aditya Gupta:
→ Aditya Gupta and Attify

Mentioned in this episode:
→ Attify
→ OWASP IoT Top 10

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

Chapters:
00:00 The exploitation of IoT with Aditya Gupta
00:46 Aditya’s path from mobile security to IoT
02:03 Defining the Internet of Things
02:58 Where IoT development goes wrong
04:03 Security gaps between components and teams
05:48 Authentication failures and secure design
07:03 Practical security steps for developers
07:58 Protocol fragmentation and resource constraints
09:10 Designing the complete IoT system
11:17 Updating devices after deployment
17:30 How physical access exposes larger attack paths
20:48 Resources for learning IoT security

Jim Manico and Katy Anton -- The Future of the OWASP Proactive Controls Oct 03, 2017

Show notes

Where should the OWASP Proactive Controls go after giving developers a concise defensive counterpart to the Top 10? Project leaders Jim Manico and Katy Anton discuss the document’s origins, intended audience, and plans for its next version. They explore how much implementation guidance belongs in a short list, whether data should shape future priorities, and how the controls relate to ASVS, cheat sheets, and other OWASP resources. The guests consider language-specific guidance and a future in which developers can move from a high-level control to concrete examples for their platform. Chris also asks how the community can review and contribute. The conversation captures an open-source project deciding how to remain approachable while becoming more useful to practicing software engineers.

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 Jim Manico and Katy Anton:
→ Jim Manico on LinkedIn
→ Katy Anton on LinkedIn
→ OWASP Proactive Controls

Mentioned in this episode:
→ OWASP Proactive Controls
→ OWASP ASVS
→ OWASP Cheat Sheet Series
→ NIST Digital Identity Guidelines

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

Chapters:
00:00 The future of OWASP Proactive Controls
02:43 A defensive counterpart to the Top 10
04:46 The project’s origin story
06:10 Priorities for the next version
09:11 Whether data should shape the controls
12:39 Mapping to ASVS and other projects
14:25 A five-year vision for the project
16:24 Language-specific developer guidance
17:24 How the community can contribute
18:50 Final thanks and next steps

Our TOPPODCAST Picks

Follow Us

Stay Connected

The Application Security Podcast

Related Podcasts

Links

Stay Connected