Threat Modeling for Developers (How To)

Threat modeling has a reputation for being complicated, full of diagrams, and requiring long meetings. In reality, most developers already do it, they just don't realize it. The difference is that doing it intentionally helps you catch security problems before they become security incidents.

This episode is sponsored by Maze.

In this episode of DevSec Station, Tanya Janca breaks threat modeling down into a simple five-step process that any developer can use while designing a feature. You'll learn how to identify what you're protecting, where trust boundaries exist, and how to ask a few simple questions that uncover security issues early; before they're expensive to fix. 

You'll learn:

•  why threat modeling is can be simpler than most people think 
•  how to threat model a feature in about fifteen minutes 
•  how to identify assets, entry points, and trust boundaries 
•  three practical misuse questions that reveal common insecure design mistakes 
•  how to turn identified threats into concrete security controls 

Tanya walks through a practical, developer-friendly approach to threat modeling that doesn't require diagrams, special tools, or security approval. Instead, she demonstrates how asking a handful of structured questions during design helps developers build more secure software from the very beginning. 

If you do just one thing after listening to this episode:

Threat model one feature you're currently building.

Follow these five simple steps:

•  describe the feature in one sentence 
•  identify what you're protecting 
•  identify the entry points and trust boundaries 
•  ask what could go wrong if the feature is misused or fails unexpectedly 
•  identify at least one security control that should be added or verified 

Write your notes somewhere your team can see them; a ticket, pull request, markdown file, or design document. You don't need a formal process. You just need to think about security before the code exists.

DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.

Follow Tanya:

• https://shehackspurple.ca
• https://youtube.com/@shehackspurple
• https://newsletter.shehackspurple.ca
• https://linkedin.com/in/tanya-janca
• https://tanyajanca.com

This episode is sponsored by Maze.

One of the biggest problems in security right now is that every vulnerability scanner says everything is critical, and honestly, no one has time for that.

Maze uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment, not just theoretically scary.

Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams need right now.

Learn more about Maze https://mazehq.com/devsec

Episode Transcript

SPEAKER_00 (00:00):
Let's talk about threat modeling.
If that phrase makes you picturewhiteboards and diagrams and
never-ending meetings, I get it.
But here is the actual truth.
Most developers do threatmodeling all the time.
We just don't call it that.
Today, I want to show you how todo it on purpose in about 15

(00:24):
minutes.
Hi, I'm Tanya Jenka, also knownas SheHexPurple.
Welcome to DevSecStation, apodcast for software developers
who want to build more securesoftware.
In each episode, I'll share ashort practical lesson about
secure coding, softwaresecurity, and how to build safer

(00:44):
systems without slowingdevelopment down.
You can jump in at any episode,at any time.
No homework required.
This episode is sponsored byMAES.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical, and

(01:04):
honestly, no one has time forthat.
MAZES uses AI agents toinvestigate vulnerabilities in
context, so you can focus on theissues that are actually
exploitable in your environmentand not just theoretically
scary.
Their AI agents also generateand prioritize fixes that knock
out multiple vulnerabilities atonce, which is honestly the kind

(01:26):
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.
If you're building a newfeature, adding an endpoint,
integrating a service, orchanging how data flows through
your system, this episode is foryou.

(01:47):
So for your information, you donot need security approval,
special tooling, or a diagramapp or tool to do this.
You can just start now.
Threat modeling soundscomplicated because we wrapped
it in process, but at its core,it's actually very simple.
Threat modeling is justintentionally thinking about

(02:10):
what you're building, whatyou're protecting, and how it
could be misused.
That's it, seriously.
The goal is not to predict everysingle possible attack, it's to
notice obvious problems beforethey turn into security
incidents and then fix them.
Developers do this informally,literally, all the time.

(02:34):
You add a new endpoint and youthink, hmm, should this be
authenticated?
I should add authentication.
You store something new in thedatabase and you think, is this
sensitive?
You integrate a service and youthink, oh, what's gonna happen
if this goes down?
If this goes down, then what?
What should I do?
That's literally you threatmodeling.
The difference is that when wedo it casually, it's very easy

(02:58):
to miss things.
But when we do it intentionally,usually we catch all the
important stuff.
So how about we try it?
I'm gonna give you a simple wayto threat model one feature
without a diagram.
Okay, are you ready?
Step one, define the thing.
Write down on a piece of paperor type it out what you're

(03:21):
building in just one sentence.
So for example, I'm building anendpoint that lets users update
their profile.
If you cannot describe a featuresimply, that's already a signal
that you probably have a problemhere.
Okay.
Step two, let's identify whatyou are protecting.
Ask yourself, what data isinvolved?

(03:43):
Is it sensitive?
Who should be allowed to do thisaction?
Would it be bad if somethingwent wrong and what would that
be?
Step three, identify entrypoints and trust boundaries.
Ask yourself, where does thisdata come from?
Where does it cross fromuntrusted into trusted?

(04:04):
Where do we rely onauthentication and
authorization?
I have a tip for you.
These are the same places youlook at during a secure code
review.
Remember that from the lastepisode?
Okay, step four.
Ask three misuse questions.
You don't need a long list, justask a few things such as, what
if someone who shouldn't do thistries to do it anyway?

(04:27):
What if this input is maliciousor otherwise unexpected?
What happens if this fails in areally weird way?
If you can answer thosequestions, you're doing threat
modeling.
Step five, decide what needs acontrol.
So for anything that you feeluncomfortable about, you need to

(04:47):
decide, do we already have acontrol to protect against this?
And if not, does one need to beadded?
This is where threat modelingturns from just a discussion
into action.
We don't just want to identifythreats, we want to defend
against the ones that actuallyscare us.
Shall we do our bad better bestthing now?
I think we should.

(05:09):
A bad approach for threatmodeling is assuming security
testing will just catcheverything later.
It pushes risk downstream, wherefixes are more expensive, and it
might get missed.
A slightly better approach isthinking about threats casually
while building.
This helps, but it'sinconsistent, and it depends
largely on memory, which, as weknow, is not a reliable way to

(05:32):
do things.
The best approach is threatmodeling each new app or feature
on purpose.
One feature can be 15 minutes, asingle page of notes, done.
When you do this regularly,secure design becomes a habit.
If you do just one thing afterthis episode, please do this.
Threat model one feature thatyou are currently working on.

(05:55):
Use the five steps that we justcovered.
Write it down somewhere thatyour team can see it.
So you could put it in a PRdescription, a ticket, or a
simple markdown file, whateverit is that makes sense to you,
but so it won't disappear.
You don't need to solveeverything.
Just identify one place where acontrol is missing or unclear
and then fix it.

(06:16):
That's a huge win.
Threat modeling is not securitytheater.
It really can create true value.
It's a way to ensure fewersurprises happen to you later.
When developers do itthemselves, security stops
becoming a blocker for you.
And instead, security starts tobe part of what you think of as

(06:39):
good design.
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with
a friend, or leave a review.
It helps more people discoverthe show.
If you'd like to learn more, I'mTanya Jenka, also known as
SheHacksPurple.
And I teach secure codingtraining for software

(07:00):
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.