Category: Software Engineering

Most small teams I talk to think threat modeling is something big companies do with a dedicated security architect, a two-week engagement and a 40-page document nobody reads afterwards. That version exists, and it’s mostly a waste. The version that works for a team of five engineers fits in a 90-minute meeting around a whiteboard and ends with a handful of tickets. STRIDE is the tool I reach for because it gives a room full of people a structured way to ask “what could go wrong here?” without needing a security specialist to lead every question.

What STRIDE actually is

STRIDE came out of Microsoft in 1999, from Loren Kohnfelder and Praerit Garg, and was popularised by Adam Shostack’s book Threat Modeling: Designing for Security. It’s a mnemonic for six threat categories, each one the violation of a property you want your system to have:

• Spoofing violates authentication. Someone claims to be a user, a service or a host they aren’t.
• Tampering violates integrity. Data in transit, at rest or in memory gets modified.
• Repudiation violates non-repudiation. Someone does something and you can’t prove it.
• Information disclosure violates confidentiality.
• Denial of service violates availability.
• Elevation of privilege violates authorization. A user or component gets capabilities it shouldn’t have.

That’s it. It isn’t a methodology on its own, and it doesn’t rank anything. It’s a checklist of question shapes. The value is that it stops the discussion from collapsing into whatever the loudest person in the room worried about last week, which in my experience is usually SQL injection.

Start from four questions, not from the acronym

Shostack frames the whole exercise as four questions, and the Threat Modeling Manifesto (2020) kept them:

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?

STRIDE only answers question two. Teams that skip question one end up applying STRIDE to a vague mental picture of “the system”, which produces vague threats like “an attacker could spoof a user”. True, useless.

So answer question one concretely. Pick one feature or one change, not the whole platform. “We’re adding a webhook receiver that accepts events from our payment provider and updates order status” is a good scope. “Our backend” is not.

Draw a data flow diagram with trust boundaries

The diagram is where most of the value comes from, and it should take 15 to 20 minutes. You need four kinds of things:

• External entities: users, third-party services, anything you don’t control.
• Processes: your services, workers, lambdas.
• Data stores: databases, queues, buckets, caches.
• Data flows: arrows between them, labelled with what moves and over what protocol.

Then draw trust boundaries, the dashed lines where the level of trust changes. Internet to your load balancer. Your API to the database. Your worker to the third-party API. Your app to the admin interface. If a flow crosses a dashed line, that’s where you spend your time. Flows entirely inside one trust zone rarely produce interesting threats.

For the webhook example, the boundaries are the payment provider to your public endpoint, your receiver to the queue, and the worker to the orders database. Three crossings. That’s a manageable meeting.

Walk STRIDE per element

The variant that works best for small teams is STRIDE-per-element. Not every category applies to every kind of element, and the classic mapping keeps the discussion short:

• External entities: spoofing and repudiation.
• Processes: all six.
• Data stores: tampering, information disclosure, denial of service, and repudiation if the store is a log.
• Data flows: tampering, information disclosure, denial of service.

Go element by element along the flows that cross a boundary and ask each applicable question out loud. For the webhook receiver it might go like this:

• Spoofing: can anyone on the internet POST a fake “payment succeeded” event? Do we verify the provider’s signature, and do we compare it in constant time?
• Tampering: can a valid event be replayed? Is there a timestamp in the signed payload, and do we reject old ones?
• Repudiation: if an order flips to paid by mistake, can we show which event did it and where it came from?
• Information disclosure: do our error responses leak stack traces or internal hostnames to the caller?
• Denial of service: what happens if someone sends 10,000 large bodies a second? Is there a size limit before we parse JSON?
• Elevation of privilege: does the worker’s database role need to write to anything except the orders table?

Every one of those is a concrete, testable question, and most of them are a few lines of code to fix. That’s the point.

Record threats as tickets, not as a document

The output of the session is a list of threats, each with a decision. Mitigate, accept, transfer or eliminate the feature. I like a plain table in the repo next to the code, because it gets reviewed in pull requests and it ages with the system:

| ID | Element            | STRIDE | Threat                                  | Decision  | Ticket   |
|----|--------------------|--------|-----------------------------------------|-----------|----------|
| W1 | Webhook endpoint   | S      | Forged event without valid signature    | Mitigate  | PAY-412  |
| W2 | Webhook endpoint   | T      | Replay of a captured valid event        | Mitigate  | PAY-413  |
| W3 | Receiver -> queue  | D      | Unbounded body size exhausts memory     | Mitigate  | PAY-414  |
| W4 | Worker DB role     | E      | Role can write to users table           | Mitigate  | PAY-415  |
| W5 | Provider outage    | D      | Events delayed for hours                | Accept    | -        |

Accepted risks are fine. Write down who accepted them. A threat model where everything is “mitigate” usually means nobody was honest about the effort.

Making it stick on a small team

The failure mode isn’t doing threat modeling badly. It’s doing it once at a kickoff and never again. A few habits keep it alive.

Tie it to design review. If a change adds a new trust boundary crossing, a new external entity or a new data store with sensitive data, it gets a STRIDE pass. Everything else doesn’t. That keeps it rare enough that people don’t resent it.

Rotate who facilitates. The facilitator’s job is to keep the group moving through the elements and to stop the session from becoming a design argument. Any engineer can do that after watching it twice, and the person who facilitates tends to start thinking this way in code review too.

Keep the diagram in the repo as text. A diagram drawn in a SaaS whiteboard is dead the day the meeting ends. Mermaid, PlantUML or OWASP Threat Dragon’s JSON files all diff fine. Microsoft’s Threat Modeling Tool is also free if your team is on Windows and wants STRIDE suggestions generated from the diagram, though I find the generated list too long for a small team to triage.

Revisit question four. A month after the feature ships, spend ten minutes asking whether any incident, bug report or pentest finding touched an element you modeled. If one did and the model missed it, that’s the most useful feedback you’ll get about your process.

Where STRIDE falls short

STRIDE is good at technical threats along data flows. It’s weak on abuse of legitimate functionality, like a referral program being farmed, and on privacy harms, where LINDDUN is a better fit. It also says nothing about likelihood. When a session produces more threats than you can fix, rank them by what an attacker can reach from outside your trust boundaries first, and by what you’d have to explain in an incident report second. That’s crude, and it’s still better than ranking by gut feeling about which bug sounds scariest.

I’ve watched a five-person team find a missing webhook signature check, an admin endpoint reachable from the public load balancer and a worker with database superuser rights, all in one 90-minute session. Nobody in the room was a security specialist. They just drew the thing and asked the questions in order.