SDLC Integration and Tooling

Generated output is a floor, not a finished model. A tool reliably applies the same per-element rules everywhere and catches structural gaps, such as a data store drawn with no trust boundary. It cannot judge business impact or whether the diagram is true.

Because the model becomes a version-controlled source file that diffs in a pull request. pytm's Python and threagile's YAML sit beside the code and regenerate the data-flow diagram and threat report on every run, so the picture never goes stale.

Reconcile the model against independent evidence of the running system - deployment descriptors, service and datastore inventories, routing and access config, traffic telemetry - and record every element, flow or trust boundary that reality has and the model does not.

Trigger on architectural change, not code volume: a new component or service, a new trust boundary such as a new caller or tenant, a new class of data, and any incident that disproves a design assumption.

A threat repeating across nearly every model is a missing platform capability, not thirty-eight product defects. Build the control once where every service inherits it, then each model names that control instead of carrying its own ticket.

Four families: coverage of in-scope designs and services against a stated denominator, findings closed and mean time to close, time-to-model from trigger to owned findings, and escaped issues found after the design passed.

Pick the engineer whose design opinion the squad already follows, who wants the role, and whose hours for it are protected. Spare capacity is the worst criterion: an uninfluential engineer with free time produces threat models nobody acts on.

One ticket per threat, in the team's normal delivery backlog, each carrying the threat statement, the agreed control, a named individual owner and a due date. A single 'security' epic hides ownership and lets the whole batch stall.

A template supplies stencils with properties and threat rules. You place stencils and set their properties, and the rule engine walks each interaction between elements, firing every rule whose conditions match and emitting a STRIDE-categorised threat you then triage.

Facilitate by asking, not telling. The facilitator's job is keeping the team producing threats: pose questions about the design, park teaching and fix debates in a parking lot, watch the clock, and check part-way through that findings are accumulating.

It is a first-pass checklist, not an analysis. The draft reliably names the obvious threat for each component type, so a review starts from a filled page instead of a blank one. Ranking and business impact stay human work.

No. 'Private network' is an assumption the generator accepted as fact, not something it checked. If the partner shares that circuit with its other customers, the link is untrusted and every threat suppressed by that label comes back.

Match the tool to the team's ceremony budget. Threat Dragon is free and keeps models as plain JSON; the Microsoft Threat Modeling Tool generates threats from Windows-only stencil templates; IriusRisk is a commercial platform with a countermeasure library.

pytm reasons only over what the model asserts. Declaring a flow encrypted stops the disclosure and tampering rules from matching that hop, so the generated report reads clean about a link anyone on the internal network can read.

It 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.

Attach modeling to design decisions rather than a fixed unit of work: a full session per epic or architecture change, plus a cheap per-story filter asking only whether this story changes the design. Both fixed extremes fail.

Turn the repeated assumption into a test the platform owns and runs continuously. An unverified inherited control is a shared belief, not a control, and twenty models depend on it, so one wrong belief invalidates all twenty at once.

Interrogate the three hidden choices behind the percentage: which population forms the denominator, what test earns a service a tick in the numerator, and how recent the model must be to count. Then sample and reconcile against an independent inventory.

Walk a fixed chain and stop at the first no: was it in scope, on the diagram, enumerated, rated correctly, accepted deliberately, controlled, and was the model current. Each stop names a different part of the practice to fix.

Capture during the session, not after, and reserve the last ten minutes to give every finding a disposition, a named owner and a date, in the team's normal tracker. A list with no owners is not an outcome.

Done means the agreed control is merged and running in the environment the threat targets, and evidence exists that fails if the control is removed. A design note, a ticket comment or a reviewer's approval is not done.

Check the inventory before the threats: reconcile every component and data store in the draft against the real system, then make an owner point at evidence for each control the draft claims exists. Anything unverified reverts to a stated assumption.

The centre keeps the method, not every session: curriculum and coaching, a small library of reference models, a published risk line above which it reviews the design itself, and a sample review that stops model quality drifting.

Treat champion turnover as expected. Before the champion leaves, get the models and the reasoning behind them into the squad's repository, hand over to a named successor who inherits the same protected hours, and have the central team cover the gap.

It tells you auto-filing moved review work onto a sprint board without doing any of it. Mass closure is the team correctly rejecting undifferentiated output, and the real cost is that the next genuine finding gets closed the same way.

Treat the output as an inventory of what the library knows, not a backlog. Re-rank against your product's real assets, record a reason on every dismissal, ticket only what changes the design, and tune the rules.

Whoever owns the consequence, not whoever can merge. Storing tracking statuses in the model repo makes acceptance a one-line code change, so it needs a named accountable owner, a stated expiry and a review path stricter than an ordinary merge.

Give every model a status and a verification date, mark this one retired with the date, reason and successor, and generate assurance packs from the live index rather than circulated copies, so a retired model can never read as current coverage.

Rank by consequence and reach, not alphabetically: services that cross an external or tenant boundary, hold the most damaging assets, or sit on the critical path go first. Accept that the long tail never gets a full model.