Threat Modeling in Practice

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: You learned threat modeling back in Phase 1.2 as a way of thinking like an attacker. This page takes it from a personal skill to a practiced, repeatable team process — the way an AppSec engineer secures applications at the design stage. Threat modeling is the furthest-“left” security activity there is: it finds flaws before a line of code exists, when fixing them costs only a conversation. Done as a real practice, it is one of the highest-leverage things in all of Application Security.

Part 1: The Problem

Track B so far has secured code — writing it securely (via 5B.1’s framework), reviewing it (5B.2), and testing it automatically (5B.3). But recall a hard truth from Phase 4.3: some of the most serious flaws are not in the code at all — they are in the design. Insecure design cannot be patched cheaply after the fact. Code review and automated testing examine code and running applications — by the time those exist, the design is already fixed.

So an AppSec practice that only secures code has a gap exactly where the most expensive flaws live: the design stage. The activity that fills that gap is threat modeling — and you already learned it, as a thinking skill, in Phase 1.2. This page is about doing it as a practice: a structured, repeatable, team activity that an AppSec engineer leads or facilitates, securing applications before they are built.

This is “shift left” (5B.1) at its furthest extent — security at the design stage, the earliest and highest-leverage point of all.

Part 2: The Concept — Threat Modeling, Recalled and Elevated

Recall threat modeling from Phase 1.2: a structured process answering four questions about a system —

1. What are we building?
2. What can go wrong?
3. What will we do about it?
4. Did we do a good job?

— using assets, threat actors, attack surface, trust boundaries, and the STRIDE checklist (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).

In 1.2 you learned this as a personal thinking skill — and you applied it again in 4.3 to architecture. Track B now elevates it to a practiced, organizational process. The difference:

   THREAT MODELING AS A SKILL (1.2)   THREAT MODELING AS A PRACTICE (5B.4)
   you, thinking like an attacker      a structured TEAM activity
   applied informally                 done repeatably, as process
   a way of reasoning                  embedded in the SDLC's design stage
   ─────────────────────────────────────────────────────────────────────
   Track B makes it something an ORGANIZATION does, reliably, every time.

The underlying method is the same four questions and the same building blocks. What changes is that it becomes: a deliberate activity at the design stage of every significant project; a team effort, not a solo one; repeatable, with consistent approach and output; and facilitated — typically by the AppSec engineer. This page is about making it work as that practice.

Part 3: The Concept — How a Threat Modeling Session Works

In practice, threat modeling is usually done as a collaborative session — bringing the right people together to work through the four questions about a specific design. How such a session works:

Who is in the room. Not just the AppSec engineer. The people who understand the system — developers, architects, sometimes product people — together with the AppSec engineer who brings the security perspective and facilitates. This is essential: the developers and architects know how the system actually works; the AppSec engineer knows how to think about what can go wrong. Threat modeling is collaborative by necessity.

The flow of the session — the four questions, worked as a group:

   1. "WHAT ARE WE BUILDING?"
      The team describes and diagrams the system — components,
      data flows, and (crucially) the TRUST BOUNDARIES (1.2).
      A shared diagram everyone agrees on.

   2. "WHAT CAN GO WRONG?"
      The team works through the system — applying STRIDE at
      each component and trust boundary — to surface threats.
      The structured, group "what could an attacker do here?"

   3. "WHAT WILL WE DO ABOUT IT?"
      For each significant threat, decide a response: a
      mitigation (a security control / design change), or a
      conscious decision to accept a low risk (1.1).

   4. "DID WE DO A GOOD JOB?"
      Review — was the modeling thorough? Revisit as the
      design evolves.

The output. A threat modeling session produces concrete results: the system diagram with trust boundaries, the list of identified threats, and — most importantly — the decided responses (the security requirements and design changes that go back into the project). That output feeds the design — the threats become things the team designs against, before building.

The AppSec engineer’s role in the session is largely facilitation: bringing the security thinking and the STRIDE structure, asking the “what could go wrong here?” questions, keeping the session structured and productive, and ensuring the outputs are captured and acted on. The AppSec engineer does not need to know the system better than its developers — they bring the security lens to people who bring the system knowledge.

