This trace follows the actual state transitions behind the companion Threat Modeling Starts With Assets and Boundaries. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Name the asset and actor
Threat modeling is a structured way to ask how a system could be misused or attacked. Begin with assets worth protecting, actors, data flows, and trust boundaries. A boundary marks where assumptions change, such as browser to server, service to database, or tenant to tenant.
Step 2: Draw the data flow
A diagram of a file upload can show the browser, API, object store, and image-processing worker. Each crossing raises specific questions: who authenticates the request, how type and size are checked, whether the object name is attacker-controlled, and what privileges the worker receives.
Step 3: Mark a trust boundary
At each boundary, ask who controls the incoming value and which authority is available; derive a concrete misuse case rather than relying on a generic threat list.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Identify a misuse path
A threat list without mitigations or owners becomes paperwork. Threats depend on the system’s actual deployment and adversaries; generic checklists may miss a risky data flow. Revisit the model when architecture, external exposure, or sensitive data changes.
Step 5: Assign a control and test
Draw the trust boundaries for a password-reset flow and identify one abuse case at each boundary, including the email provider callback.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.