Twenty threat models all assume CI runners cannot reach production databases, and nobody has tested it. What do you do?

## Assumption, control, and the gap between them Threat modelling depends on inheritance. A product team does not re-derive network segmentation, key storage or runner isolation for every service; it states what it is relying on and models what it owns. That is correct and it is how the practice stays affordable. The failure mode is that the inherited item is written down and never verified, so the model rests on a **belief** while reading like a **control**. *CI runners cannot reach production databases* is a good example because it sounds like a fact about the network. In twenty models it is doing enormous work: it is why a build compromise is scoped to the build, why credentials in the pipeline are treated as lower value, why database-level threats are ranked below others. If it is wrong — a peering route added for a migration, a temporary rule that outlived its ticket, a new runner pool placed in a subnet nobody re-checked — then twenty models are wrong at the same moment, and none of them will notice, because the sentence stays true on the page. ## Who benefits when the assumption is false Name the attacker and the asset, because they set how hard to work on this. The attacker is whoever controls what a build runner executes: a compromised transitive dependency pulled during the build, a pull request from a fork that triggers a job, a stolen runner registration credential, an insider with commit rights. That attacker starts with code execution in a machine that already holds credentials and network position. The asset is customer data sitting in the production database, reachable in bulk and without a login. That is why the assumption is worth a test rather than a footnote: it is the boundary between a bad day and a breach notification. ## Turning the assumption into a test The assumption states a **negative** property — this path does not exist — and negative properties cannot be verified by reading configuration. Configuration tells you what the configuration says; a route added elsewhere, a proxy, a service mesh egress, or a second network interface all falsify it without changing the file you read. Verify it by attempting the thing: - From a **real runner**, in the same network position a build actually occupies, including each runner pool. - **Attempt the connection** to a production database endpoint — resolve, connect, complete the transport handshake. - **Fail the run when it succeeds.** The test passes only when the connection is refused, dropped or unroutable. - **Run it on every change to the control**, not once at design time, because the property degrades through ordinary infrastructure work rather than through anything anyone would flag as security-relevant. Where the test lives matters as much as what it does. Put it in the platform's own suite, not in twenty product repositories. The product teams do not own the network path, cannot change it, and cannot see it change; twenty copies of the same test drift, get skipped, and still leave a twenty-first service arriving with no test at all. One test, sitting with the control, runs whenever the control changes and routes its failure to the team that can actually fix it. ## Inheritance becomes safe once it is evidenced Once the test exists, something changes in every one of the twenty models. Where they used to say *we assume runners cannot reach production*, they can say *we inherit runner-to-production isolation, verified by a test owned by the platform team*. The sentence is the same length; what sits underneath it is different. Inheritance is now the transfer of a verified control instead of the transfer of optimism. This also creates an obligation in the other direction. Something has to record **who depends on the assumption**, because the first question when the test goes red is not how the path opened — it is which services just lost a control they were counting on. If the dependency is only implicit in twenty documents, you discover the blast radius one team at a time, usually after an incident. ## The general rule Read the portfolio for assumptions the way you read it for threats. An assumption repeated in many models is not stronger for being repeated — it is more dangerous, because its consequences fan out and its ownership is diffuse. The practical rule: **every inherited control that many models rest on needs a named owner, an active test from the right vantage point, and a list of dependants.** Anything short of that is a sentence protecting nothing, replicated twenty times.