OWASP Threat Dragon

OWASP Threat Dragon is a free, open-source threat-modeling tool built around the exact STRIDE methodology the threat-modeling page teaches: draw a data flow diagram, and for every actor, process, data store, and flow you place, the tool narrows the six STRIDE categories down to the subset that's actually applicable to that shape — so you're prompted with the right questions per element instead of starting from a blank checklist each time. The other half of its pitch is where the finished model lives afterward: it saves as a plain JSON file, and its web edition can write that file directly into a connected Git repository, so a threat model can sit in version control next to the service it describes, reviewed in a pull request the same way a code change is.

What Threat Dragon is, and the problem it solves

☺ Like you're 10: It's a free drawing tool that already knows the security questions to ask about each shape you draw, and it saves your answers as a file you can keep, not a whiteboard photo you'll lose.

Threat Dragon is an OWASP project, originally created by Mike Goodwin and now maintained under the OWASP umbrella by a small group of community contributors rather than a single vendor. OWASP groups its projects into maturity tiers that shift over time as a project's activity and adoption change, so check the current OWASP project inventory if the exact tier label matters to your evaluation — what matters more for this page is that it's been actively maintained for years and ships two interchangeable editions of the same tool: a desktop edition (an Electron app you install and run entirely offline, with no account and no server) and a web edition (a browser-based app, typically self-hosted, that can authenticate against a Git provider and read/write the model file straight to a repository path). Both editions open and save the identical file format, so a model started on a laptop with no network access opens cleanly in the web edition later, and vice versa.

The problem it solves is the one the threat-modeling page names directly: STRIDE is a checklist that only works if someone actually applies all six categories to every element, consistently, and the output has to be something a team can revisit later rather than a whiteboard photo nobody can search or diff. A spreadsheet or a slide deck can hold a threat list, but neither one enforces "did you ask the spoofing question about this specific data store" the way a tool that already knows a data store's applicable category set can, and neither diffs meaningfully in a code review. Threat Dragon's whole design is aimed at closing exactly that gap: structure the diagram, narrow the questions per element automatically, and store the result as a file a version control system already knows how to handle.

Building the diagram: the stencil and trust boundaries

☺ Like you're 10: You drag four kinds of shapes onto a canvas — a person, a box that does work, a cylinder that stores stuff, and arrows connecting them — then draw a line everywhere trust changes.

A new model starts as a name, an owner, and a short description, then one or more diagrams underneath it — most systems get a single top-level diagram, with a deeper diagram added only for a component complex enough to deserve its own pass. The stencil offers a small, fixed shape set that maps directly onto the data-flow-diagram vocabulary the threat-modeling page introduces:

• Actor (an external entity) — a person or an external system the diagram doesn't control, like a shopper's browser or a third-party payment gateway.
• Process — a piece of your own system that does work: a service, a function, a background job.
• Store (a data store) — anywhere data rests: a database, a cache, an object bucket, a log stream.
• Flow — the arrow connecting two shapes, representing data moving between them; every flow gets a name describing what actually travels across it.
• Trust boundary — either a boundary box enclosing a zone or a dashed boundary line a flow crosses, marking exactly the places the threat-modeling page says analysis should concentrate: where a flow moves from one level of trust to another.

Every element also carries an Out of Scope toggle with a reason field. That matters more than it looks: a component silently missing from the diagram reads as an oversight nobody can distinguish from "forgot to draw it," while a component explicitly marked out of scope, with a reason, is a documented decision a reviewer can agree or disagree with. Recent versions of the tool also let you pick a diagram's threat-generation ruleset at creation time — STRIDE is the default and the one this page focuses on, but LINDDUN (privacy-focused categories) and a generic empty ruleset with no suggestions are options in the editor if your deployed version includes them; treat that as a detail to confirm against the running tool rather than assume.

STRIDE per element: what the tool narrows down, and what you still write yourself

