1. What is Threat Modeling?

In the simplest words:

Threat modeling is the process of looking at an application before or during development and asking: “How can this system be attacked, what could go wrong, and how can we prevent it?”

Think of it as a security review of your application design.

Normal development thinking

A developer may think:

“How do I make this feature work?”

Threat modeling adds:

“How could someone misuse or attack this feature?”

2. Simple Example

Imagine you’re building an online shopping application:

Customer
   |
   ↓
Web Application
   |
   ↓
Database

A developer thinks:

Customer logs in → browses products → places order → data goes into database.

A security engineer asks:

What if someone sends a fake request?

What if someone steals another user’s session?

What if someone modifies the price?

What if someone accesses the database directly?

What if someone sends thousands of requests and brings the application down?

Those questions are threat modeling.

3. Threat Modeling in One Sentence

Remember this:

Threat Modeling = Understand the system → Identify what can go wrong → Assess the risk → Decide how to protect it.

4. When Should We Do Threat Modeling?

Ideally, before the application is built.

Requirement
     ↓
Architecture
     ↓
🛡️ Threat Modeling
     ↓
Development
     ↓
Testing
     ↓
Deployment
     ↓
Production

But you can also perform it on an existing application.

It’s particularly useful when:

• Designing a new application
• Adding a major feature
• Adding a new API
• Introducing a payment system
• Adding a third-party service
• Changing authentication
• Moving to cloud/Kubernetes
• Handling sensitive information
• Changing architecture

5. What is OWASP Threat Dragon?

Now introduce the tool.

OWASP Threat Dragon is an open-source tool that helps you perform and document threat modeling visually.

The important point:

Threat Dragon does not replace threat modeling.

It helps you draw the system, identify threats, document them, and track mitigations.

Think:

Threat Modeling
      +
Threat Dragon
      ↓
Visual + Documented Threat Model

6. Why Not Just Use Excel?

Excellent question—and this should actually be discussed in a good tutorial.

You absolutely can use Excel, Notion, Markdown, Miro, etc.

For example:

That’s perfectly valid.

But when the architecture becomes larger:

Internet
   ↓
CloudFront
   ↓
WAF
   ↓
ALB
   ↓
EKS
 ┌─┼───────────────┐
 ↓ ↓               ↓
API Redis          Worker
 ↓                  ↓
RDS                S3
 ↓
Payment Gateway

visual modeling becomes much more useful.

Threat Dragon helps you see the system and the security boundaries, rather than just maintaining a list.

7. The Core Threat Modeling Process

A practical gold-standard workflow is:

1. Understand the system
          ↓
2. Draw the architecture
          ↓
3. Identify trust boundaries
          ↓
4. Identify assets/data
          ↓
5. Identify threats
          ↓
6. Analyze risk
          ↓
7. Define mitigations
          ↓
8. Document
          ↓
9. Review
          ↓
10. Update when architecture changes

This is more important than learning the Threat Dragon buttons.

8. Step 1 — Understand the System

Before opening Threat Dragon, understand what you’re building.

For example:

Online Banking Application

User
 ↓
Web Application
 ↓
Authentication Service
 ↓
Banking API
 ↓
Database

Ask:

• Who uses the system?
• What data does it handle?
• What are the important components?
• Which systems are external?
• Where does sensitive data travel?
• Who can access what?

9. Step 2 — Draw the System

Now create a Data Flow Diagram (DFD).

For example:

                    Internet
                       |
                       ↓
                   [User]
                       |
                       ↓
                 [Web Server]
                       |
                       ↓
                    [API]
                    /   \
                   /     \
                  ↓       ↓
              [Database] [Payment API]

This is where Threat Dragon becomes useful.

10. Step 3 — Identify Trust Boundaries

This is one of the most important concepts.

A trust boundary is a place where the level of trust changes.

For example:

           INTERNET
              |
================================
        TRUST BOUNDARY
================================
              |
          Application
              |
