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?
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.
Original post by @wgildersleeve
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.