How do you scope a threat model to a new caseload-export feature on a twelve-year-old case-management monolith?

### Why change-scoped modeling exists Most real threat modeling is not done on a greenfield architecture. It is done on a change to a system that already exists, is large, is old, and was never modeled. If the only accepted scope were `the whole system`, no model would ever be produced, because the first session would drown in a decade of accumulated design. Change-scoped modeling is the answer: bound the exercise to what is being built now, and be precise about how far outward that bound reaches. ### The delta and its blast radius The scope of a change model has two parts. **The delta** is what is genuinely new: new code paths, new data flows, new stored or transmitted data, new places data comes to rest. For a caseload export that is a bulk query over case records, a file-generation step, and a delivery path - a download response, an object store, or an email attachment. **The blast radius** is everything outside the delta whose behaviour the delta depends on for a security property, or whose assumptions the delta changes. This is the part inexperienced modelers skip, and it is where the real findings live. For the export it typically includes: the authorization check that decides who may invoke the export at all; the data-access layer's row-level filter, if there is one, and whether the export path goes through it or around it; the audit log, which now must record a bulk read rather than a single-record view; and session and URL handling for the produced file, which may leave the authenticated boundary entirely if the download is served from a signed or guessable link. A useful phrasing for the room: *in scope is the change and anything the change makes a promise about.* ### Behavioural widening with no structural change The most valuable thing this bound catches is a change in risk with no change in shape. Suppose the export reuses an existing report screen and adds no new endpoint. Structurally nothing was added, so a naive scope says there is nothing to model. But the control environment has moved: a district filter that is fine when a caseworker opens one child's record is a catastrophic single point of failure when the same identity can emit the entire national caseload as a spreadsheet in one action. Rate limiting that made no sense per record now matters. Detection that never fired on a page view now needs a signal for bulk extraction. Aggregation converts a low-impact authorization gap into a mass-exfiltration path, and the only way to see it is to put the reused control inside the boundary explicitly and ask what it now promises. The attacker position that drives all of this is not an anonymous internet user. It is an authenticated caseworker with a legitimate account, pulling records for districts that are not theirs - a person the perimeter will never stop and whose actions look like work. The asset is highly sensitive personal data about vulnerable people, where a single successful bulk read is unrecoverable. ### Where the line closes Three stop rules keep a change model finishing: 1. **Untouched code with pre-existing weaknesses is out.** If a legacy module has a known problem the export does not touch, record it, hand it to whoever owns the backlog, and do not expand this session into it. A change model is not an audit. 2. **A dependency comes in only when the change relies on its behaviour.** If the export reuses a legacy query builder, that builder is now inside the line because the export's safety depends on how it composes filters. If it merely runs on the same server, it is not. 3. **The exclusion list ships with the model.** The legacy login flow, the billing module, the batch reporting jobs: named, with one line each, and with a re-entry condition. A future change that touches them will find that note. ### What the deliverable looks like A good change model here is small and specific: a paragraph naming the change and its boundary, a handful of threats concentrated on authorization scope, aggregation, file lifetime and audit coverage, mitigations attached to each, and an exclusion list. It fits in one session because the boundary was made narrow on purpose - and because it was narrow, the findings are actionable rather than a generic list of everything that could ever be wrong with an aged monolith. ### The failure modes Insisting on modeling the whole monolith first guarantees the feature ships unmodeled. Scoping only the literal new lines of code misses every reused-control finding, which is where the aggregation risk hides. Treating `no new endpoint` as `no new risk` misses behavioural widening entirely. And letting the session sprawl into every legacy flaw someone remembers produces a document that lands after the release.