OWASP Threat Dragon: Threat Modeling That Starts with a Diagram, Not a Spreadsheet
An open source threat modeling tool from OWASP. [ ][build] [ ][latest] [ ][practices] OWASP Threat Dragon [OWASP][owasp] [Threat Dragon][project] is a free, open-source, cross-platform threat modeling application.
At a glance
- What is it?
- OWASP Threat Dragon is a free, open-source threat modeling tool that combines diagramming with threat listing. This review covers its architecture, setup, and where it fits in a security workflow.
- Who is it for?
- Adopt Threat Dragon if you want a free, visual threat modeling tool that runs in a browser or as a desktop app, and if your team is comfortable with a diagram-first approach. Avoid it if you need automated threat generation from code or if your workflow demands heavy integration with CI/CD pipelines; the tool focuses on manual diagramming and threat listing.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Threat Dragon Actually Does
Threat Dragon solves a specific problem: it gives teams a place to draw data flow diagrams and attach threat lists to each element. The README is clear that the tool is used to draw threat modeling diagrams and to list threats for elements in the diagram. That is the core loop. You model a system visually, then you enumerate threats per component, and you record mitigations. It is aimed at teams that want an accessible, low-cost way to do threat modeling without buying a commercial platform. The project has OWASP Production status, which signals a level of maturity, but the tool itself is deliberately simple. It does not do automated code scanning or dynamic analysis. It is a structured whiteboard with a threat catalog attached.
Two Flavors: Web App and Desktop
The project ships in two forms. The web application is the primary variant, and it can store threat model files on the local filesystem or connect to external repositories: GitHub, Bitbucket, GitLab, and GitHub Enterprise. That means a team can keep models in version control, which is a sensible way to track changes over time. The desktop versions, available for Windows, MacOS, and Linux, store files only on the local filesystem and do not access external repositories. That is a meaningful difference. If you want collaborative versioning through a repo, you need the web app. If you want a standalone tool that never touches the network, the desktop version is the safer bet. The README does not say whether models are stored as JSON or YAML, but the file-based nature is clear.
How the Architecture Is Split
The repository layout shows a clear separation: a back-end application in td.server and a front-end in td.vue. The back-end handles file storage and repository access, while the front-end is the Vue.js interface. This split matters for deployment. You can run both together with npm start on Linux or MacOS, or run them separately in watch mode during development on Windows. The web variant requires environment variables, and the README points to documentation for setting them. If you want to use GitHub, GitLab, or Bitbucket integration, you must register the application with those providers. The README links to step-by-step guides for each. That is a real setup cost. It is not a zero-config tool if you want repository integration.
Getting It Running: Commands That Work
The README gives concrete commands. For a source build, you clone the repository, then run npm install from the top directory. For development on Windows, you start the server and front-end separately with npm run dev:server and npm run dev:vue. On Linux or MacOS, npm start launches both, and you access the app at http://localhost:8080/. To stop, use npm stop. There is also a Docker path. The README warns that the latest tag may be a development version, so it recommends the stable tag: threatdragon/owasp-threat-dragon:stable. A Docker run command mounts a .env file into the container: docker run -it --rm -p 8080:3000 -v $(pwd)/.env:/app/.env threatdragon/owasp-threat-dragon:v2.2.0. That .env file is where you set the required environment variables. The port mapping is 8080 on the host to 3000 in the container.
A Real Limitation: Manual Threat Suggestion
The README lists 'suggesting threats' as a feature, but it does not claim automatic threat generation from code or infrastructure. The suggestion mechanism is tied to the diagram elements, meaning you still have to know what threats to look for. This is not a tool that scans your codebase and produces a threat model. It is a guided manual process. For teams that want to automate threat modeling as part of a CI pipeline, this is the wrong tool. The manual nature is a strength for education and early design discussions, but it becomes a bottleneck if you have many services and need rapid, repeatable threat assessments. The README does not mention any API or CLI for batch processing, so expect a human in the loop.
The Vue Rewrite and Version 1.x Legacy
Threat Dragon has a history worth knowing. The original version used AngularJS 1.x, which reached end of life. The project rewrote the tool using Vue.js for version 2.x. The README states that version 1.x is no longer actively maintained, and the code lives on an archive-legacy-v1.x branch. This matters for adoption. If you find older tutorials or blog posts referencing Threat Dragon 1.x, they may not apply to the current version. The rewrite means the interface and possibly the file format changed. The README does not say whether models from 1.x import cleanly into 2.x. If you have existing models, verify that before migrating. The active development is clearly on 2.x, with recent releases like v2.6.2 in May 2026.
Alternatives and How They Differ
The main alternative in the open-source space is OWASP Threat Dragon's sibling, OWASP Threat Modeling (or the older Microsoft Threat Modeling Tool, which is not open source). A closer open-source alternative is pytm, which takes a code-first approach: you define your architecture in Python code, and it generates threat models and diagrams. That is the opposite of Threat Dragon's diagram-first approach. pytm is for teams that want to keep threat models in code and generate diagrams as artifacts. Threat Dragon is for teams that want to draw first and then reason about threats. Another alternative is the commercial IriusRisk, which offers automated threat generation and risk management, but it is not free. The choice comes down to whether you prefer a visual canvas or a programmable model.
Licensing and Maintenance Costs
Threat Dragon is licensed under Apache-2.0, which is permissive. You can modify and redistribute it, even for commercial use, as long as you preserve the license. That is a low barrier for internal adoption. The maintenance cost comes from the environment setup and the repository integrations. The README emphasizes that the web app requires environment variables, and the configuration documentation is separate. You will need to maintain those variables and the OAuth credentials for any repository integration. The project appears actively maintained, with a release in May 2026. The README also mentions a vulnerability disclosure policy, which is a good sign for security-focused teams. However, the project does not provide a managed cloud service; you run it yourself or use the demo site, which is not for production.
Editorial conclusion
Adopt Threat Dragon if you want a free, visual threat modeling tool that runs in a browser or as a desktop app, and if your team is comfortable with a diagram-first approach. Avoid it if you need automated threat generation from code or if your workflow demands heavy integration with CI/CD pipelines; the tool focuses on manual diagramming and threat listing. Before committing, verify which storage backend you need: the web app can connect to GitHub, GitLab, Bitbucket, or GitHub Enterprise, but the desktop versions store files locally only. Also check the environment variable configuration for the web variant, because the README warns that these are required and undocumented in the same file. If your team already uses a specific repository platform, confirm that the OAuth or token setup matches the step-by-step guides linked in the docs.
Community notes