Forget Threat Modeling?!?

  • 10 February 2023
  • 6 replies
Forget Threat Modeling?!?
Userlevel 4

Secure coding guru extraordinaire, Jim Manico, has in the past opined, “Forget threat models.”

One of Jim’s many superpowers is focusing attention so that people will thoughtfully consider the issues he’s raising. Often, he points out to us that, “the emperor has no clothes”, i.e., our practices are insufficient or downright dysfunctional. To be sure, some threat modelling approaches can, indeed, hurt more than help.

When I’ve discussed this with Jim, I agree with what I understand his chief criticism to be: If the threat model is built to make security people feel good, it’s useless, don’t bother.

Threat models have several important uses, none of which is to salve infosec anxiety.

Testing map: A catalog of possible attack vectors and techniques (a “threat library” correlated to the target system’s attack surfaces) provides a necessary prelude to testing. Typically, skilled penetration testers will build this type of model as they prepare to test.

Risk discovery: Once a threat library has been identified, adding a risk rating to each credible attack scenario provides decision makers with data that can be used for choosing security-related investments. A risk discovery model helps decide which are the most important items to address and which may be deprioritized or delayed, i.e., as a strategy input.

Development: This model is a superset of the model types above. Derive mitigations based upon the above model’s attacks, attack surfaces, and risk ratings. That is, build a model that is useful to developers so that they may discover existing weaknesses and anticipate those that have some likelihood of showing up in the future. The intention is to build software that is resilient.

The development model is what we use in software security. It gets the most attention in articles, panels, and so forth, and is the model to which various AppSec standards and directives refer. 

AppSec focus does not diminish the usefulness of other types of models. The other two types may very well be generated by security experts (a penetration tester or a risk and compliance expert) and may require limited input from others. 

On the other hand, development models, that is models intended to drive secure design decision making, models intended to identify security that will be built as part of a system, really don‘t work well when the following occur: 

  • Security expert parachutes into an ongoing development team exactly once

  • Security expert renders a model in isolation producing a bunch of work (security features and requirements) with little or worse, no reference to development methodologies and cycles, nor those business imperatives that the developers must heed

  • Expert drops the additional work on the development team, then

  • Expert disappears but expects developers to accept the model and its decisions without question

💡 Learn more about the common pitfalls in running threat modeling program in “The Hitchhiker Guide for Failing TMs” by@Michael Bernhardt. The Threat Modeling Manifesto also lists some common dysfunctions.

Indeed, I’ve seen this type of “threat modelling” all too often. I concur with Jim that the model tends to be so completely out of phase with developer needs that it too often causes more harm than help.

  • The model is too late, causing expensive rework

  • The model quickly becomes obsolete and out of sync due to the dynamic nature of development especially in Agile shops (which is today’s norm)

  • A parachute/drop/disappear, point-in-time process generates enormous amounts of ill-will and interdepartmental friction

  • This process misses the opportunity to foster security thinking throughout development

Threat modelling mustn’t be thought of as an out-of-band “thing” done to “please” security. 

Threat modelling is an analysis technique. It’s not really different in timing than considering performance, scale, usability, etc. To build appropriate security, we have to consider attacks and their defenses (at varying levels of specificity, true!), just as we consider all the other factors that running software must face. We ask, “how can we help this software survive its likely adversaries?” Hence, threat modelling is best performed as a natural and organic part of development. 

Usually threat modelling is an integral input to structure (architecture) and design (though certainly not the only input). Threat modelling must be one of the analyses that are taken up in whatever manner and timing design is arrived at.

Plus, in my very humble experience, threat modelling is very much a “team sport”; the model is improved greatly through inclusive, multi-discipline/knowledge participation. Very much as Agile SCRUM improves development through the active participation of every member of the SCRUM team, so too, threat modelling benefits from thoughtful input from almost everyone involved throughout the software creation, implementation, and operation process.

In that respect, Mr. Manico is exactly right. Software security (development) threat modelling by and for security doesn’t usually provide enough value while too often leading to dysfunction. 

