# OWASP Threat Dragon: a free threat modeling tool you run yourself or in Docker > Threat Dragon is an OWASP project for drawing data flow diagrams and listing threats against each element. This covers how the web app and desktop builds differ, how to install it, and where it stops being the right choice. **OWASP/threat-dragon** — 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. - Repository: https://github.com/OWASP/threat-dragon - Website: https://owasp.org/www-project-threat-dragon/ - Stars: 1,609 · Forks: 404 - Language: JavaScript - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/owasp-threat-dragon ## What Threat Dragon is for, and who it is aimed at Threat Dragon draws threat modeling diagrams and lists threats for the elements in those diagrams. That is the whole scope. It is not a scanner and it does not read your source code. The README describes the project's aims as ease of use and accessibility, designing a data flow diagram, suggesting threats, and entering mitigations and counter measures. The suggestion step is a template-driven prompt, not analysis of a live system. The people it fits are design and security reviewers who need to sit in a room (or a call) and produce a diagram with a threat list attached to it. The README says it is designed to be accessible for various types of teams, with an emphasis on flexibility and simplicity, and that it follows the values and principles of the threat modeling manifesto. Mike Goodwin created it as an open source community project, and it now holds OWASP Production status. Where it does not fit is equally clear. If your requirement is continuous scanning of deployed infrastructure, or automatic discovery of components, Threat Dragon gives you nothing. You draw the boxes. The tool records what you decided about them. ## Web app or desktop: the storage decision comes first The repository splits into td.server (back end) and td.vue (front end), and the README states plainly that Threat Dragon is primarily a web application. The two variants differ in one important way: where the model files live. The web application can store threat model files on the local filesystem, and access can additionally be configured for GitHub, Bitbucket, GitLab and GitHub Enterprise. The desktop versions store threat model files on the local filesystem and do not access external repositories. Installers for Windows, macOS and Linux are available from the GitHub releases area. That choice has consequences beyond convenience. If you configure a Git provider, you have to register the application in that provider's account settings, and the README points to separate step by step guides for Bitbucket, GitHub and GitLab. That registration is real setup work, and it is the point where most first attempts stall. If your team cannot get an OAuth application registered, the filesystem-backed web app or the desktop build is the honest fallback. Version 1.x is a separate matter. It was written in AngularJS 1.x, which reached end of life, so versions 1.x are no longer actively maintained and 2.x was rewritten in Vue.js. The legacy branch still exists for anyone who needs to build the old version, but new work belongs on 2.x. ## Installing Threat Dragon from source and opening the first model Building 2.x from source needs git and Node.js, which brings npm with it. Clone the repository, then install from the top directory. The postinstall script installs dependencies inside both td.server and td.vue, so a single install at the root covers both halves. ```bash git clone https://github.com/owasp/threat-dragon.git cd threat-dragon npm install ``` On Linux or macOS, npm start builds the Vue front end and the server, then starts both. The README gives the access address as http://localhost:8080/. ```bash npm start ``` On Windows, and during development generally, the two halves can be run separately in watch mode. This is the loop you want if you are changing front-end code, because a rebuild is not needed for every edit. ```bash npm run dev:server npm run dev:vue ``` Stopping is symmetric: npm stop shuts down both the back-end server and the front-end application when you started them with npm start. If you ran the dev commands instead, break out of both processes. ```bash npm stop ``` One caveat before you start: the web application variant requires environment variables. The repository ships example.env and minimal.env, and the README directs you to the configuration documentation for how to set them. Read those files before the first run rather than after a failed one. ## Running the container, and the tag trap in the Docker instructions Threat Dragon publishes images in the OWASP organisation area on Dockerhub, tagged per release as v{major}.{minor}.{patch}. The README warns that the latest tag, which is the default, may well be a development version, and advises using the stable tag, which will always be the latest official release. Take that warning literally. A default pull is not a release pull here. ```bash docker pull threatdragon/owasp-threat-dragon:stable ``` The run command maps container port 3000 to host port 8080 and mounts a .env file into the container. That mount is how the environment variables reach the application. ```bash docker run -it --rm -p 8080:3000 -v $(pwd)/.env:/app/.env threatdragon/owasp-threat-dragon:v2.2.0 ``` On Windows the same command uses %CD% in place of $(pwd). Building an image locally follows the same shape, with docker build -t owasp-threat-dragon:dev . from the top directory of the project, then a run against that tag. In both cases the README assumes http port 8080 and access at http://localhost:8080/. The Dockerfile itself is worth a glance if you care about supply chain hygiene. It pins the npm version, copies an .npmrc and sets NPM_CONFIG_USERCONFIG, and runs npm clean-install in each package directory. That is a deliberate choice to make container builds reproducible rather than fast. ## Where Threat Dragon stops being the right tool The threat list is only as good as the diagram you drew. Threat Dragon suggests threats for elements in the diagram, which means an element you forgot to place produces no suggestion. There is no mechanism in the README that detects a missing component, and no import path from infrastructure or code into the model. Teams used to tools that enumerate resources automatically will find this manual by design, not by omission. The second limit is the storage model. Models are files. If you configure GitHub, Bitbucket, GitLab or GitHub Enterprise, those files live in a repository you registered the application against; otherwise they live on the local filesystem. Nothing in the README describes a shared server-side database, concurrent editing, or conflict handling between two people editing the same model. For a single reviewer working through a design, that is fine. For a large organisation expecting a central register of models with access control, the file-based approach means you build the surrounding process yourself. The third limit is version 1.x. It is in maintenance mode, written against an AngularJS version that reached end of life, and the README says versions 1.x are no longer actively maintained. If you are following an old tutorial that references 1.x, you are following instructions for a branch the project has moved past. Finally, the repository's most recent push was on 2026-05-10, the same date as the v2.6.2 release. That is the current state of the project as recorded here; check the releases page for anything after it. ## Alternatives and how their approach differs The obvious comparison is Microsoft Threat Modeling Tool, which also produces data flow diagrams with threats attached. The difference is platform and file handling: Threat Dragon is cross-platform and its web app runs in a browser against filesystem or Git-backed storage, while the Microsoft tool is a Windows desktop application. If your team is not on Windows, that alone decides it. A second comparison is diagramming tools such as draw.io or general purpose diagram editors. Those draw better than Threat Dragon in several respects, and some support threat modeling shapes. The distinction is that a general diagram editor has no notion of a threat attached to an element, no threat list per component, and no mitigation field. You would be maintaining that structure in a separate document, which is exactly the duplication Threat Dragon removes. A third comparison is the emerging category of threat modeling as code, where models are text files in a repository and rendered by a pipeline. Threat Dragon's models are files, and its web app can store them in Git, so the two overlap more than they first appear. The difference is authoring: Threat Dragon is a graphical editor with a browser UI, not a text format you hand-edit. If your team wants models reviewed as diffs in pull requests, the graphical authoring is a mismatch, even though the storage is not. For pure free-and-open-source criteria, the Apache 2.0 licence is the practical differentiator against the Microsoft tool, which is not open source. ## Maintenance cost, licence and what to check before adopting Threat Dragon is licensed under the Apache 2.0 License, and the README states the program is free software that you can redistribute and modify under that licence. In practical terms, that means you can run it internally, modify it, and ship a modified version without a copyleft obligation on your own code. This is not legal advice; read license.txt in the repository for the actual terms. Upgrade cost is moderate. The root package.json wires build, test, lint and audit scripts across both td.server and td.vue, so a version bump means rebuilding both halves and re-running the test suites. The Dockerfile pins a specific Node image and a specific npm version, which means the container path upgrades on the project's schedule, not yours. If you run from source, you carry the Node.js version requirement yourself. There is a vulnerability disclosure process, referenced in the README, which matters if you are deploying the web app with Git provider access configured: that configuration gives the application credentials to your repositories. Registering a dedicated application and scoping its access is the sensible shape, and the README's per-provider guides are the place to start. Before adopting, check three things. Whether your storage target is filesystem or a Git provider, because that determines the setup work. Which environment variables your variant needs, by reading example.env and minimal.env. And which tag you are running, given that the default Docker tag may be a development build. ## Conclusion Adopt Threat Dragon if you want a free, OWASP-hosted tool that keeps threat models as files you own, and if a diagram plus a threat list per element matches how your team already reviews designs. Skip it if you need automated analysis of running systems, or if you cannot run Node.js 24 or a container and cannot use the desktop installers. Before committing, verify two things yourself: which environment variables your chosen storage needs, by reading example.env and minimal.env, and which release tag you are pulling, since the latest Docker tag may be a development version while stable is the latest official release. ## FAQ ### Is OWASP Threat Dragon free? Yes. The README states it is a free, open-source, cross-platform threat modeling application, and it is distributed under the Apache 2.0 License. ### What is OWASP Threat Dragon? It is an OWASP project, holding OWASP Production status, that is used to draw threat modeling diagrams and to list threats for elements in the diagram. It was created by Mike Goodwin as an open source community project. ### How do I install OWASP Threat Dragon? Clone the repository, run npm install from the top directory, then npm start on Linux or macOS and open http://localhost:8080/. Alternatively pull the Docker image using the stable tag, or download a desktop installer for Windows, macOS or Linux from the GitHub releases area. ### How do I use OWASP Threat Dragon? You design a data flow diagram, and the application suggests threats for the elements in it, where you then enter mitigations and counter measures. The README also points to a demo website and the documentation pages for end user help with version 2.x. ### What are the alternatives to OWASP Threat Dragon? Microsoft Threat Modeling Tool covers similar ground but is a Windows desktop application, whereas Threat Dragon is cross-platform and its web app can store models on the local filesystem or in GitHub, Bitbucket, GitLab or GitHub Enterprise. General diagram editors can draw the same shapes but have no threat list attached to each element. ## Sources - [Official documentation](https://owasp.org/www-project-threat-dragon/) - [Official README](https://github.com/OWASP/threat-dragon#readme) - [Project repository](https://github.com/OWASP/threat-dragon) - [Release notes](https://github.com/OWASP/threat-dragon/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-threat-dragon