Why require the threat-model diagram update in the same pull request as the code change?
answer
- catch drift when it is created
- the model diff sits beside the code diff
- history equals commit history
- narrow coverage, high frequency
- an edit is not an analysis
basics
~20 sIt turns drift into a review-time question. The reviewer sees the model diff next to the code diff and can refuse a change whose new flow, store or boundary is missing, instead of discovering the gap at the next audit.
solid answer
~50 sKeeping the model in the repo next to the code means its history is the commit history, and requiring the update in the same pull request means someone looks at the model at the exact moment the architecture changes. On a telco number-porting service, a pull request adding a queue consumer is where a reviewer can ask the one useful question: does this add a flow across a boundary, a new store, or a new data class? If the diagram diff is empty, that is either a fair answer or a caught omission - and either way it took thirty seconds rather than a quarterly reconciliation. Two limits keep me honest. It only catches change that flows through that repo, so infrastructure another team stands up stays invisible and still needs periodic reconciliation. And editing the diagram is not redoing the analysis: the new consumer still needs its threats considered, not just its arrow drawn.
go deeper
Know that the model lives in version control beside the code and that changing the architecture means changing the diagram in the same change, so its history is reviewable later.
Explain what the reviewer is actually looking for in the model diff - a new flow crossing a boundary, a new store or external dependency, a new data class - and why a binary image defeats the whole mechanism.
State the coverage limit without being prompted: this catches only change that flows through the repo, so it pairs with periodic reconciliation against the live environment. Describe how you keep the check from becoming a rubber stamp.
Own the balance between review friction and detection: how heavy an obligation the organisation can carry per change, which repos it applies to, and how you sample to prove the claims people write are true.
## The idea Store the model where the code lives, and make changing it part of the same review as the change that invalidated it. The model stops being a document that someone remembers to revisit and becomes an artefact with the same lifecycle as the code: branched, diffed, reviewed, merged, tagged with the release. The reason this works is timing. Reconciling a model against production after the fact is archaeology - you are reconstructing which of the last two hundred merges mattered. At review time the person who made the change is present, remembers why, and can answer in a sentence. ## What it actually buys - **Drift becomes visible at the moment it is created**, not at the next scheduled check. - **The model gets a real version history.** Each state is a commit, correlated with a release, so a later reviewer can ask what the model said at the time an incident happened, and can diff two points in time instead of rewriting from scratch. - **A shared frame for the discussion.** The diff shows what the author believed changed structurally. That belief is itself reviewable, and disagreement about it is a useful conversation. - **The reviewer population is right.** The people reviewing the code know the change; a central security team reading models in isolation does not. ## A worked example A telco number-porting service holds the drawn model in the repository, and the team's convention is that a structural change and its diagram change land together. A pull request adds a consumer to the porting-request queue so a new partner channel can submit ports. The code diff is small: a consumer class, some config. The model diff is the interesting part. A new publisher on that queue means a new path into the porting workflow, and porting integrity is the asset - a successful injection of forged port-out requests moves a victim's number to an attacker-controlled SIM, which is the pivot into everything that number authenticates. The reviewer's question is not "is the arrow drawn" but "who may publish here now, is that population authenticated per message, and does the model still claim only the internal request API can initiate a port?" That question is only asked because the model was on screen next to the code. ## Where it fails, and what to do about it **Undiffable models.** If the model is an exported image, the pull request shows "binary file changed" and review is impossible. Keep the model in a text-serialisable form - a structured file, or at minimum a short committed list of elements, flows, boundaries and data classifications beside the picture - so a human can read what moved. If reviewers cannot see the delta, the rule produces compliance, not review. **Change that never touches the repo.** Infrastructure created by another team, a configuration toggle flipped in a console, a vendor integration enabled by an account admin, a new consumer living in a different codebase - none of these pass through this gate. This is the important limitation to state out loud in an interview: same-pull-request review is a high-frequency, narrow-coverage detector, and it must be paired with periodic reconciliation against the live environment, which is broad and low-frequency. Neither alone is enough. **Rubber-stamping.** A mandatory checkbox with no prompt gets ticked. Make the ask small and specific: one line in the pull request description saying what changed structurally, or explicitly that nothing did, and a reviewer prompt naming the three things that matter - a flow crossing a boundary, a new store or external dependency, a new data class. Sample a handful of merged changes periodically and check the claim against the code; that is what keeps the answer honest. **Confusing an edit with an analysis.** Drawing the new arrow updates the picture; it does not decide whether the new path needs authentication, rate limiting or an audit record. The diagram change is the trigger for a short analysis of the added element, not a substitute for it. A team that congratulates itself on a perfectly current diagram with no new threats considered in six months has automated the wrong half. **Friction and scope.** Requiring a model edit on every pull request trains people to write "no change" reflexively. Keep the obligation proportionate to changes that alter the drawn architecture, and keep the model small enough that editing it is a minute's work; a sprawling diagram that takes an hour to update will simply stop being updated. ## How to answer this in an interview Give the benefit in one sentence, then immediately name the coverage limit and the rubber-stamp risk. Interviewers are listening for whether you think a repo-side control is sufficient. It is not; it is the cheap, frequent half of a two-part detection strategy, and saying so is what separates someone who has run the practice from someone who has read about it.
- The model is stored as an exported image, so the pull request shows only that a binary file changed. What do you do?Move the source of truth to something a human can diff: a structured text file describing elements, flows, boundaries and data classes, with the picture generated or attached as documentation. If that is not possible, require a short committed changelog entry beside the image naming what moved. Review that a reviewer cannot see is not review.
- What drift does this rule never catch?Anything that does not pass through that repository: a store or region stood up by another team, a console-flipped configuration, a vendor integration enabled at the account level, a consumer added in a different codebase. That is why it is paired with periodic reconciliation against live inventory, routing and telemetry, which is slower but sees the whole environment.
- How do you stop it from degrading into a checkbox?Make the ask specific and cheap: one line saying what changed structurally or that nothing did, and a reviewer prompt naming a flow crossing a boundary, a new store or dependency, and a new data class. Then sample merged changes occasionally and compare the claim with the code, so the answer is known to be checkable.
saying these in an interview costs you the question
- Claims a same-pull-request rule keeps the model in sync on its own
- Treats editing the diagram as having redone the analysis
- Keeps the model as an image nobody can read a diff of
- Adds a mandatory check with no reviewer prompt, so it is ticked blind
- Keeps the model somewhere reviewers never open during a change
- Requires a model edit on every change until people write no change reflexively