Getting Developers engaged in threat modeling?

  • 18 September 2023
  • 3 replies

Userlevel 3

What approach does everyone use to get developers engaged in the threat modeling process? Have you found that developers are generally open to getting involved and see the value in shifting left or do they look at it like its just going to add additional work for their teams? 

3 replies

Userlevel 2

Here’s a couple of things I focus on:

  • I try to have a really well defined and documented process, with clear output artifacts.  That conveys the message that the process is not something being developed or being ‘tried out’, but rather it’s a formal company process.
  • Often you can find some teams who are more interested in threat modelling, so start with them, and make the output from them available to all developers.  This shows the other teams that the process is not just for them, they aren’t the first, and won’t be the last.

In my experience getting developers or teams involved isn’t actually all that related to threat modelling at all - I think most teams appreciate security and are willing to do an activity that could improve security.  I think its the maturity of the process that matters more, so look to the other processes the team has, and mimic the ways those process seem mature (docs, broad uptake, governance, clear outputs etc.).  Create a process that respects the developers time, and they’ll respect the process.

Userlevel 1

As a recovering engineer myself, I remember having fairly strong tunnel-vision. I simply wasn't interested in anything that didn't have to do with my job. If it was important for what I was doing, then no problem, but otherwise don't bother me.

Which goes along with what Dave is saying--you have to make it relevant to the teams. Devs understand the need for security, so it simply becomes a matter of showing the efficacy of threat modelling.

Userlevel 2

Most development activity happens in the code that runs on that relatively unchanging architecture. You can model the functions of an application and iterate on designs before writing code, or as part of threat modeling user stories.

Identifying plausible cyber threats is a core step in threat modeling, but taking action is what leads to improved security. Development teams need to refine their threat model outputs, determine which countermeasures to act on, identify those that aren’t relevant, and which ones have already been implemented.

Finding a solution that will help Dev’s threat model application behaviour / functions will go a long way in getting their buy in especially if this is automated.