OWASP Threat Modeling Project
Central repository of threat modeling information, techniques, and methodologies
Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.
Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things
in the Internet of things, business processes, etc. There are very few technical products which cannot be threat modeled; more or less
rewarding, depending on how much it communicates, or interacts, with the world. Threat modeling can be done at any stage of development,
preferably early - so that the findings can inform the design.
Most of the time, a threat model includes:
Our motto is: Threat modeling: the sooner the better, but never too late.
The Threat Modeling Manifesto has adopted the 4 Questions Framework as the seminal framework to direct threat modeling efforts. Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building,
examples of helpful techniques are:
This is a “research” activity in which you want to find the main threats that apply to your application. There are many ways to approach the
question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning. Review needed changes to your process, your methodology, and how you communicate results to your stakeholders.
The effort, work, and timeframes spent on threat modeling relate to the process in which engineering is happening and products/services are
delivered. The idea that threat modeling is waterfall or ‘heavyweight’ is based on threat modeling approaches from the early 2000s. Modern
threat modeling building blocks fit well into agile and are in wide use.
When the system changes, you need to consider the security impact of those changes. Sometimes those impacts are not obvious.
Threat modeling integrates into Agile by asking “what are we working on, now, in this sprint/spike/feature?”; trying to answer this can be an important aspect of managing security debt, but trying to address it per-sprint is overwhelming. When the answer is that the system’s
architecture isn’t changing, no new processes or dataflows are being introduced, and there are no changes to the data structures being
transmitted, then it is unlikely that the answers to ‘what can go wrong’ will change. When one or more of those changes, then it’s useful to
examine what can go wrong as part of the current work package, and to understand designs trade-offs you can make, and to understand what
you’re going to address in this sprint and in the next one. The question of did we do a good job is split: the “did we address these
threats” is part of sprint delivery or merging, while the broader question is an occasional saw-sharpening task.
After a security incident, going back and checking the threat models can be an important process.
Threat modeling at a whiteboard can be a fluid exchange of ideas between diverse participants. Using the whiteboard to construct a model
that participants can rapidly change based on identified threats is a high-return activity. The models created there (or elsewhere) can be
meticulously transferred to a high-quality archival representation designed for review and presentation. Those models are useful for
documenting what’s been decided and sharing those decisions widely within an organization. These two activities are both threat modeling,
yet quite different.
Project Resources
- GitHub
- State Of Threat Modeling Report
- Threat Modeling Manifesto
- Resources tab
- OWASP Threat Model Cookbook
- OWASP Threat Dragon
- OWASP PyTM
- OWASP Ontology Driven Threat Modeling
- OWASP Threat Model Library
- OWASP SAP Threat Modeling Builder
- OWASP Cumulus - gamified threat modeling for the cloud
- OWASP Cornucopia - gamified threat modeling
- OWASP Threat Modelling Guide
- OWASP Threat Modeling Playbook
- OWASP Dragon GPT
- Threat Modeling in OWASP Security Culture
- Threat Modeling in OWASP Community Pages
Project Information
Lab Project
Classification
Documentation
Contributors
1
GitHub Stars
207
Downloads
0
Corporate Supporters
OWASP is a nonprofit foundation improving software security through open-source projects, global communities, and education. All resources are free and open to everyone.
Quick Links
Legal & Governance
SlackOWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, OWASP Boston Application Security Conference, and LASCON are trademarks of the OWASP Foundation, Inc.
© 2026, OWASP Foundation Inc. All rights reserved.