Threat modelling to bridge design and development - SDP Breakout Padlet Summary - 09/11/2020

Key Themes

Secure development, threat modelling, design, collaboration and the perceived efficacy vs real value.


Threat modelling directly effects system design and is embedded in system development. By its nature it forces the creation of explicit requirements, processes and design. Doing so in such a way, that it being secure is ensured by virtue of the activity. It helps teams develop design requirements and security requirements simultaneously and by hosting it collaboratively, helps communicate this shared understanding throughout the entire developing team and the related project managers.

As such, the scope of work can be considered large and time-consuming by management, it gets labelled as extensive upfront investment. Naturally leading into a desire for ‘something lightweight’. With threat modelling being abstract and not necessarily a ‘defined’ process (there are as many ways to threat model as there are threat modellers), there exists a vernacular that must be taught prior to the first session to enable effective communication (a maze of twisty little terminology wars - Adam Shostack). However, if done it provides a common language between different groups in an organisation and helps facilitate non-experts communication of ‘difficult’ security technical conversations by giving a shared lexicon of threats, vulnerabilities and mitigations.

The perceived up-front investment and cost seem to make management shy away from using threat modelling and steers them towards more lightweight solutions. To ensure that threat modelling is able to help and to prove that it warrants adoption, a body of research to deduce threat modelling efficacy in different environments is needed. Further research is required to deduce what this shared lexicon should include and if introducing it helps bring more security driven conversations between design and development.


  • Managements perception of TM session is a ‘waste’ - people AFK etc
  • Seems like upfront cost (unclear benefits)
  • Dysfunctional environments
  • Silver Bullet Thinking
  • The Greenfield Mirage
  • Terminology and language is muddled and can be confusing


  • Design is often a part of development
  • Threat-design, as opposed to design/develop and then address vulns
  • TM can provide common language between different groups
  • TM can be done collaboratively - across design and development teams (and other roles: product owners, security engineers, infrastructure, QA, product management, BA, project management)
  • TM can inform decisions development teams are making
  • Desire for something more lightweight

Contact Information

Thanks for reading this far, if you have any questions or thoughts about this post, feel free to let me know at