What can an automated threat-model generator's output be trusted to deliver, and where does it stop?

## The claim to get right Automation in threat modeling operates on the **model**, not on the system. A generator reads the elements you drew or declared — processes, data stores, data flows, external entities, trust boundaries — and emits threats by rule. Everything it says is therefore true *of the model*. Whether the model resembles the thing you are about to build is outside its reach, and that gap is the whole subject of this question. It helps to separate four things that interviews routinely blur. A **threat** is what could go wrong (an attacker replaces the settlement file in transit). A **vulnerability** is the flaw that would let it happen (the transfer accepts any certificate). A **risk** is the rated consequence of that pairing for this business. A **control** is what you do about it. Generators are strong on the first, weak on the second, essentially blind on the third, and can only suggest generic instances of the fourth. ## What automation genuinely earns **1. A checklist floor.** The value of per-element rule application is completeness of the boring kind. A human reviewing thirty elements gets tired around element nine and stops asking the same six questions of each. A generator asks them of all thirty, identically, every time the model changes. Nothing brilliant comes out — but the embarrassing omission (a flow nobody considered tampering with) does not survive. **2. Structural checks.** This is the strongest automation win and the one candidates undersell. Some defects are properties of the diagram itself and need no judgment at all: a data store sitting inside no trust boundary; a flow that crosses a boundary with no authentication or integrity property stated; an external entity connected straight to a store with no process between them; an element with no data classification. On a rail revenue-settlement model, a check of exactly this kind catching a settlement store drawn with no boundary around it is worth more than fifty generated threat sentences, because it tells you the *model* is unfinished — and an unfinished model makes every downstream threat unreliable. **3. Bookkeeping.** Formatting surviving items into tickets, carrying identifiers so the same threat is recognisable across revisions, and showing what changed between two versions of the model. This is clerical work and machines are better at it than people. ## What stays human **False assumptions.** A generator treats every label as fact. 'Private network', 'internal only', 'trusted partner', 'encrypted at rest' are inputs, not findings. If the assumption is wrong, the output is confidently wrong in the same direction, and no amount of rule coverage detects it. **Business impact.** This is the sharpest limit. Rules know element types; they do not know what your company sells. In a hotel-booking model the engine can tell you an unauthenticated feed can be read by anyone — it cannot tell you that this particular feed is live rate-and-availability data that competitors would pay for, which makes an 'expected, by-design' public endpoint the most commercially sensitive thing on the page. Information disclosure of a marketing image and information disclosure of pricing IP are the same category and wildly different risks. Only a person who knows the business closes that gap. **Omission.** A generator cannot flag a component you never drew, a flow you forgot, or a threat category no rule encodes. Silence means 'no rule fired', never 'nothing is there'. **Deciding it is good enough.** Shostack's fourth question — did we do a good enough job? — is a judgment about coverage and residual risk. No rule set answers it. ## How to say this in an interview Frame it as division of labour rather than tool-bashing. Automation removes the excuse for missing the obvious and standardises the mechanical pass; humans supply ground truth about the design, the value of the assets, and the decision about what to do. A team that runs the generator and skips the walk-through has automated the cheap half and dropped the expensive half. A team that refuses the generator is paying senior time to do proofreading. A practical formulation: **let the tool fail the model, let humans rate the system.** Structural gaps and unapplied rules should block the review as unfinished work; the resulting threat list is raw material for a human pass that adds assumptions, impact and the two or three threats that only someone who knows the product could name.