Choose a threat modeling method and turn its findings into tests

Threat modeling means examining a model of a system to find security and privacy problems while they are still cheap to fix. The Threat Modeling Manifesto organizes the work around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. STRIDE, attack trees, LINDDUN and PASTA are different ways of answering the second question, with more or less structure around the other three.

Each question should leave something behind. NIST SSDF 1.1 (SP 800-218) asks teams to use risk modeling such as threat modeling (PW.1.1) and to track the resulting requirements, risks and design decisions (PW.1.2). OWASP Top 10:2025 A06 Insecure Design recommends threat modeling for authentication, access control, business logic and other key flows, done during refinement rather than after release.

No method finds everything, and the SEI comparison of twelve methods recommends choosing by the project's needs and combining methods when one view is not enough. A technical design review starts with STRIDE; a fraud path calls for an attack tree; personal data adds LINDDUN; a risk decision that leadership must fund may justify PASTA.

A data-flow diagram has four kinds of element plus boundaries. External entities are people and systems you do not control. Processes are code you run. Data stores hold data at rest, including queues, buckets and logs. Data flows are the arrows between them. A trust boundary marks where the level of trust or privilege changes: internet to API, service to database, your cloud account to a SaaS provider, or a sandbox around a file parser.

Microsoft's SDL guidance gives useful sanity checks. Data does not appear from nowhere, so every store needs a process that writes it and one that reads it. Data never moves straight from a person to a disk; a process sits between them. Collapse similar elements inside one boundary, and use a context diagram plus detail diagrams instead of one huge picture. Add the paths teams forget: background jobs, admin and support tools, and third-party callbacks.

Keep the model next to the code. OWASP pytm describes the diagram in Python and generates the diagram and candidate threats from it. OWASP Threat Dragon and the Microsoft Threat Modeling Tool are diagram-first alternatives. The model below describes the worked example used in the rest of this guide.

#!/usr/bin/env python3
# Expense-claims API threat model (pytm 1.4.0, Python 3.11+)
from pytm import (TM, Actor, Boundary, Classification, Data, Dataflow,
                  Datastore, ExternalEntity, Process)

tm = TM("Expense claims API")
tm.description = "Employees submit claims with receipts; managers approve; payroll pays."
tm.isOrdered = True

internet = Boundary("Internet")
cloud = Boundary("Company cloud account")
sandbox = Boundary("Receipt parsing sandbox")
payroll_net = Boundary("Payroll provider")

employee = Actor("Employee", inBoundary=internet)
manager = Actor("Manager", inBoundary=internet)
payroll = ExternalEntity("Payroll provider API", inBoundary=payroll_net)

api = Process("Expenses API", inBoundary=cloud)
worker = Process("Receipt worker", inBoundary=sandbox)
claims_db = Datastore("Claims DB (claims, approvals, audit)", inBoundary=cloud,
                      storesPII=True, maxClassification=Classification.RESTRICTED)
receipts = Datastore("Receipt object store", inBoundary=cloud, storesPII=True)

claim = Data("Claim and receipt image", classification=Classification.RESTRICTED)

Dataflow(employee, api, "Submit claim + receipt", protocol="HTTPS", data=claim)
Dataflow(api, receipts, "Store receipt")
Dataflow(api, claims_db, "Write claim version")
Dataflow(manager, api, "Approve claim version", protocol="HTTPS")
Dataflow(receipts, worker, "Read receipt for extraction")
Dataflow(worker, claims_db, "Write extracted fields")
Dataflow(api, payroll, "Payout instruction", protocol="HTTPS")
Dataflow(payroll, api, "Payout status webhook", protocol="HTTPS")

if __name__ == "__main__":
    tm.process()

STRIDE names six threat types, each the violation of one property: spoofing breaks authentication, tampering breaks integrity, repudiation breaks non-repudiation, information disclosure breaks confidentiality, denial of service breaks availability, and elevation of privilege breaks authorization. Microsoft's per-element chart limits which questions to ask of each element type, which keeps a session moving.

Treat the letters as prompts and argue about the threat, not its category. A small diagram yields dozens of candidates, many already covered by platform controls such as TLS everywhere; record those once as assumptions. If a data store holds audit logs, ask repudiation questions too, because whoever can edit the log can erase the evidence. For the patterns that recur per element type, such as caller-supplied identity on a boundary flow or a missing tenant filter on a shared store, use /domains/appsec/threat-modeling/threat-pattern-library/.

STRIDE per interaction walks each interaction, meaning an origin, a destination and what passes between them, instead of each element. It suits threats that exist only in the combination. A payout webhook is only as trustworthy as the sender check on that flow, which /domains/appsec/secure-features/verify-webhook-deliveries/ covers. An approval means something only if it binds to exactly what the approver saw, which neither the manager nor the API owns on its own.

A replicated controlled experiment with student teams found no significant difference in precision or productivity between the two variants (Mbaka and Tuma, 2022). Choose by fit: per element for coverage of a new component, per interaction for integrations, protocols and approval chains.

