Secure software architecture and threat modelling
Agree which trust boundaries and attack paths the architecture must defend
A new service, integration or platform is being designed and its security assumptions remain implicit. The decision is to agree which trust boundaries and attack paths the architecture must defend. The work starts from how data, credentials and privileged operations cross each boundary in the intended deployment and ends with a threat model with ranked attack paths and the architectural mitigations attached to them. It is most relevant to software architects and product security leads. A useful result states what was examined, what remains uncertain and which decision the evidence can support.
Agree which trust boundaries and attack paths the architecture must defend
- Trust boundary
The starting condition this work depends on.
- Attack path
Where the consequence actually arises.
- Architectural mitigation
The finding and its open dependencies.
Decision
Frame the decision before scoping the work
Questions and the evidence each one needs
- Trust boundary
- Inspect architecture and data-flow diagrams.
- Attack path
- Inspect deployment topology.
- Architectural mitigation
- Inspect existing security requirements.
The decision is to agree which trust boundaries and attack paths the architecture must defend. This matters to software architects and product security leads when a new service, integration or platform is being designed and its security assumptions remain implicit. Name the affected product, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.
The specific failure hypothesis is that the design assumes a trusted internal network that the deployment no longer provides. It stays a hypothesis until it is examined in your own case. Existing design records, tests or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.
Mechanism
Follow the relationship that carries the consequence
Where the boundary is actually crossed
- Trust boundary
- The condition the design assumes.
- Attack path
- Where authority or information changes hands.
- Architectural mitigation
- The effect the owner must answer for.
What this specialty examines
Secure software architecture and threat modelling rests on how data, credentials and privileged operations cross each boundary in the intended deployment. Work from the configuration that will actually ship rather than from the reference design, and record where the two differ.
The examination draws on architecture and data-flow diagrams; deployment topology; and existing security requirements. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.
The tradeoff to make explicit
The tradeoff here is a simpler deployment topology against a smaller blast radius. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.
Preparation
Connect the inputs to the boundary examined
Preparation record for the engagement
Illustrative working format
- Architecture and data-flow diagrams
- Bounds the context.
- Deployment topology
- Supplies the material examined.
- Existing security requirements
- Exposes conditions that qualify a result.
Start with architecture and data-flow diagrams; deployment topology; and existing security requirements. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.
The scope also needs software architects and product security leads with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which the design assumes a trusted internal network that the deployment no longer provides from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.
Working sequence
Carry the question through to an accountable finding
From scoped material to a decision record
- Establish the system boundary
Set the conditions assumed.
- Derive attack paths
Apply the scoped check.
- Attach mitigations to the design
Record evidence and the next decision.
Establish the system boundary
Identify the components, actors, data classes and external dependencies in scope, and name the deployment the model describes. Record what is deliberately excluded.
Derive attack paths
Work from each boundary crossing to the asset it protects, recording the assumed attacker position and the conditions that make a path reachable. Keep an unreproducible observation in the record with its reason.
Attach mitigations to the design
Connect each ranked path to a specific architectural control, an accepted risk or an explicit open question with an owner. Hand the result over with its open dependencies attached.
Indicative artefact
Make the artefact usable by the person who owns the decision
A threat model with ranked attack paths and the architectural mitigations attached to them
Illustrative working format
- The modelled system boundary and its assumptions
- What was examined, and under which assumptions.
- Ranked attack paths with reachability conditions
- Each observation, linked to evidence.
- Mitigation decisions, accepted risks and open questions
- The next decision, and its limits.
The proposed decision artefact is a threat model with ranked attack paths and the architectural mitigations attached to them. Depending on the agreed scope, the pack may include:
-
The modelled system boundary and its assumptions. Basis: the definitions, boundaries and assumptions another reviewer would need.
-
Ranked attack paths with reachability conditions. Observation: the findings and their interpretation, preserving adverse results and disagreement.
-
Mitigation decisions, accepted risks and open questions. Decision: what the owner could do next, and what change would justify revisiting it.
Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.
Illustrative scenario
Examine the question through a constructed case
A constructed case and its decision paths
Illustrative scenario
- Trust boundary
A team adds a partner-facing integration to a service originally built for internal use.
- Attack path
Which boundary now carries untrusted input, and which privileged operation can it reach?
- Architectural mitigation
Add an enforcement point at the integration boundary before the interface is published.
Consider an illustrative situation: a team adds a partner-facing integration to a service originally built for internal use. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.
The question to examine is which boundary now carries untrusted input, and which privileged operation can it reach. A reasonable next action would be to add an enforcement point at the integration boundary before the interface is published. The decision record should state which configuration was accepted and which limitations came with it.
Scope and next action
Keep the conclusion inside the agreed boundary
Confirm fit before the next commitment
- Trust boundary
- Limited to the agreed scope and configuration.
- Architecture and data-flow diagrams
- The owner confirms access and conditions.
- Architectural mitigation
- A threat model is a structured argument about a design, not a demonstration that the built system resists attack.
A threat model is a structured argument about a design, not a demonstration that the built system resists attack. Any engagement depends on an agreed scope, a qualified team and authorised access.
Bring the affected product or workflow, its current configuration and the evidence you already hold. The scope question follows from the situation in which a new service, integration or platform is being designed and its security assumptions remain implicit. Confirm which missing observation would change the owner’s next action.