Software rarely becomes secure by luck. Security usually depends on deliberate engineering work: examining how a system might be attacked, deciding which risks matter and changing the design before weaknesses become embedded in it. Threat modelling provides a way to do that work, yet it is still an unusual activity on many development teams. It may happen because someone on the team has a strong personal interest in security, or because the organisation has adopted a formal set of security practices. Neither condition can be assumed.
That leaves an important question: how can threat modelling become a normal part of building software, rather than an activity reserved for the few teams with ready access to security expertise?
The value and limits of expert-led threat modelling
Threat modelling has traditionally been led by security specialists. Many have learned the practice through an informal apprenticeship: working alongside experienced colleagues, studying previous failures and gradually developing the judgement to recognise where a design might be vulnerable.
It is therefore tempting to conclude that specialists should always lead threat modelling. But an approach centred entirely on experts has limits. Security specialists are scarce, and they cannot attend every design discussion. They may also need time to understand a system that its developers already know in detail. If threat modelling depends on their availability, opportunities to identify risks during everyday development can be missed.
What developers bring to the process
Developers have knowledge that is essential to a useful threat model. They know what the code really does, where the design differs from the original plan and which changes would be straightforward or costly. They understand the practical trade-offs involved in a proposed mitigation.
They are also present when decisions are made. Some of the most consequential choices about data flows, trust boundaries and system behaviour emerge in informal conversations or at a whiteboard, long before a formal security review takes place. A developer who knows how to ask basic threat modelling questions can bring security into those conversations while the design is still taking shape.
This does not mean expecting every developer to become a security specialist. It means giving developers enough knowledge and structure to identify common threats, question assumptions and recognise when a problem needs expert attention. Specialists can then spend more of their time on the unusual, subtle or high-impact issues where their experience adds the most value.
Closing the gap between development and security
Involving developers also changes the relationship between development and security teams. When security work remains solely in the hands of specialists, it can reinforce a divide: one group builds the system and another arrives to identify problems with it. Devs say “please?”, security says “no”.
If those problems surface after key decisions have been made, addressing them can mean substantial rework. Developers may see security as an obstacle to delivery, while specialists may interpret resistance as a failure to take risks seriously. The engineering constraints and security reasoning behind each position can get lost.
Giving developers an active role in threat modelling brings that conversation forward. Developers explain how the system works and what changing it would involve; specialists explain how it could be attacked and why the risks matter. Together, they can challenge assumptions and choose mitigations that are effective and practical.
This builds shared ownership of security. Both groups contribute to understanding the risks and deciding how to address them, making security part of the design process rather than a handover of findings.
Making security part of design
Developers are present when many consequential decisions are made. Choices about how data moves, which components are trusted and how users interact with a system often emerge during ordinary conversations around a whiteboard.
Giving developers the skills to recognise potential security issues allows threat modelling to enter those discussions. A questionable assumption can be challenged while the design is still flexible, and the team can consider its security implications alongside functionality and other engineering concerns.
When security becomes part of ordinary design conversations, teams have more chances to find weaknesses early and build systems that are more resilient as a result.
This article draws on Adam Shostack’s white paper, Elevation of Privilege: Drawing Developers into Threat Modeling, written during his time at Microsoft.