An attack tree puts the attacker's goal at the root and the ways to reach it underneath. OR nodes are alternatives; AND nodes are steps that must all succeed. Schneier's 1999 description assigns values to the leaves and propagates them upward: an OR node takes its easiest or cheapest child, and an AND node needs every child, so costs add up. Use a tree for fraud, account takeover or signing-key theft, where attackers chain steps that a per-element pass lists separately.

Read the tree again after the fixes. In this example only the collusion branch survives the technical controls. That is a business decision, such as a second approver above a limit plus finance sampling, recorded as an accepted risk with an owner.

GOAL: Get paid for money that no approver agreed to pay   [OR]
+-- 1. Approve your own claim                                 [OR]
|   +-- 1.1 Call /approve on your own claim                   T2
|   +-- 1.2 Create the claim with status=approved             T3
+-- 2. Change the amount after approval                       [AND]
|   +-- 2.1 Approval does not record the version reviewed     T4
|   +-- 2.2 Edits are still accepted after approval           T4
+-- 3. Trigger a second payout                                [AND]
|   +-- 3.1 Post a forged "payout failed" webhook             T1
|   +-- 3.2 Retry logic resends without asking the provider   T1
+-- 4. Collude with the approving manager (insider)           T8

Leaf value: possible without insider help? (yes/no)
OR node = yes if any child is yes. AND node = yes only if all children are yes.
After T1-T4 are fixed, only branch 4 is still possible, and it needs an insider.

STRIDE asks whether an attacker can break a security property. It does not ask whether the system collects, links or exposes personal data while working exactly as designed. LINDDUN, from KU Leuven's DistriNet group, covers seven privacy threat types: linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, and non-compliance. Its non-repudiation is a privacy harm, being unable to deny something attributed to you, which is the opposite viewpoint from STRIDE's.

LINDDUN GO is a deck of 33 threat cards, redesigned in 2024, for a lean team session. LINDDUN PRO walks each interaction in the diagram, considering sending, transfer and receipt, with threat trees and a mapping table. Choose PRO when you need systematic, documented coverage.

Applied to receipts: images show card digits, places and sometimes health-related purchases, so keeping them forever is data disclosure and likely non-compliance. An export of merchant, time and place per employee allows linking and tracking. Employees who cannot see or correct what is kept face unawareness and unintervenability. Responses: extract only needed fields, mask card numbers, set a retention period (/domains/identity-crypto/privacy/data-minimization-retention/ covers how), limit access to approvers and finance reviewers, aggregate exports and publish a notice.

PASTA, the Process for Attack Simulation and Threat Analysis, was developed by Tony UcedaVélez in 2012. It is risk-centric and runs in seven stages: define objectives, define technical scope, decompose the application, analyze threats, analyze vulnerabilities and weaknesses, model attacks, and analyze risk and impact. It draws on business impact analysis, threat intelligence and existing vulnerability data, and it uses data-flow diagrams in stage three and attack trees in stage six.

The cost is time and people: business owners, operations and architects take part, and the output is a ranked risk register, not a quick list. Use it for a payments platform or a regulated product where leadership must weigh spending against expected loss, and keep STRIDE for feature work. In the expense system, stage one would put a figure on fraud loss and stage seven would rank the surviving fraud paths against it.

Agile teams get most of the value from short, frequent sessions scoped to one change. Hold one in refinement when a story matches any trigger below. Invite the developer, a tester, the product owner and a security champion; sketch the change on the story's diagram, walk STRIDE over the new elements and flows, and turn every threat you keep into an acceptance criterion and a named abuse-case test. Update the system diagram when the story merges. New systems and large redesigns still need a full session.

• Adds or changes a trust boundary or an external integration.
• Changes authentication, authorization, roles or tenant rules.
• Adds a data store or a new class of sensitive or personal data.
• Parses untrusted files, documents or formats.
• Moves money or performs an action that cannot be undone.
• Adds an admin, support, batch or migration path.
• Creates, stores or uses keys, tokens or other secrets.

Employees submit claims with receipt images. Their manager approves a claim, and the API sends a payout instruction to a payroll provider, which reports the result through a webhook. A worker in a sandbox extracts fields from receipts. The boundaries are the internet, the company cloud account, the parsing sandbox and the payroll provider.

Running the model above with pytm 1.4.0 produced 118 candidate findings of 43 generic types, such as interception and content spoofing. None of them concerned who may approve which claim version. The threats that matter most came from the session.

Name tests after threat IDs so a failing build points back to the record. The tests below run with Node.js's built-in test runner against the service's HTTP interface. All five failed against a variant of the service with the controls removed and passed against the fixed one. A check that only runs on a laptop decays; run these on every pull request that touches claims, approval or payout code. Ready-made abuse cases with tests for common features are in /domains/appsec/threat-modeling/abuse-case-library/, and /domains/appsec/threat-modeling/security-requirements-definition-of-done/ shows how to keep them as requirements with a Definition of Done.

