Do we need a dedicated security engineer to run this?

No. Any senior engineer with a checklist and 90 minutes can run a competent threat model. Bring in outside expertise (consultant, security engineer at a friend's company) for the first two or three sessions to calibrate; then it becomes muscle memory.

How is this different from a pentest?

Pentests find implementation bugs in shipped code ('this endpoint has SQL injection'). Threat models find design flaws in unshipped systems ('this endpoint shouldn't exist without an authz check because there is no way to enforce it later'). You need both. Threat modeling is 10x cheaper because refactoring a diagram takes minutes and refactoring production code takes weeks.

What if the team resists?

Start with a real incident — yours or a public one (LastPass, Okta, MOVEit). Walk through it as if you were threat-modeling the pre-incident design. Engineers who see how a 90-minute meeting would have caught it become believers quickly.

Threat Modeling: STRIDE, Data Flow Diagrams, and Practical

Threat modeling is the structured practice of asking 'what could go wrong?' during design — before code is written.

Threat Modeling: Finding Design Flaws Before Attackers Do

Threat modeling is design review with an adversarial lens. A small team walks through a proposed system, systematically enumerates ways it could be attacked or abused, and decides which risks to mitigate now vs. accept. Unlike pentests (which find implementation bugs), threat modeling finds design flaws — the kind that would cost weeks to refactor after launch. It is cheap, it is high-leverage, and most startups skip it entirely.

When to threat-model

Model at design time for any feature that (1) handles authentication, authorization, or session state; (2) processes payments, PII, or regulated data; (3) exposes a new external surface (public API, webhook receiver, file upload); (4) crosses a trust boundary (customer data touched by a third party, cross-tenant queries); (5) is a rewrite of a previous system where legacy assumptions may not carry forward. Skip for pure UI changes, internal tooling with no sensitive data, and simple CRUD on existing schemas.

STRIDE as a checklist

Microsoft's STRIDE gives you six categories to walk through for each component and data flow: Spoofing (can someone impersonate a user or service?), Tampering (can data be modified in transit or at rest?), Repudiation (can an actor deny performing an action?), Information disclosure (can data leak?), Denial of service (can availability be degraded?), Elevation of privilege (can a low-privilege actor gain higher access?). Walk through each pairing; note real threats; discard ones that don't apply. STRIDE is not the only framework (PASTA, LINDDUN for privacy) but it is the fastest to teach a team.

Data flow diagrams, kept simple

Draw the system as boxes (processes), cylinders (data stores), arrows (data flows), and dashed lines (trust boundaries — where data crosses from one authority to another). Every arrow crossing a trust boundary is where you focus STRIDE analysis. You don't need a formal tool: a whiteboard or Miro board is fine. What matters is that everyone in the room agrees on what the system does and where the boundaries are. Half the value of threat modeling is exposing that engineers, PMs, and security had different mental models of the same feature.

Running the workshop

Cast: the feature's tech lead, one security-minded engineer, the PM, optionally an outside reviewer. Time: 60-90 minutes for a moderately complex feature. Preparation: tech lead sends a design doc 48 hours ahead. Agenda: (1) 10 min — tech lead walks through the design and DFD; (2) 40 min — group runs STRIDE against each trust boundary, capturing threats in a shared doc; (3) 20 min — triage each threat as Mitigate/Accept/Transfer/Investigate with an owner and rough due date; (4) 10 min — retro and document decisions. Ship the doc as an ADR in the repo so future engineers understand why the design looks the way it does.

Turning threats into work

A threat model that doesn't produce follow-up work is theater. Each Mitigate item becomes a ticket in your normal tracker, linked back to the threat model doc. Accepted risks are logged with a stated rationale and a review date — 'we accept that unauthenticated webhook receivers can be flooded; will revisit if we cross 100K events/day.' Investigate items get a 1-week spike. Track a lightweight metric: percentage of new features with a threat model on file. Aim for 100% of features touching the criteria in section one; don't force it elsewhere.

Frequently asked questions

Do we need a dedicated security engineer to run this?: No. Any senior engineer with a checklist and 90 minutes can run a competent threat model. Bring in outside expertise (consultant, security engineer at a friend's company) for the first two or three sessions to calibrate; then it becomes muscle memory.
How is this different from a pentest?: Pentests find implementation bugs in shipped code ('this endpoint has SQL injection'). Threat models find design flaws in unshipped systems ('this endpoint shouldn't exist without an authz check because there is no way to enforce it later'). You need both. Threat modeling is 10x cheaper because refactoring a diagram takes minutes and refactoring production code takes weeks.
What if the team resists?: Start with a real incident — yours or a public one (LastPass, Okta, MOVEit). Walk through it as if you were threat-modeling the pre-incident design. Engineers who see how a 90-minute meeting would have caught it become believers quickly.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database