Choose by how your team works, not by feature count. Ask five questions: which methods it supports, where the model is stored, who can edit it, whether it links to your issue tracker, and what the license allows. Start with the cheapest option that answers yes, often a whiteboard.
Three kinds of tool
| Kind | Example from public docs | Strength | Watch for |
|---|---|---|---|
| Drawing tool with threat suggestions | OWASP Threat Dragon: open source, web or desktop, Apache 2.0, STRIDE, LINDDUN, CIA, DIE and PLOT4ai, with a rule engine that suggests threats and mitigations | Friendly for mixed groups | Diagrams can drift from the code |
| Model as code | pytm: a Python framework that generates diagrams, sequence diagrams and reports | Lives in the repo, reviewable in pull requests | Needs developers and some setup |
| Vendor desktop tool | Microsoft Threat Modeling Tool: standard notation for components, flows and boundaries, suggests and manages mitigations, can plug into issue tracking | Built for non-security experts | Check platform and support on the vendor page |
Details come from the public pages for each project. Check the current page before you commit, because versions change; the Threat Dragon page listed v2.6.2 when I read it.
The five questions
- Which methods do we use? If you use STRIDE, nearly every tool works. If you need LINDDUN for privacy, check support.
- Where does the model live? The OWASP cheat sheet says to save diagrams in a form the team can update. Prefer storage your team already uses.
- Who edits it? If non-developers join sessions, a drawing tool or whiteboard is easier than code.
- Does it connect to our tickets? A threat that never becomes a ticket does not get fixed. Look for issue tracker links or export.
- What is the license and hosting model? Threat Dragon can be self-hosted or run as a desktop app. For model as code, check the license file in the repository, as the pytm page I read did not state it.
A sensible way to start
Hold the first two sessions at a whiteboard or on paper. The OWASP guidance points out that brainstorming lets every team member contribute. After the group agrees on a rhythm, pick a tool for storage and review. Often that choice is obvious by then. See also whiteboard or Threat Dragon.
Red flags
- A tool that generates hundreds of threats nobody reads
- A model only one person can edit
- Exports you cannot get out if you switch
- Treating generated suggestions as findings without discussion
The Threat Modeling Manifesto values people and collaboration over processes, methodologies and tools. A tool that gets in the way of the conversation fails that test.
Quick check
Do I need a tool at all?
No. A whiteboard and a template work for many teams. Add a tool when storage, review or ticket links become the pain.
Can a tool find all the threats for me?
No. Rule engines suggest threats from the structure you draw. People still decide which matter and what to do.
A note on tooling
Safeguard does not replace a threat modeling tool. It covers checks on what you build: SBOM and dependency scanning, reachability analysis and policy gates. Try the free scan.
Sources
- OWASP Threat Dragon
- pytm on GitHub
- Microsoft SDL: Threat modeling
- OWASP Threat Modeling Cheat Sheet
- Threat Modeling Manifesto
Last reviewed: 19 October 2026.