Part 4: The Concept — Making Threat Modeling a Repeatable Practice

A single threat modeling session is useful; threat modeling as an established, repeatable practice is transformative. What it takes to make it a practice rather than a one-off:

Do it at the right time — early. Threat modeling belongs at the design stage, before significant code is written — that is the entire point (catching design flaws when they cost a conversation). A threat model done after the system is built has largely missed its value.

Do it consistently. Significant new projects and significant changes get threat-modeled — as a normal, expected part of how the organization designs software, not an occasional special event. Consistency is what makes it a practice.

Keep it appropriately lightweight. A common reason threat modeling fails to stick is being too heavy — too long, too bureaucratic, too document-laden. A practice that is painful gets avoided. Effective threat modeling is right-sized: thorough enough to be valuable, light enough to actually happen regularly. Better a consistent lightweight practice than a heavyweight one done rarely (or never).

Make it a living thing. A design evolves; a threat model should be revisited as it does (the fourth question — “did we do a good job?” — extends to “is this still accurate?”). It is a living document, not a one-time artifact.

Capture and track the outputs. The identified threats and decided responses must be recorded and tracked to completion — otherwise the session produces insight that is never acted on. The threats become security requirements that flow into the project and get verified.

Build the organization’s capability. As with code review (5B.2), the AppSec engineer’s deeper goal is to make threat modeling something the teams can increasingly do themselves — providing the structure, the training, and the facilitation until threat thinking becomes part of how developers and architects naturally design. This is the 5B.1 principle again: AppSec makes secure development a property of the whole organization.

Part 5: The Concept — Why Threat Modeling Is High-Leverage

It is worth being explicit about why threat modeling, done as a practice, is one of the highest-value activities in Application Security.

It is the furthest “left” — and the leverage of “left” is greatest there. 5B.1 established that the earlier a flaw is caught, the cheaper it is to fix, by a large margin. Threat modeling operates at the design stage — earlier than code review, earlier than testing. A flaw it catches costs a design conversation; the same flaw caught later costs a code change, a bug-fix cycle, or an incident. The leverage of catching things early is maximized at the design stage.

It catches what nothing else can. Code review (5B.2) and automated testing (5B.3) examine code and running applications — they cannot find a flaw in a design that has not been built. Insecure design (4.3) — a real OWASP Top 10 category — is precisely the class of flaw that threat modeling catches and the code-focused activities cannot. Without threat modeling, design flaws ship.

It is preventive, not reactive. Threat modeling does not find vulnerabilities in built software — it prevents them from being built in the first place. A threat identified and designed-against never becomes a vulnerability at all.

It builds security thinking. Beyond the specific threats it finds, the practice of threat modeling spreads the attacker mindset (1.2) through the development organization. Developers and architects who regularly threat-model start to design with security in mind by habit — a compounding cultural benefit.

It is comparatively cheap. Threat modeling is mostly thinking and discussion — it needs people and structure, not expensive tooling or long engagements. For the value it delivers, it is inexpensive.

For these reasons, an AppSec engineer who establishes a good threat modeling practice has done something genuinely high-impact — securing applications at the point of maximum leverage, catching the flaw class nothing else catches, and seeding security thinking across the organization.

Part 6: The Concept — Threat Modeling in the Whole AppSec Picture

Threat modeling completes Track B’s coverage of the Secure Development Lifecycle. Seeing how the pieces fit:

   SDLC STAGE        TRACK B ACTIVITY
   ──────────────────────────────────────────────
   Design          → THREAT MODELING (5B.4) ← this page
   Implementation  → secure coding (5B.1) + code review (5B.2)
   Testing         → security testing automation (5B.3)
   ──────────────────────────────────────────────
   Across all of it → working with developers (5B.5)

• It covers the design stage — the one stage the code-focused activities (5B.2, 5B.3) cannot reach. Together, threat modeling and the code activities cover the SDLC end to end.
• It builds directly on Phase 1.2 and 4.3 — the same method, elevated to a practice. Nothing about the technique is new; what is new is doing it as a reliable organizational process.
• Its outputs feed everything downstream — threats identified become security requirements, which become things to build correctly (secure coding), to check in review (5B.2), and to verify in testing (5B.3). Threat modeling sets the security agenda for the rest of the lifecycle.
• It depends on working with developers (5B.5) — it is inherently collaborative, a session with developers and architects. How well the AppSec engineer collaborates determines whether threat modeling is a valued practice or an avoided chore.
• It embodies the AppSec philosophy — preventive, early, collaborative, making secure development the organization’s property.