// abuse-cases.test.js: one test per threat record (run: node --test)
import { test, before, after } from 'node:test';
import assert from 'node:assert/strict';
import { createApp } from './app.js';

let server, base;
before(async () => {
  server = createApp({ webhookSecret: 'test-only-secret' }).listen(0);
  await new Promise((r) => server.once('listening', r));
  base = `http://127.0.0.1:${server.address().port}`;
});
after(() => server.close());

const call = (method, path, token, body) => fetch(base + path, {
  method,
  headers: { authorization: `Bearer ${token}`, 'content-type': 'application/json' },
  body: body && JSON.stringify(body),
});
const submit = async (token, amount) => (await call('POST', '/claims', token, { amount })).json();

test('T2: an employee cannot approve their own claim', async () => {
  const c = await submit('tok-alice', 120);
  assert.equal((await call('POST', `/claims/${c.id}/approve`, 'tok-alice', { version: 1 })).status, 403);
});

test('T3: the client cannot set status when creating a claim', async () => {
  const res = await call('POST', '/claims', 'tok-alice', { amount: 120, status: 'approved' });
  assert.equal(res.status, 400);
});

test('T4: approval binds to the reviewed version', async () => {
  const c = await submit('tok-alice', 120);
  await call('PATCH', `/claims/${c.id}`, 'tok-alice', { amount: 1200 }); // now version 2
  assert.equal((await call('POST', `/claims/${c.id}/approve`, 'tok-mo', { version: 1 })).status, 409);
  assert.equal((await call('POST', `/claims/${c.id}/approve`, 'tok-mo', { version: 2 })).status, 200);
  assert.equal((await call('PATCH', `/claims/${c.id}`, 'tok-alice', { amount: 5 })).status, 409);
});

test('T5: another employee cannot read the claim', async () => {
  const c = await submit('tok-alice', 120);
  assert.equal((await call('GET', `/claims/${c.id}`, 'tok-bob')).status, 404);
  assert.equal((await call('GET', `/claims/${c.id}`, 'tok-mo')).status, 200);
});

test('T1: an unsigned payroll webhook is rejected', async () => {
  const res = await fetch(`${base}/webhooks/payroll`, {
    method: 'POST',
    headers: { 'content-type': 'application/json', 'x-payroll-timestamp': String(Math.floor(Date.now() / 1000)) },
    body: JSON.stringify({ claim: '1', status: 'failed' }),
  });
  assert.equal(res.status, 401);
});

Keep one short record per threat you act on: scenario, impact, response, control, owner, status, verification and the change that should reopen it. OWASP's cheat sheet lists four responses: mitigate, eliminate, transfer and accept. Transfer moves responsibility, not the harm itself, so name who still owns the residual controls.

To answer whether you did a good enough job, check that the diagram matches the deployed system, every boundary-crossing flow was considered, every threat has a response, mitigations have passing tests, and accepted risks were approved by someone with the authority to accept them.

# threats/T4.yaml: one record per threat the team decided to act on
id: T4
title: Claim amount changes after approval
found_by: STRIDE per interaction (Manager -> Expenses API, approve)
category: Tampering
scenario: >
  Alice submits a claim for 120. Mo approves it. Alice edits the amount
  to 1,200 before payout, and payroll pays the edited amount.
impact: A payout that no approver saw.
response: mitigate            # mitigate | eliminate | transfer | accept
control: >
  Approval names the version the manager reviewed. Edits after approval
  are refused. Payout reads approvedVersion only.
owner: payments-team
status: verified
verification: "abuse-cases.test.js, test 'T4: approval binds to the reviewed version'"
revisit_when: Claim editing, approval or payout code changes.

Most failed sessions fail in the same few ways.

• Modeling the whole estate at once. Scope to a change and finish it.
• Treating generated findings as the model. Tools miss business rules such as approval binding.
• Debating whether a threat is tampering or elevation. The category does not change the fix.
• Leaving out asynchronous jobs, admin tools and partner callbacks, where many real defects sit.
• Relying on one expert. The Manifesto calls this the hero threat modeler; everyone on the team can contribute.
• Filing the diagram and never revisiting it. Tie reviews to the triggers above, not to a calendar.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Threat Modeling Manifesto
2. OWASP Threat Modeling Cheat Sheet
3. Microsoft: Uncover Security Design Flaws Using the STRIDE Approach (MSDN Magazine, 2006). November 2006.
4. Mbaka and Tuma: A replication of a controlled experiment with two STRIDE variants (2022)
5. Bruce Schneier: Attack Trees (Dr. Dobb's Journal, 1999). December 1999.
6. LINDDUN privacy threat types
7. SEI: Threat Modeling, A Summary of Available Methods (2018)
8. NIST SP 800-218, Secure Software Development Framework 1.1 (PW.1). Version 1.1 (February 2022).
9. OWASP Top 10:2025 A06 Insecure Design
10. OWASP pytm

Reference information

Tags

Threat modeling

SDLC phase

Design

Role

DevelopersAppSec engineers

Download this guide as Markdown

Continue exploring