Outputs and Non-Goals

### Why the outputs are the whole point A threat modeling session is an analysis of a design, done before or alongside the build. Its value is realised only if something downstream changes because of it. So the useful way to judge a session is not "did we talk about attacks for ninety minutes" but "what did we hand back, and who is going to do something with it". A model whose output is a document filed by the security team has produced nothing. ### The four artifacts **1. Findings, each with a named owner.** A finding is a concrete statement of something that could go wrong with the design as proposed, written specifically enough that a reader who was not in the room can act on it. The part teams skip is the name. "The team should look at the duty-rate override path" is a wish; "Ana owns the override path finding" is work. Ownership at the moment the finding is written is what separates outputs from minutes. **2. Security requirements.** Not everything a model produces is a defect. Much of it is a constraint on something that has not been built yet, and it belongs in the description of the work: "a duty-rate override must be rejected unless the principal holds the customs-supervisor role, and every attempt must be recorded whether it succeeds or fails". A finding says something is wrong now; a requirement says what must be true when the feature is done. Confusing the two is why models aimed at unbuilt features feel like they produce nothing. **3. Abuse test cases.** During the session the group has spent an hour thinking about what an attacker would try, which is exactly the raw material testers rarely have. Capture it as things someone should deliberately attempt — submit a declaration for a consignee the broker does not represent, replay a filed declaration with a lower duty rate, correct a declaration after the filing window closed. Turning those into acceptance criteria and automated negative tests is a separate downstream step; the model's job is to write down the attempts while the reasoning is fresh. **4. The corrected diagram.** The picture the team brings to the session is always wrong somewhere: a queue nobody drew, a batch job that reaches straight into the database, an assumption that a call is internal when it crosses a network the team does not control. The diagram that leaves the room is different from the one that entered, and that corrected shared picture is frequently the longest-lived artifact of all — teams still use it long after the findings have been closed or forgotten. ### Vocabulary that keeps the outputs honest - A **threat** is what could go wrong: an attacker in some position doing something to an asset. - A **vulnerability** is the specific flaw that would let it happen. - A **risk** is the rated consequence of that happening. - A **control** is what you do about it. A threat model deals mainly in threats and controls. It may hypothesise vulnerabilities, but it does not confirm them; it may motivate a rating, but rating is a separate step with its own method. ### What is not an output - **A verdict.** "The design passed threat modeling" is not a thing. There is no pass state, because the exercise is not a test. - **A confirmed vulnerability list.** Sponsors ask for this constantly. On a freight-forwarding customs-declaration service, a model might hand back exactly three findings, two security requirements, one abuse case and a redrawn diagram, while the sponsor keeps asking where the vulnerability list is. The honest answer is that the model reasons about a design, not about a running build, and the list they want comes from testing that build. - **An assurance statement**, and **an organisation-level risk register**. Individual threats may feed those instruments, but the model is neither of them. ### How outputs decay, and what that tells you A genomics research data-sharing platform ran a serious session and wrote the results as prose: paragraphs describing how a partner institution could reach further into the platform than intended. Six months later the only artifact anyone still used was the corrected data-flow diagram. The prose had no owners, so nothing pulled it into anyone's week. The diagram survived because it was directly useful to whoever opened it next. That asymmetry is a good diagnostic: if the diagram is outliving your findings, your findings were not written as work. ### A practical closing habit End the session by reading the artifacts back aloud: this many findings and who holds each, these requirements and which story they enter, these abuse cases, and the diagram as corrected. If any category is empty, say so deliberately — an empty list is a legitimate result, an unnoticed one is not.