A team is about to build a new payment feature. When and how should threat modeling happen?
Short answer
Threat modeling is cheapest and most effective at design time, before code locks in decisions: walk the data flows, enumerate threats with a framework like STRIDE, and bake in mitigations, then revisit as the design evolves. Doing it only post-incident or at the annual pentest finds problems after they are expensive to fix and already exposed. And relying on 'careful developers' is a hope, not a repeatable, auditable control.
A payment feature handles money and sensitive data — exactly the kind of system where design-stage security thinking pays off most. The question tests whether the candidate understands when security work is cheap and effective versus when it is expensive and reactive.
Why design-time threat modeling wins
Threat modeling is a structured way to ask, before you build: what can go wrong, and what will we do about it? At design time the architecture is still fluid — you can change a trust boundary, add a control, or drop a risky dependency for the cost of editing a diagram, not refactoring shipped code.
A practical flow:
- Diagram the data flows for the payment feature and mark trust boundaries (browser → API → payment processor → database).
- Enumerate threats with a framework like STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — at each boundary.
- Define mitigations (authn/authz, input validation, idempotency keys, tokenization, logging) and track them as requirements.
- Revisit whenever the design changes — it is a living activity, not a one-off.
Why the wrong answers are wrong
"After launch, only if there's an incident" is the most expensive possible timing: you pay in breaches, customer harm, and emergency rework. "Only during the annual pentest" finds issues late, narrowly, and after they have shipped — a pentest validates a design, it does not substitute for designing securely. "Unnecessary if developers are careful" mistakes individual diligence for a process; care is not repeatable, auditable, or resilient to turnover, and it gives no systematic coverage of threat categories.
What an interviewer is probing
They want shift-left instinct: security reasoning embedded in design, a named methodology, concrete trust boundaries and mitigations, and the maturity to treat the threat model as a living artifact that evolves with the system — not a checkbox at the end.
Likely follow-ups
- Walk me through STRIDE applied to a payment flow — give one threat per category.
- What artifacts (data-flow diagram, trust boundaries) do you need before you can threat model?
- How do you keep a threat model alive instead of a one-time document that rots?