If a model isn’t useful to its consumers, why build it?



  1. To be clear, Jim has contributed greatly to the OWASP Application Security Verification Standard in which the first step is “Architecture, Design, and Threat Modeling”.
  2. Several Threat Modeling Connect members have authored books on software security threat modelling, including this author. Please see @Adam Shostack, @izar, @Chris Romeo, etc. Readers may also want to look at the Threat Modeling Manifesto, which summarizes best practices and lessons learnt.
  3. Regarding the last point about the scenarios where the development model doesn’t work well, I have never met a competent engineer who didn’t hesitate to question engineering decisions when necessary. I encourage those discussions. Good engineering requires review and critique.

6 replies

Userlevel 4

But wait! “Threat models have several important uses, none of which is to salve infosec anxiety.” - as a pretty anxious one myself, I’d counter that the clarity and visibility you just exhibited goes far in reducing infosec anxiety! You just pointed at so many “we didn’t know before, now we do” angles that I think it counts as Infosec Valium.’


Userlevel 4
Badge +1

I double-down on everything that you say, Brook! Especially ‘Threat modelling mustn’t be thought of as an out-of-band “thing” done to “please” security.’.

Just one thing hits the reality check when you say that ‘threat modelling is best performed as a natural and organic part of development’. I see it still a reality that in contrast to other activities, the proactive security assessment still doesn’t find its way into effort planning. As per the saying ‘No cookies without hands’, it would thereby remain a best practice guidance that is all too often not lived. But I’m with you in the desire to lead it into that direction.

Userlevel 4

Manico has reversed his conclusion on threat modeling. Izar and I heard it live at LasCON 2022. Here is a link to the keynote: 


Userlevel 4

@izar If we actually produce useful threat models (which vary according to use case and audience) then my experience with hundreds of security folk suggests that, indeed, security will generally be happy.


But not all, sadly. Some of security’s old myths and misconceptions seem remarkably resistant to change and have stubborn inheritance strength. People 3 generations descended from my cohort who’ve adopted the very mistakes we have tried to undo! It’s maddening, frankly. 


Much received infosec wisdom is incorrect and is as resilient as any other folklore custom. Among these, “Security must tightly control threat modelling, or disaster will strike” - not true, but still practiced.


Userlevel 4

@Michael Bernhardt There are so many factors that get in the way/prevent/discourage proper timing in threat modelling, I can’t respond directly too well in a reply. Lots of behaviours can contribute to this problem.

Frankly the only really effective way that I’ve been able to solve it is to put it back on to developers and security in the same room. My trick goes something like this, assuming I have dev and security in the same room:

“Developers, how do you like getting your security requirements late so that they inject into and interrupt what you’ve worked hard on?” The developers boo, hiss, hold their thumbs down. (they will, trust me)

“Security folk, how do you like being engaged when development has proceeded so far that your contribution will interrupt, it’s too late to be effective, cause friction between you and your partners?” Again, thumbs down, boo, hiss, negative reactions.

“So, why do you continue to do this? Security, did you hear dev? Dev, did you see how this doesn’t work for security?” 

“Come on, folks! You can fix this. Dev, thinking of doing something new? Reach out to security; make sure their involved. Security, you know who your partners are. Call them; ask what’s new, what’s coming in for the next cycle.”

Really, for all the nice SDL graphics, and policies, and management mandates, none of these fix this problem (IMVHE). but pointing out to those involved that they are creating their own problems fixes it totally. 

Sometimes, we just have to look reality in the face and take some responsibility and stop blaming someone else.


At leasat, 4 programmes, this has worked marvellously for me.

Userlevel 4
Badge +1

@Brook Schoenfield Indeed that kind of communication helps to improve the exchange between Dev and Security. Yet, if it was a systemic issue I rather prefer to take the extra effort from security side and raise it to the program management level. As security team imho we should not only aim for somehow make it work with the dev teams but also raise the challenging questions to the ones that should enable dev teams to work. Otherwise it may remain seen as a personal contradiction between dev and security team. I have seen it working best if one is using the eloquance for addressing this kind of issues and one is aware of all the little screws (audit, compliance, risk management, ...) that can be of help.