☺ Like you're 10: Click a shape, and instead of six blank boxes to fill in, you only see the ones that actually apply to that kind of shape — then you still have to write what the danger really is.

Click any element and a panel opens with a "Threats" tab and an "Add Threat" action. Choosing a category there opens a dropdown that's filtered to the categories Threat Dragon's built-in mapping considers applicable to that shape type — the same convention Microsoft's original STRIDE tooling established, and the one most STRIDE-based tools including this one still follow:

What the tool does not do is write the threat for you. Selecting "Tampering" on a data-store element gives you an empty title and description field, a severity dropdown, and a status dropdown (typically Open, Mitigated, or Not Applicable) — you still supply the sentence that makes it specific to this system: not "tampering is possible" but "an operator with read replica access can modify order rows without the write path's validation running." That specificity is the entire value of the exercise; a generic STRIDE-category label with no detail is functionally a to-do list item with the details missing.

The model file: what actually gets versioned

☺ Like you're 10: Everything you drew and typed gets written into one plain text file — shapes, arrows, and every threat attached to each one — so git can track it exactly like it tracks code.

A saved model is a single JSON document: a summary block (title, owner, description) and a detail block holding one or more diagrams, each diagram a list of cells — one entry per shape and per flow — and each cell carrying its own threats array. Exact field names have shifted across the tool's major versions, so treat the following as illustrative of the shape rather than a guaranteed-current schema:

{
  "summary": {
    "title": "Checkout Service",
    "owner": "payments-team",
    "description": "Threat model for the checkout API and its data flows"
  },
  "detail": {
    "contributors": [{ "name": "Rocky Raccoon" }],
    "diagrams": [
      {
        "title": "Checkout — level 0",
        "diagramType": "STRIDE",
        "cells": [
          {
            "id": "a1b2c3",
            "shape": "actor",
            "data": { "name": "Shopper (browser)" }
          },
          {
            "id": "d4e5f6",
            "shape": "process",
            "data": {
              "name": "Checkout API",
              "outOfScope": false,
              "threats": [
                {
                  "id": "t1",
                  "type": "Spoofing",
                  "title": "Client-supplied user-id header trusted without verifying the session",
                  "status": "Open",
                  "severity": "High",
                  "mitigation": ""
                },
                {
                  "id": "t2",
                  "type": "Elevation of Privilege",
                  "title": "Admin-only discount endpoint reachable without a role check",
                  "status": "Mitigated",
                  "severity": "High",
                  "mitigation": "Role guard added in PR #482; covered by an integration test"
                }
              ]
            }
          },
          {
            "id": "g7h8i9",
            "shape": "flow",
            "data": { "name": "HTTPS request", "threats": [] }
          }
        ]
      }
    ]
  }
}

Two things about this file matter more than any single field name. First, it's diffable: a reviewer can see exactly which threat changed status from Open to Mitigated, and cite the pull request that fixed it, the same way they'd review a code diff. Second, the web edition's Git integration means the "export" step most tools require doesn't exist here — you point the model at a repository and a path when you create it, and every save is a commit (or a change staged for one), so the model file can live at, say, docs/threat-model.json right beside the service it describes, versioned on the same branch and reviewed in the same pull request as the code change that prompted the update.

Day-to-day workflow

☺ Like you're 10: Mostly you click and drag, not type commands — the few commands that exist are just for installing or self-hosting the tool itself.

Threat Dragon is overwhelmingly a GUI tool; there's no CLI for authoring a model. What there is, is a handful of ways to run the tool itself, and a repeatable sequence once it's open. Folder names, image tags, and exact scripts shift between releases — verify against the project's own README before running these — but the shape holds:

# Desktop edition — no server, no account, works fully offline.
# Download the signed .dmg / .exe / .AppImage from the project's GitHub Releases page.

