In the Security Champion Program Success Guide blog, I invite industry professionals to share their experiences and viewpoints about Security Champion programs, to expand our collective knowledge and encourage healthy conversation. In this post, Hassan Ud-deen, Product Marketing Manager at ThreatModeler, explains how Champions can make threat modeling a regular part of how their teams design software, and how to introduce it as a set of Ideal Actions that grows with your program. Threat modeling is often the activity that moves a program from participation and learning into preventing issues, so I’m glad to have Hassan’s perspective here. Enjoy! – Dustin Lehr
Making threat modeling part of everyday development
Threat modeling helps a team understand what could go wrong with a system and decide how to address it. Start by mapping how a feature works: its components, the data moving between them, and the boundaries where access or permissions change. Then answer the following four questions:
1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?
Methods like STRIDE help teams explore potential threats systematically. The aim is to turn that discussion into design decisions, agreed actions, and a way to check that those actions worked.
Making this a regular practice across development teams takes more than a good workshop. If every session depends on the central security team, coverage is limited by that team’s availability. Developers also hold context that a visiting reviewer may miss: a changed dependency, an undocumented connection, or a temporary workaround that has become permanent.
Security champions help bring that knowledge into the review. With training, time, and support from security, they can make threat modeling part of their team’s design process.
Why champions are the right people to do it
Champions work alongside the people building the system. That gives them a useful starting point for threat modeling:
- Context. They know how their team’s software works and where the documentation may be out of date. A detail such as “that service now connects directly to the database” can change the discussion.
- Trust. An established working relationship makes it easier to ask questions, challenge assumptions, and talk openly about shortcuts or uncertainties.
- Coverage. Trained champions can lead focused reviews within their teams and bring in security specialists when the design needs closer attention.
- Shared expertise. Champions can help teammates get better at spotting risks and making security decisions, without expecting everyone to become a specialist.
Threat modeling also rewards champions. It is one of the most transferable skills in application security, and it gives a developer a real voice in architecture discussions. Leading sessions also grows their understanding of architecture, their security judgment, and their ability to guide technical discussions.
Introducing threat modeling in phases
Like the rest of the program, threat modeling works best when introduced gradually. Here is how it could look as Ideal Actions in your design spreadsheet:
Early actions are low-commitment and focus on learning. Later actions put champions in the driver’s seat, and those should earn the most stars.
| Ideal Action | Goal Alignment | Phase |
|---|---|---|
| Attend a threat modeling brown bag or workshop | Knowledge | Initial |
| Observe a threat modeling session led by security | Knowledge | Initial |
| Diagram a feature your team owns | Discover Issues | Intermediate |
| Co-facilitate a threat modeling session with security | Discover Issues | Intermediate |
| Lead a threat model for a new feature before development starts | Prevent Issues | Advanced |
| Track identified threats to mitigation in the backlog | Remediate Issues | Advanced |
| Mentor another champion through their first threat model | Participation | Advanced |
The biggest risk to threat modeling isn’t a lack of technical knowledge. It’s that the model becomes a static, point-in-time exercise that describes a system that no longer exists.
Whiteboards are training wheels for developers new to threat modeling. However, a whiteboard can’t survive contact with a codebase that changes weekly. A few things that help scale threat modeling within fast-paced development environments:
- Keep sessions short. Thirty to forty-five minutes around a whiteboard beats a half-day review nobody wants to attend.
- Model what the team is building now. Real features create real stakes and real discussions.
- Celebrate the findings. A threat caught at design time is a vulnerability that never shipped. Recognize it publicly in your champion channel.
- Use your motivational design. Award stars for sessions led, create a “Threat Hunter” award for your annual ceremony, or run a quarterly threat modeling challenge.
- Reduce the busywork. Diagramming and documentation can eat the time that should go into assessing critical design risks and applying controls. Templates and tooling that automate the repetitive parts let champions focus on the conversation.
Tooling can reduce the preparation and documentation involved. Platforms like ThreatModeler Nexus help teams automatically build models from architecture diagrams, and existing code or cloud environments with suggested threats and controls for review. Champions can use that starting point to check the model with their teammates and focus the session on decisions.
Measure what matters
When you get to Tuning, threat modeling gives you metrics leadership understands: features modeled before development, threats identified per session, the share mitigated before release, and how many champions have moved from observer to facilitator. Few activities in a champion program connect so directly to reduced risk.
The bottom line
Participation and knowledge get your program off the ground. Threat modeling is what turns an engaged community into a real line of defense, because it moves security to the one place where fixing a problem costs almost nothing: the design. If you’re planning your program’s next phase, make threat modeling one of your Ideal Actions.
Want to share your own viewpoint or case study about security champions to post on this site? Contact me on LinkedIn and let’s chat! — Dustin Lehr
