Threat Model Maturity model

 Achieving a difficult goal like having a useful, always updated Threat Models requires resources and a good strategy. Requires also to divide the big challenge in smaller step, assess progress and, in the first place define the ultimate goal. To perform those activities a maturity models is the right tool. It defines the goal as the target maturity. It also defines a series to intermediate goals in the form of lower to higher maturity targets, and is fundamental to assess the advancement and the overall quality/maturity of the Threat Models.

There are some great maturity models, for example OWASP SAMM, that helps assessing the maturity of different practices across secure development lifecycle (https://owaspsamm.org/model/design/threat-assessment/).  I've personally worked on them with great results. But the granularity and details of the parameters to assess the maturity of secure design and threat model is not enough for defining a specific strategy for successfully Threat Modeling. Based on my experience and valuable feedback from colleagues, I came with a more detailed maturity model just for Threat Modeling. As in other maturity frameworks the highest maturity, Level 3, is not the prescriptive final target for everybody. Maturity 1 or 2 al already a great place to be for a company or product.

The table below summaries the specific maturity models for Threat Modeling. 

Area	Level 1​	Level 2​	Level 3​
Process integration​	Yearly review​ ​ Threats formalised and tracked with company tools​	Integration into Agile and formal quality gates (Def of Done, Def of Ready) for change management and release criteria​ ​ Capturing and formalising of security features in place/assumptions and use them as checklist for feature development​	Explicit testing (e.g. dynamic) of identified vulnerabilities and threats​ ​ ​
Analysis granularity​	Data flow diagram or C4-Container level like diagram with trust zones and STRIDE/CIA analysis at architectural level.​ ​ Identified threat agents and attackers in/out of scope​	Feature level Analysis (abuse cases) that feed the main TM​	STRIDE analysis Sequence diagrams for endpoints TBC​ ​ Compatible and composable Threat Model among different teams​ ​ Per API endpoints detail level analysis​ ​ Custom and domain specific threat Taxonomies (e.g. LINDDUN)​ ​
Staff enablement​	Initial training and enablement​ (devs & architects)​	Security Champions specific training​	Dedicated SME for continuous TM validation​
Measurement & Metrics​	Metrics for TM completeness at Dataflow/asset level​	Metrics for TM completeness at feature level​	Superior metrics and tool: ​ Integrations for completeness of analysis and security debt​ Lead vs lag indicators performance analysis (threat model impact on security outcomes)​ ​

Every entry in the table would contribute with a specific weight to the periodic assessment of the Threat Models maturity.