How do you run a one-hour rapid threat model on a feature that ships Friday?
answer
- Cheap enough that it actually happens
- Scope down before you speed up
- Same written prompts every session
- Capture threats, do not solve them
- Coverage is what the clock costs
basics
~20 sFix the scope to the change itself, sketch its flows and trust boundaries, walk one fixed question set over every boundary crossing, and leave with ranked threats that each have an owner. You buy the obvious high-impact threats and spend completeness.
solid answer
~50 sI treat the hour as triage, not a study. Roughly ten minutes to draw only the change and what it talks to, ten to mark where data crosses a trust boundary, thirty to walk a fixed question set over each crossing, ten to rank and assign. The set is fixed so the room does not free-associate: who can reach this and what do they already hold, what crosses this line and who validated it, what here is worth stealing or turning off, what happens if this component lies to the next one, and what would we never see. Take the feature-flag admin console built at a hackathon: once someone says it can dark-launch a payments path, the dominant threat is any engineer inside the VPN flipping production configuration, not an anonymous internet attacker. The output is a ranked list with owners, plus a written statement of what the hour never looked at.
go deeper
Be ready to say what a rapid model produces: a short ranked list of threats, each with an owner, not a report. Know that the scope is the change being shipped, not the whole platform.
Expect to walk the hour minute by minute - what you draw, which prompts you ask at each boundary crossing, and how you keep the room capturing threats instead of designing fixes.
Show that you state the residual out loud: which parts the hour never touched, and what would trigger a deeper session. Attaching owners and dates before the room empties is the part interviewers watch for.
Own the argument that a model teams will actually run beats a thorough one they skip, and be able to name the conditions under which one hour is not an acceptable answer for a given system.
## What a rapid model actually is A rapid threat model (often run as a "one-hour threat model" or a rapid risk assessment) is not a compressed full model. It is a different product with a different promise: it finds the threats that are *obvious once someone asks*, on a design that is still cheap to change, in a slot short enough that a team under deadline will actually book it. The alternative in the real world is almost never a thorough model - it is no model at all, because the thorough one never got scheduled. The economics are the whole argument. A model that costs an hour and finds the three threats that would have shipped is worth more than a model that costs three days, finds eleven, and happens after the feature is live. ## An hour that works A workable shape, roughly: ``` 0-10 min Draw only the change: the new component, what it talks to, where its data comes from and goes. 10-20 min Mark trust boundaries - every place data or a request moves between things that trust each other differently. 20-50 min Walk the fixed question set at each crossing. Capture, do not debate. 50-60 min Rank, assign an owner and a next step, state the residual. ``` Two mechanics matter more than the clock. First, **capture without solving**: the fastest way to lose the hour is to start redesigning the first threat someone raises. Write it down, name an owner, move on. Second, **a fixed question set**. Free association scales with whoever is loudest in the room; a written list of prompts is repeatable and produces comparable output across teams. A serviceable set: - Who can reach this, from where, and what do they already legitimately hold? - What crosses this boundary, and who validated it on the far side? - What here is worth stealing, worth changing, or worth turning off? - What happens if this component lies to the one next to it? - What would we never see if it happened? - What can this thing do that it does not need to do? ## Worked example An internal feature-flag admin console, built at a hackathon, shipping Friday. The team's instinct is that it is internal, therefore low risk. The hour changes that in two prompts. *Who can reach this?* Any engineer on the VPN, plus anything running as a service account with the console's credentials. *What is worth changing?* The flag values themselves - and one of them dark-launches a payments path. The asset is not customer data at all; it is the integrity of production configuration and the availability of the payment flow. The dominant threats become an insider or a stolen internal session flipping a flag, and a flag change with no record of who made it - a non-repudiation gap that turns a bad Friday into an unanswerable one. Mitigations that fit the deadline: two-person approval on the flags tagged payments, an append-only change log, and a kill switch that reverts to the last known state. Notice what the hour never touched: the console's dependency tree, its build pipeline, its session handling, the flag evaluation SDK inside every service. That is not failure - it is the thing you must write down. ## What the hour trades away - **Coverage.** Entire subsystems go unexamined. The model says nothing about them, and "nothing said" must never be read as "looked at and cleared." - **Depth of chains.** Rapid models find single-step threats. Multi-step chains - a low-severity information leak that makes a second threat trivial - need the time you did not spend. - **Rigor of rating.** You will rank by rough judgment in the room, not by a defended scoring exercise. - **Durability.** The artifact is a list, not a maintained model. It is accurate for the design as of Friday and starts decaying immediately. ## Making the trade honest The difference between a useful rapid model and security theatre is one paragraph: the **residual statement**. Record what was in scope, what was explicitly out, and what would trigger a deeper session - a new trust boundary, a change from internal to internet-facing, money or personal data entering a path that did not have it. That paragraph is what lets a reviewer six months later tell an unexamined area from a cleared one, and it is what a senior interviewer is listening for.
- What do you record about the parts of the system the hour never touched?An explicit residual statement: what was in scope, what was deliberately out, and what would trigger a deeper session later. Without it, the next reader cannot tell an area that was examined and cleared from one nobody opened. I keep it in the same artifact as the threat list, not in a separate document, because separated caveats get lost.
- A colleague calls a one-hour threat model security theatre. How do you answer?Theatre is a model that produces a document nobody acts on. This produces a ranked list with owners and dates, and it says out loud what it did not cover. The honest comparison is not against a three-day model - it is against the model this team would otherwise never run. If the hour is wrong for a system, the answer is to trigger a deeper session, not to skip modeling.
- How do you stop the hour from turning into a design review?Separate capture from solving. When a threat surfaces, the room records it, names an owner and moves on; the fix is designed afterwards by that owner. I also refuse scope creep in the moment - if someone raises a threat in an adjacent system, it goes on the residual list rather than into the hour.
A rapid threat model is triage, not diagnosis. You sort by what could kill the patient in the next hour, you write down who you did not have time to examine, and nobody pretends triage was a full workup.
saying these in an interview costs you the question
- Claims a one-hour model is as complete as a full one
- Spends most of the hour perfecting the diagram
- Free-associates threats instead of using a fixed prompt list
- Leaves with findings but no owners or next steps
- Models the whole platform instead of the change shipping
- Treats unexamined areas as verified safe