The Threat Modeling Habit

Threat modeling is a way of institutionalizing proactive security reviews. For us, it’s less about a rigid toolchain and more about creating a recurring forum where security engineers and product engineers can debate the design of a system before and after it ships. The material output is a list of prioritized risks and mitigations; the more important result is the ongoing conversation itself.

A productive threat modeling session aims to accomplish three things. First, get the architecture on the table so that everyone—particularly the engineers who own the code—has an accurate, shared picture of how the system is actually built. Second, look at the full attack surface and identify the weak points where compromise is most likely. Third, capture those findings as prioritized mitigation strategies, because no team has unlimited time or budget to fix everything at once.

When to Run a Threat Model

The best prerequisite for security review is rhythm. We prefer to schedule threat modeling on a regular cadence with each feature team, and also ahead of any release that meaningfully changes the architecture. The right frequency depends on the amount of engineering churn; a fast-moving feature might need a session every couple of months, while a stable service can be reviewed annually. Folding the exercise into an existing review process instead of bolting on a separate one helps the habit take root without disrupting engineering flow.

Preparing for the Session

The preparatory work matters as much as the meeting itself. We ask each engineering team to prepare a threat model before the session, covering the chunk of the system to be reviewed. Documentation and examples are shared from the security side so expectations are clear. Common targets for output are the diagrams created in Microsoft’s Threat Modeling Tool or OWASP’s Threat Dragon—both free. The diagrams are a useful way to visualize APIs, trust boundaries, dependencies, datastores, and authentication mechanisms; they also provide an artifact for compliance or audit purposes later. The key expectation to set is that the engineering team comes with a model in hand. That way, the meeting is spent discussing findings, not trying to understand what piece of the system is under the microscope.

Running the Review

A focused review session typically runs about an hour, split into two parts.

The first five to ten minutes are spent walking through the design. The engineering team explains the technologies, the data flow, and any quirks in the architecture. This ensures the security team is looking at the same blueprint everyone else is, and surfaces any discrepancies from the written threat model.

With alignment on the architecture, we move into the security discussion. To keep the thinking systematic, we map candidate vulnerabilities to the STRIDE framework—Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation of Privilege—which ensures a broad sweep across common attack classes. The remainder of the hour is spent stepping through each category as it applies to the pipeline and design of the system, often pushing into corners that the initial walkthrough didn't cover.

Any weakness or design flaw that comes up is noted alongside candidate remediations. Those notes become the basis for a list of recommended changes shared with the engineering team after the session. A quirk of this format is that, as teams internalize the process, some of them begin engaging security earlier in the development cycle, which is ideal. When threat modeling is happening on the whiteboard before an implementation is set in stone, the cost of addressing the issue drops sharply.

The session ends by recapping the key findings and defining concrete tracking items for each. A summary of the session goes out to all attendees, and follow-up questions are encouraged so the action items are fully fleshed out.

The Org-Wide Returns

Having repeated this cycle across multiple teams and services, several recurring benefits emerged.

Stronger overall security posture. Bringing a full system into view at once lets engineers see beyond their immediate area of responsibility and what the attack surface looks like in aggregate. The mitigations that come out of those discussions improve the entire environment, not just the service under review.

Earlier design intervention. Over time, teams that threat model move the exercise “left” in the development lifecycle. Instead of security teams playing catch-up on vulnerabilities discovered after release, they sometimes get a chance to steer teams away from risky architectural decisions at the design stage. Those shifts are much cheaper to make before code exists.

Better working relationships between teams. Recurring meetings naturally lower the friction of cross-team communication. When engineering and security know each other from a shared structured exercise, a quick technical question between sessions goes a lot further than a formal outreach through the proper channel.

Process Checklist

To consolidate the practice, the following points will get a team to a working threat modeling loop:

  • Attach threat modeling to an existing development cycle or review cadence, and automate what you can.
  • Make sure the team brings a complete model to the session—come prepared, and you've won half the battle.
  • Use a structured framework like STRIDE to be methodical about which risk categories you are checking.
  • Exit every session with explicit, prioritized action items assigned to people.
  • Follow up to verify that the follow-ups actually landed.