Security is easiest to add when nothing has been built yet.

That sounds obvious, but it’s the most expensive lesson teams learn the hard way. Once a system is deployed, every “security fix” becomes a negotiation with time, budget, and inertia. In the design phase, it can be a decision. That’s what people mean by secure by design, and threat modelling is one of the few practices that makes that phrase real.

I recently took part in a threat modelling hackathon and it was a reminder of something that doesn’t show up in most process diagrams: different people see different threats. Put engineers, architects, and security together around the same design and you get a broader attack surface map almost immediately. The value isn’t just in what gets found. It’s in the shared understanding of how the system could fail and what “good” needs to look like.

Threat modelling, in plain terms

Threat modelling is a structured way of identifying what could go wrong in a system before you commit to building it. It helps teams reason about adversaries, failure modes, and control gaps while the cost of change is still low.

It’s often described as arduous, full of diagrams and long, technical workshops. Sometimes it is. But it doesn’t have to be. The challenge is less the methodology and more the engagement: getting a room full of busy people to meaningfully participate without it feeling like a compliance ritual.

That’s where a surprisingly effective trick comes in: make it collaborative and lightweight enough that teams actually want to do it.

The “in the wild” technique that worked

On a programme in London with 40+ development teams, one of the most effective ways to get threat modelling adopted was Elevation of Privilege—a card game designed by Adam Shostack to guide teams through STRIDE threats. It sounds gimmicky until you see it work.

The game breaks down the social barrier between “security people” and “builders”. Instead of security acting like a referee at the end of the sprint, it becomes a facilitated conversation where everyone contributes. It turns threat modelling from “that thing security makes us do” into “a structured conversation we can actually finish”.

It also works well in remote environments. Even when teams aren’t physically together, the structure still holds: one shared diagram, a set of prompts, and a facilitated walkthrough that helps people generate threats without having to be threat-modelling experts.

Why do it in the pipeline?

Threat modelling belongs in the development pipeline because it changes decisions when decisions are still cheap.

A good threat modelling session does a few things at once:

• It surfaces threats early, before architecture choices calcify.
• It forces trade-offs to be explicit (security, cost, complexity, delivery time).
• It gives teams a shared language to talk about risk.
• It drives better engineering decisions—authentication flows, trust boundaries, logging, data handling—because people have mentally “walked the attack” before writing code.
• It upskills teams through participation. You can watch someone’s mental model expand in real time when another engineer describes an attack path they hadn’t considered.

The underrated benefit is momentum. If teams threat model early and often, security stops being a last-minute surprise.

STRIDE as a practical lens

STRIDE works because it’s simple enough to hold in your head and comprehensive enough to be useful. It gives teams a set of threat categories they can methodically walk through without being overwhelmed.

• Spoofing: “Can someone pretend to be someone else?”
• Tampering: “Can someone modify data or code without permission?”
• Repudiation: “Can someone deny they did a thing because we can’t prove it?”
• Information disclosure: “Can secrets leak—data, credentials, internal logic?”
• Denial of service: “Can someone make this unusable or unreliable?”
• Elevation of privilege: “Can someone gain permissions they shouldn’t have?”

A small facilitation tip that works well: start with spoofing. It’s an easy entry point for most teams because it maps directly to auth, identity, sessions, tokens, and access control—things developers already think about. Once people warm up, the other categories come more naturally.

Making threat modelling stick

Threat modelling succeeds when it’s treated as a team habit, not a security ceremony.

A few patterns that consistently help: - Keep sessions short and repeatable rather than massive and rare. - Anchor threat modelling to real artefacts: architecture diagrams, data flows, sequence diagrams, deployment models. - Capture outputs in a way teams will actually reuse: threats, assumptions, controls, and owners—lightweight, not a novel. - Build “security facilitation” capability, not dependency. The goal is for teams to be able to run sessions without security in the room every time. - Use familiar references like OWASP Top 10 as supporting material, but don’t let the session turn into a generic vulnerability lecture. It should stay anchored to this system.

Learning in community

If you’ve never built a full threat model for a system, one of the fastest ways to level up is to do it alongside other practitioners. Communities like Threat Modelling Connect and hackathons are great for that. Seeing how other people structure outputs—and how differently they can interpret the same system—makes you better quickly.

And it would be a miss not to mention Adam Shostack here. A lot of modern threat modelling practice traces back to his work, and if you want a deep but practical grounding, his books are genuinely useful—especially if you’re trying to make threat modelling land with engineers rather than just security specialists.

---

Adam Shostack: https://shostack.org/about/adam
Threats: What Every Engineer Should Learn from Star Wars: https://threatsbook.com