================================
        TRUST BOUNDARY
================================
              |
           Database

For example:

Internet → Application

The Internet is untrusted.

Your application cannot simply trust everything coming from the Internet.

11. Step 4 — Identify Important Assets

Ask:

“What are we trying to protect?”

Examples:

• Passwords
• Personal information
• Credit-card information
• API keys
• Authentication tokens
• Customer records
• Business data
• Source code
• Financial transactions

These are your assets.

12. Step 5 — Identify Threats

Now ask:

“What could an attacker do?”

This is where STRIDE becomes useful.

STRIDE

Example

For:

User → Login API

you might identify:

Spoofing

Attacker obtains another user’s credentials and logs in.

Mitigation:

MFA + strong authentication + session controls.

13. Step 6 — Analyze the Risk

Not every threat has the same importance.

For example:

The purpose isn’t to create 100 threats just because you can.

The goal is:

Find the threats that actually matter and prioritize them.

14. Step 7 — Define Mitigations

For every meaningful threat, ask:

“What are we going to do about it?”

Example:

Threat:
SQL Injection

Risk:
High

Mitigation:
- Parameterized queries
- ORM
- Input validation
- Least-privilege database account
- Security testing

Another:

Threat:
Credential theft

Mitigation:
- MFA
- Password hashing
- Secure session management
- Rate limiting
- Account lockout/risk controls

15. Step 8 — Put It Into Threat Dragon

Now the tool becomes useful.

You create your model and add components such as:

User
Process
Data Store
External Entity
Data Flow
Trust Boundary

Then document threats against the relevant components or data flows.

For example:

                 User
                   |
                   | HTTPS
                   ↓
              ┌─────────┐
              │   API   │
              └────┬────┘
                   |
                   | SQL
                   ↓
              ┌─────────┐
              │   RDS   │
              └─────────┘

Threat:
SQL Injection

Mitigation:
Parameterized queries

Now you have an architecture + threats + mitigations in one model.

16. What Threat Dragon Should NOT Become

This is very important for a gold-standard tutorial.

Don’t teach:

“Every project must have a 200-page threat model.”

❌ That’s bureaucracy.

Instead:

Threat modeling should be proportional to the risk and complexity of the system.

A small internal application might need:

30-minute threat-modeling exercise
+
simple checklist

A large banking platform might require:

Multiple architecture diagrams
+
trust boundaries
+
detailed threat analysis
+
risk assessment
+
mitigation tracking
+
security review

17. The DevSecOps Connection

Threat modeling fits very early in DevSecOps.

                 DEVSECOPS

Plan
 ↓
Requirements
 ↓
🏰 Threat Modeling
 ↓
Design
 ↓
Code
 ↓
SAST
 ↓
SCA
 ↓
Build
 ↓
Container Security
 ↓
IaC Security
 ↓
DAST
 ↓
Deploy
 ↓
Runtime Security
 ↓
Monitoring

Notice something important:

Threat modeling happens before most security testing.

Why?

Because testing can find vulnerabilities in an implementation.

Threat modeling can identify security problems in the design itself.

18. Threat Modeling vs SAST vs SCA

This distinction is excellent for students:

So:

Threat Modeling
      ↓
Find design-level risks

SAST
      ↓
Find code-level risks

SCA
      ↓
Find dependency risks

DAST
      ↓
Find runtime/application risks

They complement each other.

19. The Golden Mental Model

If you’re teaching this, I’d make students remember this:

             THREAT MODELING

          "What are we building?"
                    ↓
          "What do we need to protect?"
                    ↓
          "How could it be attacked?"
                    ↓
          "What is the risk?"
                    ↓
          "How will we mitigate it?"
                    ↓
          "Did we document it?"
                    ↓
          "Did the architecture change?"
                    ↓
                 Repeat

And finally:

Threat Dragon is the tool. Threat modeling is the security practice.

That’s the distinction I’d make very clear in a professional DevSecOps course.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.