Most threat modeling advice is written for companies with a security team. If you are six engineers shipping a product, that advice reads as a list of reasons not to start.
STRIDE per data flow diagram element. Trust boundary enumeration. A DFD maintained as the architecture changes. Attack trees. It is all legitimate, and none of it survives contact with a team where the person who would run it is also on call this week.
So teams do the honest thing and skip it, and then the security questionnaire from a prospect asks "do you perform threat modeling?" and someone writes yes and hopes.
There is a version that fits in one hour and produces something real. I have run it with teams of four and teams of forty. Here it is.
The setup
One hour. One feature or service, not the whole system. Three people: whoever owns the code, whoever owns the infrastructure it runs on, and one person who did not build it. That third person is the important one and the one teams skip.
A whiteboard or a shared document. No tooling.
Step one: draw it, badly (10 minutes)
Boxes and arrows. What talks to what. Where does data enter the system, where does it rest, where does it leave.
Do not make it pretty and do not make it complete. The purpose of the diagram is to give six eyes the same mental model for the next fifty minutes, not to be an artifact you maintain. If it is wrong, someone will say so, and that correction is itself worth the ten minutes.
Mark three things on it:
- Every point where data crosses from something you control to something you do not
- Every point where a user-supplied value influences what the code does
- Every place credentials or tokens live
That is your trust boundary map. You did not have to know the term to draw it.
Step two: four questions (35 minutes)
This is Adam Shostack's framing and it is the most useful thing in the field. Ask, in order:
What are we working on? You just drew it. Say it out loud in two sentences. If you cannot, the diagram is wrong.
What can go wrong? This is the whole exercise. Go around the diagram element by element. For each one, ask what an attacker who reached this point could do. Not "is this secure." What could they do.
The prompts that consistently produce real findings in small teams:
- What happens if this identifier is changed to another tenant's identifier?
- What does this component do if the thing it calls returns garbage, or nothing, or takes forever?
- Who can read this log, and what is in it?
- If this credential leaked today, what is the blast radius and how would we know?
- What does this endpoint do before it checks authorization?
That last one finds more real problems than any other single question I have used.
Write every answer down, including the ones you immediately dismiss. Dismissing something out loud with two colleagues present is a different act from never having considered it.
What are we going to do about it? Sort the list into three buckets. Fix now, accept and document, needs more thought. Be ruthless about the middle bucket. Accepting a risk deliberately is a valid engineering decision. Accepting it by forgetting is not.
Did we do a good job? Five minutes at the end. Did we cover the diagram. Did anyone hold back a concern. What would we do differently next time.
Step three: the artifact (15 minutes)
One page. Date, participants, the diagram photographed or pasted, the findings table with three columns: what could go wrong, decision, owner.
That page is the deliverable. It is what you point at when a prospect asks whether you threat model, and it is what a SOC 2 or ISO 27001 auditor will accept as evidence of secure design practice, which is a control most small teams have nothing for.
Do it once per meaningful new service or major architectural change. Not per sprint, not per PR. Perhaps four to six times a year for a team your size.
What this deliberately gives up
It is worth being honest about the trade.
You will not get systematic coverage. Structured STRIDE catches categories of issue that ad hoc questioning misses, particularly repudiation and elevation-of-privilege classes that do not occur to people naturally.
You will not build a maintained model. The diagram is disposable, so the next session starts from scratch.
You will be biased toward what the room already worries about. The outsider in step one is the partial mitigation, and it is partial.
What you get in exchange is that it happens. A threat model that gets run four times a year and finds three real issues beats a rigorous methodology that gets deferred for eighteen months. I would rather argue about the coverage gaps of something that exists.
The finding pattern
Across small-team sessions, the same three categories dominate:
Authorization checked after the expensive thing. The endpoint fetches, computes, then checks whether you were allowed. Timing and error-message differences leak existence of other tenants' objects.
Trust in an internal service that is not internal. Something on the private network is reachable from somewhere it should not be, usually via a path added months after the original design.
Secrets with no rotation story. Not leaked secrets. Secrets where nobody can answer what the recovery procedure would be, which means there is not one.
None of these require a specialist to find. They require an hour and someone asking the second question.
I run the vCISO practice at IRM Consulting & Advisory in Toronto, working with SaaS and scaling teams on exactly this problem: security practices proportionate to the size of the team actually doing them. Our threat modeling approach for small engineering teams is written up at https://irmcon.ca/threat-modeling-tm/
If the constraint is that nobody owns this work rather than that nobody knows how to do it, that is the gap fractional security leadership is meant to fill. Detail here: https://irmcon.ca/virtual-ciso-services-vciso/
Curious what the third category is for other people. If you have run a session like this, what kept coming up that is not on my list?
Top comments (1)
"The third person is the important one and the one teams skip" is the truest sentence written about this exercise. The outsider finds the findings not because they're sharper but because they don't have the mental model that fills the gaps for the people who built it.
Genuine question on step two: when you run this with teams of four to six, how do you handle the prioritization after "what can go wrong"? Our failure mode was a list of thirty findings where the team had capacity for two — do you cap the list during the hour to force ranking, or is triage out of scope?
The secrets-with-no-rotation-story point is also the one I'd add to every questionnaire response review: that finding is almost never new, the session just makes someone say it out loud with witnesses.