Why architecture matters here
The economic argument is the strongest one: vulnerability cost scales with discovery lateness. A missing authorization check caught in design review is a sentence in a document; caught in code review, a changed PR; caught by pentest, a remediation project competing with the roadmap; caught by an attacker, an incident with regulatory and reputational interest. Threat modeling is the only security activity positioned at the cheapest point — and it catches a class of flaw the later stages structurally miss: design vulnerabilities. Scanners find the SQL injection; nothing downstream finds 'the internal admin API trusts any caller inside the VPC' or 'password reset tokens don't expire' — architecture decisions that are perfectly implemented and fundamentally wrong. The pentest might stumble onto them; the threat model interrogates them systematically.
The method's core insight is that threats live at trust boundaries. Drawing the data-flow diagram is not documentation busywork — it forces the questions that matter: where does untrusted input enter? which components run at different privilege levels? what crosses from the browser (hostile territory) to the API (defended), from the API to the payment processor (third party), from the pipeline to the model (a new boundary the LLM era added)? Every crossing is a place where assumptions about the other side become attack surface, and STRIDE-per-boundary is a checklist that converts 'think like an attacker' — advice nobody can follow on command — into a mechanical elicitation any engineer can run.
The organizational value is subtler and larger: threat modeling is how security scales past the security team. A ten-person security org cannot review three hundred engineers' designs; it can teach the four-question habit, provide the templates and boundary checklists, and reserve its experts for the sessions where the model surfaces something novel. The residual-risk contract completes the system: risks nobody chose to mitigate are written down, owned, and revisited — turning the silent risk acceptance every organization does anyway into an explicit, auditable decision with a name attached.
The architecture: every piece explained
Top row: model and elicit. The system model is a data-flow diagram at the altitude of trust: external entities (users, partners, attackers' entry points), processes, data stores, and flows — with trust boundaries drawn wherever privilege, ownership, or trust level changes (internet→edge, service→database, org→vendor, user content→LLM context). Assets and actors anchor relevance: what is worth stealing/breaking (credentials, PII, money movement, model weights), and who plausibly tries (opportunists, insiders, targeted attackers) — the difference between modeling a marketing site and a payment switch is written here. STRIDE runs per element: for each flow/store/process, walk the six categories — spoofing at every identity claim, tampering on every mutable flow, repudiation where actions need attribution, disclosure at every store and log, DoS at every resource, elevation wherever privilege is decided. Attack trees complement the checklist with goal-driven thinking: root = attacker goal ('exfiltrate the customer table'), children = alternative paths (compromise an app credential; SQL-inject a reporting endpoint; social-engineer a DBA; poison a backup restore), leaves = concrete steps ranked by feasibility — the structure that finds the paths STRIDE's per-element sweep can miss.
Middle row: decide and close. Risk ranking keeps the output actionable: likelihood × impact (calibrated buckets beat false-precision scores), yielding a short list that survives contact with sprint planning. Mitigations map controls to threats explicitly — authn scheme vs spoofing, integrity checks vs tampering, audit trails vs repudiation, encryption/access control vs disclosure, rate limits vs DoS, privilege separation vs elevation — with each control's verification method named (the unit test, the config assertion, the pentest scenario). Residual risk is the honest ledger: threats acknowledged and not mitigated (cost, likelihood, compensating controls), accepted by a named owner with a review date — the artifact auditors and future engineers thank you for. Validation closes the loop: mitigations become security test cases (the authorization matrix as an automated suite), and the threat model becomes the pentest's scoping document — pointing expensive human attackers at the boundaries the model says matter most.
Bottom rows: making it live. The lightweight cadence scales the practice: every design doc answers three embedded questions (new trust boundaries? new data classifications? new external dependencies?); 'yes' escalates to a one-hour session with the template; only genuinely novel surfaces get the full workshop. The living artifact discipline: models live next to the architecture docs they describe, diffed when the architecture diffs — a new queue, a new vendor, a new AI feature each trigger a boundary review. The ops strip: a registry of models with owners and review dates, control-verification status tracked (which mitigations have tests, which are promises), and drift review — the quarterly check that the diagram still resembles the deployment.
End-to-end flow
Model a real feature: adding an AI support assistant to a SaaS product — the kind of addition that sails through review without threat modeling and generates incidents for a year after. The one-hour session, template-driven. What are we building? The DFD sprouts new elements: user chat → orchestrator → LLM provider (new external dependency), orchestrator → internal APIs (order lookup, account data) via tools, knowledge-base documents → context. Four new trust boundaries get drawn, and one gets circled in red: user content and retrieved documents flow into the same context that steers tool execution — untrusted data adjacent to privileged capability.
What can go wrong? STRIDE on the circled boundary yields the modern classics: elevation via prompt injection (user text convincing the agent to call tools beyond intent), disclosure via exfiltration (injected instructions steering retrieved-PII into responses or outbound requests), tampering via poisoned KB documents (indirect injection), DoS via token-burning loops, repudiation gaps ('the AI did it' — whose action was that?). The attack tree for 'read another customer's data' finds the non-obvious path the checklist alone might miss: the order-lookup tool takes an order ID and checks nothing else — cross-tenant access one confused deputy away.
What are we doing about it? Ranked mitigations, each with its verification: tool-level authorization binding every lookup to the session's authenticated tenant (unit-tested with an adversarial suite — the cross-tenant case becomes a permanent regression test); tool gates and budgets per the agent-guardrail playbook (verified by injection-corpus evals in CI); KB ingestion sanitization (verified by seeded poison documents); provider data-handling reviewed against the data classification (contractual control — tracked, not tested). Residual risk ledger: sophisticated multi-turn injection may evade screens — accepted by the product owner with compensating controls (output filtering, audit logging, per-session budget caps) and a six-month review date tied to the eval corpus's growth. Did we do it? The pentest scope for the quarter points squarely at the circled boundary; the pentesters, armed with the model, spend their days on the paths that matter — and their one finding (a tool-error message leaking internal hostnames) lands as a model update plus a control, not a surprise. A year later, the registry shows the model diffed four times as the feature grew — memory, file upload, A2A federation — each addition a boundary review, none an incident. The counterfactual — this feature shipped on vibes — is the case study in someone else's postmortem.