# Web edition, self-hosted via the published Docker image:
$ docker run -p 3000:3000 owasp/threat-dragon:latest
# open http://localhost:3000 — choose "local" storage to skip connecting a Git provider entirely,
# or sign in with GitHub/GitLab/Bitbucket to read and write models straight to a repo.

# Running from source for development:
$ git clone https://github.com/OWASP/threat-dragon.git
$ cd threat-dragon/td.vue    && npm install && npm run serve   # the Vue frontend, dev server
$ cd threat-dragon/td.server && npm install && npm start        # the Express API the web edition talks to

The routine itself, once it's running: create a model and point it at a storage location, add a diagram and pick a title, drag the actors/processes/stores onto the canvas and connect them with named flows, drag a trust boundary across every place trust actually changes, then click through each element adding threats from its filtered category list and writing the specific sentence under each one, setting a severity and a status. Save, and — in the Git-connected web edition — that write becomes a commit. Open a pull request alongside the code change the model describes, so a reviewer reads the diagram diff and the threats diff in the same review, not a separate document nobody opens. Then, critically, come back to it: the threat-modeling page is explicit that a model nobody revisits degrades from a security control into a historical document, and nothing about saving the file to git changes that — it only makes revisiting it, and seeing exactly what changed since last time, possible in the first place.

Gotchas and failure modes

☺ Like you're 10: Most of the surprises come from the same root cause — the tool only knows about the shapes you drew and the words you typed, never about the real system underneath.

• The diagram is never checked against reality. Threat Dragon has no way to know whether the DFD you drew still matches the deployed system. Unlike a build that fails when code and a manifest disagree, a stale diagram just sits there looking authoritative, and the threat model built on top of it inherits every blind spot the stale diagram has.
• "Mitigated" is a claim, not a verified fact. Marking a threat's status Mitigated records that someone believes a control exists — it does not check that the control shipped, that it's still in the code, or that it actually works. Closing that loop means the mitigation maps to something independently checked: a merge-blocking Semgrep or CodeQL rule, a config scan, a test — not the threat model's own say-so.
• Suggested categories aren't a finished analysis. The per-element filtering narrows which STRIDE questions apply; it never writes the answer. A model where every process element has all six categories pre-listed with generic one-line titles looks complete and tells a reviewer nothing — see the callout above.
• Canvas position data bloats diffs. The JSON stores x/y coordinates for every shape's placement, so reflowing a diagram to make room for a new element — with no threats or content actually changed — still produces a diff full of coordinate churn. Reviewers who don't know to skim past position-only hunks will waste time on them.
• Nothing gates a merge on an unresolved threat. Unlike a SAST or SCA scanner wired into CI/CD as a required check, Threat Dragon itself doesn't fail a build because a High-severity threat is still Open. If you want that enforcement, you write a script that parses the JSON and checks it in the pipeline, or you reach for a threat-modeling-as-code tool built to run in CI from the start (see the comparison below).
• File-schema drift across major tool versions. The desktop-only 1.x line and the later rewrite don't share an identical file schema in every field. A model authored years ago in an older release may need a migration pass before it opens cleanly in a current install — treat a major version upgrade of the tool itself as a migration event, the same caution this course applies to any format that isn't guaranteed stable across versions.

Alternatives and when to choose it

☺ Like you're 10: Other tools ask the same STRIDE questions differently — some draw pictures like this one, some are just text files a computer can check automatically, and one costs money for a bigger library and more integrations.

The practical rule: reach for Threat Dragon when the deliverable needs to be something a whole team can read at a glance and something git can track like any other artifact — it's usually the right default for a single service or team-owned system. Reach for a threat-modeling-as-code tool like pytm or Threagile when the model needs to be generated and enforced automatically as part of a pipeline rather than authored by hand. Reach for a commercial platform like IriusRisk once the problem is organization-wide governance across dozens of teams rather than one team's diagram. See Secure SDLC Gates & the DevSecOps Maturity Model for where a threat-modeling gate fits among the other required checks in a mature pipeline.