# What’s in your threat modeling toolbox?
**URL:** https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160
**Category:** Techniques & Tooling
**Created:** [September 9, 2025, 2:00pm UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160 "2025-09-09T14:00:27Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@shuning](https://threatmodelingconnect.discourse.group/u/shuning)
#### Post date: [September 9, 2025, 2:00pm UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160/1 "2025-09-09T14:00:27Z")
Hey friends, this week we want to talk about tools. The [SOTM Report 2024-2025](https://www.threatmodelingconnect.com/state-of-threat-modeling-2024-25) revealed something interesting: dedicated threat modeling tools are the minority - generic tools are still the norm.
@adamshostack also wrote a [post](https://threatmodelingconnect.discourse.group/t/threat-modeling-tooling-post/1157) recently around threat modeling tooling, in which he helps define threat modeling tools in four categories:
“General purpose tools like whiteboards or Google docs, Programmer threat modeling tools tools (eg, pytm), Individual/small team threat modeling tools (eg, MS-TMT or Threat Dragon), Enterprise threat modeling tools (eg, IriusRisk).”
> **We’d love to know:**
>
> What’s your tooling technique? What do you use, why, when and how?
* * *
_This post is part of our new weekly ‘Peer Perspectives’ series! Each week, we’ll explore a new threat modeling topic and open it up for community discussion. For the coming weeks ahead, we’ll discuss key findings from the newly-released State of Threat Modeling Report 2024-2025._
---
### Author:  [@jasonculligan](https://threatmodelingconnect.discourse.group/u/jasonculligan)
#### Post date: [September 10, 2025, 10:09am UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160/2 "2025-09-10T10:09:44Z")
For my work, I designed a method using a hierarchically-aware diagramming tool and an auto-calculating spread sheet. I created it by using what I believed were the best parts I had seen of all the aforementioned tools and some not mentioned tools. I know it works because it helps my teams know why every mitigation is necessary, if the mitigation is actually present, and if any mitigations are missing. At the end of the day, whatever solution people use must be reused, and not shelved. A threat model has the potential to change just as much as the code changes.
---
### Author:  [@Sebastian\_Obara](https://threatmodelingconnect.discourse.group/u/Sebastian_Obara)
#### Post date: [September 10, 2025, 11:39am UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160/3 "2025-09-10T11:39:43Z")
My threat modeling toolbox centers around an interactive whiteboard - either physical or digital like Miro or Mural - structured with the “Who-What-How” methodology that I’ve found incredibly effective for agile teams. I think my preference for this visual, collaborative approach stems from the fact that I genuinely enjoy working with people live, whether in-person around a physical board or virtually in real-time sessions - there’s an energy and creativity in group dynamics that you just can’t replicate with asynchronous tools.
I organize the board into three main columns where we identify potential attackers, their targets, and attack methods during focused 2-4 hour sessions with 3-10 participants from security, business, and technical roles. I use colored sticky notes extensively - green for user stories, red for corresponding “abuser stories,” with different colors indicating threat criticality levels.
My approach follows a “breadth-first” analysis pattern, ensuring we cover the entire attack surface before diving into specifics, which prevents getting stuck in rabbit holes during brainstorming. For existing systems, I divide the board into component sections, allowing smaller groups to analyze each part separately before consolidating findings.
I always pre-populate the board with base threat model templates for common technologies we use, like SOAP APIs, Java frameworks, REST, etc.., which saves significant time and ensures consistency. The digital version of my toolkit automatically generates Data Flow Diagrams and threat maps that export directly to our ticketing systems, making the transition from analysis to action seamless.
During sessions, I maintain strict role assignments - facilitator, moderator, and dedicated notetaker - to keep discussions productive and ensure nothing gets lost. I cap these sessions at 10% of sprint time, following Scrum guidelines, which forces us to stay focused on the most critical risks.
The session culminates in a visual risk prioritization exercise where we physically move threats into “immediate mitigation,” “for analysis,” or “acceptable risk” zones, creating instant clarity on our security roadmap that everyone can see and understand.
---
### Author:  [@hewerlin](https://threatmodelingconnect.discourse.group/u/hewerlin)
#### Post date: [September 10, 2025, 5:10pm UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160/4 "2025-09-10T17:10:33Z")
I don’t distinguish too much between tools and methods.
# General considerations + Writing things down
- Start and end where all the other work is done → issue tracking
- write where the other TechDoc is written
- draw with [draw.io](http://draw.io)
- experimented with own markup that is especially good at structured data with enforced but flexible schema, many-to-many mappings and reverse links → [Threat Items Threat Modeling Template](https://github.com/hewerlin/threat-items-threat-modeling-template) + unpublished work
- own template with lots of guidance, training material links and TODO checkboxes
- Threat properties: ID, short name, description (may be GIVEN WHEN THEN), affected component(s), category, risk before mitigations, considered mitigations, selected mitigations, risk after selected mitigations, status, review
- Mitigation properties: ID, short name, description + acceptance criteria, threat reverse links, issue tracker ticket ID, status, type
- per threat model ID spaces
- Or lean description only 🧩 threat model part \ 🌩 threat \ ☂ mitigation hierarchies
- A lot of 🌩☂ emojis
- ask AI and add what’s insightful
- [ThreatPad](https://threatmodelingconnect.discourse.group/t/meet-threatpad/741) for education and adhoc online threat model
- trainings, reviews and support
# Methods used
Here are some of my favorites:
- [4 Question Framework](https://github.com/adamshostack/4QuestionFrame) as a 🧩 plugin architecture how all of this works
## Working on?
- Two directions: secure new + salvage existing
- [Continuous Threat Modeling](https://github.com/Autodesk/continuous-threat-modeling), especially their “threat model every story” and the idea that there should be a baseline threat model
- [Incremental Threat Modeling](https://www.youtube.com/watch?v=QlLbBOgclp0&t=3001s) idea on how to threat model new next to legacy
- [Threat Modeling a Giant strategy (1.1.1 in TM of TM)](https://threat-modeling.net/threat-modeling-of-threat-modeling/) on how to catch up on threat modeling for existing → Basically Divide & Conquer + some extra ideas
- [draw.io](http://draw.io) for diagrams or [excalidraw](https://excalidraw.com/) when I can’t see [draw.io](http://draw.io) anymore
- freestyle diagrams that must contain stick figures 😉
- explicit in / out of scope
- [4 Question Framework](https://github.com/adamshostack/4QuestionFrame) as a lightweight approach on story level
## Go wrong?
- [STRIDE](https://thoughtworksinc.github.io/sensible-security-conversations/) for security threats elicitation
- [LINDDUN](https://linddun.org/) for privacy threats elicitation
- [CWE - Common Weakness Enumeration](https://cwe.mitre.org/) as category inspiration, especially [CWE - CWE Top 25 Most Dangerous Software Weaknesses](https://cwe.mitre.org/top25/)
## Do about it?
- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework) with their protect detect respond recover
- ATE (accept transfer eliminate)
- [Qualitative {L,M,H}² likelihood/impact risk assessment](https://threat-modeling.net/likelihood-impact/) with clear consistent rules when to choose what
- risk assessment before/after mitigations - have inacceptable risks turn acceptable by adding appropriate mitigations
## Go wrong + do about it?
- Attack Defense Trees - especially good when there’s powerful intermediate nodes, also: a picture is worth 1000 words effect
- [GIVEN WHEN THEN](https://threat-modeling.net/given-when-then/) - good for techtual representation of Attack Trees and threat descriptions
- [Fortunately Unfortunately (Forests)](https://threat-modeling.net/fortunately-unfortunately-of-fortunately-unfortunately/) - when we want to consider more kinds of what can go wrong, like feasibility, or do a quick discussion of pros and cons
## Good job?
- own [Meta Threat Modeling](https://threat-modeling.net/meta-threat-modeling/)
- A lot of the learnings from [⛈☂(⛈☂) Threat Modeling of Threat Modeling](https://threat-modeling.net/threat-modeling-of-threat-modeling/)#meta so that the threat modeling doesn’t suck
- Mitigation / issue tracker status integration
- Retro + Lessons learned
---
### Author:  [@hewerlin](https://threatmodelingconnect.discourse.group/u/hewerlin)
#### Post date: [September 10, 2025, 5:13pm UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160/5 "2025-09-10T17:13:22Z")
> [@Sebastian\_Obara](#):
>
> My approach follows a “breadth-first” analysis pattern, ensuring we cover the entire attack surface before diving into specifics, which prevents getting stuck in rabbit holes during brainstorming.
Sounds like a good idea!
Appreciated your detailed post.
---
### Author:  [@Dave](https://threatmodelingconnect.discourse.group/u/Dave)
#### Post date: [September 11, 2025, 8:54am UTC](https://threatmodelingconnect.discourse.group/t/what-s-in-your-threat-modeling-toolbox/1160/6 "2025-09-11T08:54:13Z")
I really wanted to strip down threat modelling to the minimum I thought was necessary and that led me to create a [template](https://docs.google.com/document/d/1DBskRZBKpolIchljkVowFsvB-xRlSVf8sPguOnxsnhU/edit) that I get dev teams to populate. It still requires work to populate, but I provide a lot of guidance as well and work with teams the first time they do it.
Populating the template completely and correctly is important for threat modelling to be effective, so I created my own tool called [threatware](https://threatware.readthedocs.io/en/main/) to lint the populated template for errors.
Since threatware works by making the threat model machine readable I added management capabilities to it that allows me to manage the lifecycle of the threat model using gitops and store a copy of the threat model in a git repo.