Once a team has run a few threat models, a new question appears: are we getting better at this? Leadership wants to know whether the time is well spent; security teams want to know where to invest next. A maturity model gives a shared answer, as long as you measure what threat modeling is actually for.
What maturity means here
Threat modeling maturity is not about which method you use. A team that runs a simple four-question session on every significant change is more mature than one that runs a full PASTA exercise once a year. Maturity is about three things:
- Coverage: are the systems that matter modelled?
- Consistency: do teams follow a common approach, so results can be compared and trusted?
- Effect: do the models change designs and reduce risk, and are they kept current?
OWASP SAMM: Threat Assessment
OWASP's Software Assurance Maturity Model (SAMM) is an open framework for assessing a software security programme. Version 2 places threat modeling in the Design business function, under the Threat Assessment practice, which has two streams: A, application risk profile and B, threat modeling. Each stream has three maturity levels:
| Level | Application risk profile | Threat modeling |
|---|---|---|
| 1. Best effort | A basic assessment of each application's risk, to identify which ones matter most | Ad-hoc threat modeling of high-risk applications, using simple checklists or methods such as STRIDE |
| 2. Standardised | A central inventory of risk profiles, built with a common method, used to decide where to invest | A standard methodology and training, applied consistently across teams, with reusable threat libraries and outputs fed into the risk process |
| 3. Optimised | Risk profiles reviewed regularly and kept current as applications and threats change | Threat models maintained throughout development, integrated with tooling, and the methodology improved based on feedback and outcomes |
The levels are cumulative: level 2 assumes level 1 is in place. BSIMM, a descriptive model built from observing real security programmes, covers similar ground in its Architecture Analysis practice.
Metrics that show real progress
| Metric | Tells you | Watch out for |
|---|---|---|
| Share of high-risk systems with a threat model | Coverage where it matters | Counting stale models as coverage |
| Median age of the last model review | Whether models stay current | Cosmetic edits that reset the clock |
| Share of high and critical risks with a decision and owner | Whether question three gets answered | "Accepted" with no reason or review date |
| Design changes made because of a threat model | Actual influence on systems | Hard to count unless teams record them |
| Pen test or incident findings the model missed | Quality of the analysis | Blame; use it to improve the method |
| Time from threat found to mitigation shipped | Whether findings turn into work | Only tracking the easy ones |
Start with the first and third: they're easy to measure and immediately useful. Add the others as the practice stabilises.
Worked example: Invoicely
Imagine Invoicely a year on, with six product teams. A maturity self-assessment:
- Risk profile: level 2. Every service has a one-line risk rating based on the data it handles (the CIA priority of its assets), kept in one list.
- Threat modeling: between levels 1 and 2. The billing and API teams model every significant change; two newer teams have never done one.
- Metrics: 4 of 6 high-risk services have a model reviewed in the last six months; 92% of high risks have an owner; three design changes in the last quarter came from threat models, including dropping the logo-from-URL feature in favour of uploads (the SSRF example).
The next step is clear and modest: a one-hour session for the two new teams using the existing template, and a review reminder in CI using the threat-modeling-as-code check.
How to move up a level
- Ad hoc to standard: pick one method and one template, train a champion in each team, and agree which systems must have a model. Our guide to getting buy-in helps with the conversation.
- Standard to optimised: connect models to the development workflow (tickets, pull requests, CI), schedule reviews based on risk, and feed missed findings back into your checklists and threat libraries.
Common mistakes
- Measuring activity, not outcomes. "Number of threat modeling sessions held" rewards meetings, not risk reduction.
- Aiming for level 3 everywhere. Low-risk internal tools may never need more than level 1.
- A central team that does all the modeling. It doesn't scale. Maturity means product teams can do it themselves, with security as reviewers.
Key takeaways
- Maturity is about consistency and outcomes, not about which methodology you use.
- OWASP SAMM's Threat Assessment practice gives three levels across two streams: application risk profiles and threat modeling.
- Coverage metrics (how many systems have a current model) are a start; outcome metrics (findings fixed before release) show real value.
- Move one level at a time. Most organisations get the biggest gain from going from ad hoc to a standard, risk-based practice.
Frequently asked questions
What is a threat modeling maturity model?
A framework that describes stages of a threat modeling practice, from ad hoc to optimised, so an organisation can assess where it is and decide what to improve next. OWASP SAMM's Threat Assessment practice is the most widely used open model.
What are the levels of OWASP SAMM Threat Assessment?
Level 1 is a best-effort, basic practice: a simple risk classification of applications and ad-hoc threat modeling for high-risk ones. Level 2 standardises it: a central risk profile inventory and a common methodology applied across applications. Level 3 optimises it: profiles and models are reviewed regularly, improved from feedback and integrated with development.
What metrics should a threat modeling programme track?
Useful ones include the share of high-risk systems with a current threat model, the time since each model was last reviewed, the number of design changes made because of threat models, the share of high risks with a decision and owner, and incidents or pen test findings that the threat model missed.
How long does it take to mature a threat modeling programme?
Moving from ad hoc to a standard practice across the most important systems typically takes six to twelve months in a mid-sized engineering organisation. Reaching an optimised, continuously reviewed practice takes longer and depends on tooling and leadership support.