Yes. A small team can threat model one feature in about 30 minutes by asking four questions at a whiteboard: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Keep the scope to one feature and write down the answers.
What threat modeling means
Threat modeling is analyzing a representation of a system to find security and privacy concerns. The Threat Modeling Manifesto frames it as those four questions, and says it should be done early and often, in iterations scoped to manageable portions of the system. It is methodology agnostic, so you do not need a special tool or a named method to start.
For a small team, that means a drawing and a conversation, not a 40 page document.
Who should be in the room
The person building the feature, one more engineer who did not design it, and whoever knows the data best. Three people is plenty. The manifesto's values favor people and collaboration over processes and tools, and a small group makes that easy.
The 30 minute routine
- Draw it (8 minutes). Sketch the feature on a whiteboard: the user, the browser or app, your services, the database, and any third party. Mark where data crosses from one trust level to another, such as from the internet into your API.
- List what can go wrong (10 minutes). Walk each arrow and box and ask: what if this input is hostile, this account is stolen, this service is down, this dependency is malicious? Write short phrases, not essays.
- Decide what to do (7 minutes). For each item pick one of four moves: fix it in the design, add a test or check, accept it on purpose, or hand it to someone else such as a vendor.
- Check yourselves (5 minutes). Ask whether the list covers the data that matters most, and whether each fix has an owner.
What to produce
A photo of the whiteboard and a short list in the ticket or the design doc: threat, decision, owner. Link it from the pull request. That is the whole artifact.
| Prompt | Example question |
|---|---|
| Who can call this? | Can an unauthenticated user reach this endpoint? |
| What do they send? | Is any field used in a query, a path or a command? |
| What do we store? | Does this save personal data or credentials? |
| What do we trust? | Do we call a package or API we did not write? |
| What if it fails? | Does an error leak internals or open a door? |
When to do it
Do it when a feature touches authentication, money, personal data, file upload, or a new third party. Skip it for a copy change. A small team that models three or four risky features a quarter will learn more than one that plans a huge annual session.
Common traps
Trying to cover the whole product in one sitting. Making it a compliance ritual. Listing threats without decisions. Letting the loudest person decide. Remember the manifesto's point that doing threat modeling beats talking about it.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Do we need a diagram tool?
No. A whiteboard or paper works. Take a photo and attach it to the ticket.
Is this the same as a penetration test?
No. Threat modeling happens before or during design and finds design flaws. A penetration test attacks a built system.
Sources
Last reviewed: 19 October 2026.