🔑 The deep lesson: threat modeling is the same method you learned in Phase 1.2, elevated into a practiced, repeatable, collaborative team process at the design stage of the SDLC. It is the furthest-“left” security activity — catching design flaws when they cost only a conversation, catching the flaw class (insecure design) that nothing else catches, preventing vulnerabilities rather than finding them, and seeding the attacker mindset across the organization. Done well, it is one of the highest-leverage things an Application Security engineer does.

📓 Key Terms

🧪 Hands-On Lab

Threat modeling is a thinking-and-collaboration practice — these labs are done on paper / in Notion, on real or realistic systems.

Task 1 — Recall the method. Revisit your Phase 1.2 notes and the threat model you built then. Re-read the four questions, the building blocks, and STRIDE. Confirm the method is solid before elevating it to a practice.

Task 2 — Run a full threat modeling session (solo). Take an application design — one of your own, the Phase 2 lab app, or a realistic example. Work through all four questions thoroughly: diagram it with trust boundaries; apply STRIDE at each component and boundary; decide a response for each significant threat; review. Produce the full output (diagram, threat list, decided responses).

Task 3 — Practice STRIDE coverage. For one component of a system, deliberately work through all six STRIDE letters, forcing yourself to find at least one threat per applicable letter. Practice the structured “what can go wrong” so nothing whole category is missed.

Task 4 — Threat-model a design change. Take an existing system and a proposed change to it. Threat-model just the change — what new threats does it introduce? Practice threat modeling as something done on changes, not only new systems.

Task 5 — Design a lightweight practice. Write out how you would make threat modeling a repeatable, lightweight practice for a development team: when it happens, who is involved, how long, what output, how it stays lightweight enough to actually happen. This is the Part 4 lesson made concrete.

Task 6 — Trace outputs into the SDLC. For the threat model from Task 2, take the decided responses and write how each would flow downstream — into secure coding (5B.1), code review (5B.2), and testing (5B.3). See threat modeling setting the security agenda.

Task 7 — Write a threat modeling note. In Notion, create a “Threat Modeling in Practice” page — the method (from 1.2), how a session works, how to make it a repeatable lightweight practice, and why it is high-leverage. Your facilitation reference.

⚠️ Common Mistakes

• Only securing code, never the design. Code review and automated testing cannot find design flaws. Without threat modeling, insecure design ships — the costliest flaw class.
• Threat modeling too late. Its value is at the design stage, before code. A threat model done after building has largely missed the point.
• Doing it solo when it should be collaborative. Threat modeling needs the people who understand the system and the security lens. It is a team activity by necessity.
• Making it too heavy. A heavyweight, bureaucratic process gets avoided. Right-size it — a consistent lightweight practice beats a heavy one done rarely.
• Not capturing or tracking the outputs. A session that produces insight no one acts on is wasted. Threats become tracked security requirements.
• Treating it as one-time. Designs evolve; threat models should be revisited. It is a living document.
• Skipping STRIDE structure. “What could go wrong?” with a blank page misses categories. STRIDE ensures coverage.

✅ Recap & What’s Next

• Threat modeling is the Phase 1.2 method elevated into a practiced, repeatable, collaborative team process at the design stage — the one SDLC stage code review and automated testing cannot reach.
• A session works the four questions (what are we building / what can go wrong / what will we do / did we do well) with the people who know the system plus the AppSec engineer facilitating; its outputs become security requirements feeding the rest of the lifecycle.
• It is high-leverage — the furthest “left,” catching design flaws cheaply, preventing vulnerabilities, and seeding security thinking across the organization — and it must be kept lightweight and consistent to stick.

Next (5B.5): Every page of Track B has pointed to one thing: AppSec works only if developers build securely, and that depends entirely on collaboration. Page 5B.5 is working with developers — the human core that determines whether everything else in this track actually succeeds.