When does a deployment diagram reveal a threat that a component diagram cannot?

## Two views, two different questions A **component diagram** answers: how is this system decomposed, and which part depends on which? A **deployment diagram** answers: what actually runs, where, as what identity, with what mounted next to it, reachable by whom? Threat modelling needs both, because a trust boundary is a claim about the second question that people habitually justify with the first. The rule worth stating out loud in an interview: **a trust boundary is only real if something enforces it.** A line on a diagram between two components is a hypothesis. The enforcement mechanism is a separate process, a separate host or tenant, a distinct workload identity, a separately scoped secret, or a network path that is actually mediated. If none of those exists, the boundary is decorative and every threat you dismissed as being blocked by it is live again. ## A worked case The component diagram shows two services: a public-facing content service and an internal billing service, with a gateway drawn between them and a trust boundary on that line. The deployment diagram, drawn honestly, shows something else: both are packaged into one process on one VM, started as one unit, with one credentials file mounted at a fixed path and one outbound identity used for all downstream calls. Requests between them are in-process calls, not network calls. Enumerate against the deployment view and four things fall out that the component view hid. 1. **No process boundary.** A compromised third-party dependency pulled into the content service executes in the same address space as the billing code. Anything the billing service can read, the attacker can read, including secrets already loaded into memory. 2. **Shared credentials.** One credentials file means the compromise of the least valuable component yields the rights of the most valuable one. The adversary here is a compromised dependency, not an anonymous internet attacker, and the asset is credentials and keys, which are then a step to everything those keys open. 3. **The mediated path is not on the path.** The gateway you drew, and any authentication or rate limiting it applies, is bypassed entirely, because the call never leaves the process. The control exists but sits beside the real data flow. 4. **Shared fate for availability and forensics.** One crash takes both down, one log stream mixes both, and an incident in either forces you to treat the whole host as compromised. ## What to do with the finding You have exactly two honest moves, and picking one is the judgment being assessed. - **Move the boundary on the model to match reality.** Erase the line, redraw the two components as one trust domain, and re-run the enumeration. Threats you previously marked mitigated by the boundary come back and need real answers. This is the right call when the co-location is deliberate and the blast radius is acceptable. - **Change the deployment to match the model.** Separate processes at minimum, distinct workload identities, per-component secrets scoped to what each actually needs, and a call path that traverses the mediation you drew. This is the right call when the model's boundary was load-bearing for a high-value asset. What is not acceptable is leaving a model that claims a boundary the runtime does not provide, because every later reader inherits that false assurance. ## What a deployment view needs to carry Deployment views rot faster than any other diagram, so capture only the properties that change threat conclusions: the execution unit boundaries (what shares a process, a host, a tenant), the identity each unit runs as, the scope of each secret it can read, the storage it can reach, and who can reach it on the network. A full inventory of hostnames and versions is a different artifact with a different owner and it will be stale within a sprint. The same view also routinely surfaces two other blind spots: the same credential reused across environments, so a compromise in a lower environment reaches production data; and copies of a store that the logical view drew once, backups, read replicas and analytics exports, each of which needs its own boundary and its own protection. ## The related failure in the other direction Beware of treating every box on a component diagram as a trust boundary. Separate repositories, separate teams and separate deployment pipelines are organisational facts, not runtime isolation. The reverse mistake, drawing no boundary because two components are internal, is just as bad: internal is not a security property, it is a network location.