Interview prompt
Explain threat modeling starts with assets and boundaries to an engineer who understands the surrounding system but has not used this technique. Walk from its contract to a concrete operation, then discuss where it fails or becomes expensive.
A strong answer
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.
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.
A complete answer also calls out the assumptions that control correctness. 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.
Close by describing one representative test or measurement. Draw the trust boundaries for a password-reset flow and identify one abuse case at each boundary, including the email provider callback.
Follow-up questions
Answer the follow-ups in the frontmatter. Use the linked article for the concept and the trace to make the explanation concrete.