Start secure software development by connecting the system’s trust boundaries to specific threats, design decisions and acceptance evidence. Start during design, keep the model current and assign an owner to unresolved risks. Use the worksheet below to trace a consequential threat from the data flow it affects to the check that supports a release decision.
What system are you asking the team to protect?
Choose a bounded service or workflow and draw the important actors, applications and data exchanges. Identify where a customer, staff member or external service supplies information and where the system changes something consequential. Keep the diagram understandable enough for the people operating the service to challenge it.
OWASP describes threat modelling as a structured, repeatable process. Documentation. OWASP says the system model should make trust boundaries and data flows clear. Documentation. OWASP describes data-flow diagrams as models of flows and external interactions. Documentation. Use those modelling ideas to make assumptions visible. A line labelled integration should prompt questions about the information crossing it, the authority used and the intended handling when the other side cannot be trusted or reached.
Record sensitive data and consequential actions beside the relevant flow. Ask who is allowed to cause each action and which evidence establishes that authority. Include the administrative and support routes the service actually needs, rather than drawing only the public customer journey.
When should the threat model affect the design?
OWASP recommends threat modelling early in the development lifecycle. Documentation. OWASP recommends maintaining the threat model alongside the system. Documentation. Review the model when a new role, data source, operation or integration changes a boundary. Keep the previous decision reference so the team can understand why an older control existed and whether the change affects it.
For each important flow, ask what could go wrong in that particular system. An incorrect customer association, an untrusted file or a repeated external message may require different responses. Write a concrete scenario rather than relying on a generic statement that the application must be secure.
Decide the intended response before selecting a tool. The response could involve rejecting an input, narrowing an operation, requiring another approval or changing the workflow. Assign someone to make the decision and identify the evidence needed to show that the chosen response works in the intended arrangement.
An original threat-to-evidence worksheet
Use this practical checklist for a defined change or service boundary. Populate it with the system’s actual actors and records. It is an original working aid for a design and acceptance discussion, with observations to add when checks are carried out.
| Design element | What to record | Question before acceptance |
|---|---|---|
| Boundary | Actor, system and data crossing the boundary | Which authority or trust assumption changes here? |
| Threat scenario | Specific unwanted action or disclosure | What could happen in this workflow? |
| Consequence | User, business or operational effect | Why does the scenario matter? |
| Chosen response | Design rule and responsible component | How should the system behave? |
| Acceptance check | Input, expected outcome and environment | What evidence would establish the intended response? |
| Residual issue | Unresolved assumption and owner | Who decides what happens next? |
| Change trigger | New role, interface or data use | When should the decision be reviewed? |
Keep a clear distinction between the proposed control and the observed result. A diagram showing an authorisation boundary is useful design information; the acceptance record should still identify how the actual request was checked. Make that relationship explicit in the working copy.
Include a reference to the code or configuration responsible for a consequential rule where appropriate. This lets a future reviewer locate the implementation when the model changes. Avoid making the worksheet a disconnected assurance document that cannot be related to the software being released.
How does this fit into the development process?
NIST SSDF recommends high-level security practices integrated into an existing development lifecycle. Documentation. Integrate the required decisions into the team’s existing planning, implementation and release work. For example, attach the relevant threat scenario to the change request and its acceptance evidence to the review. Give unresolved security work an owner and a visible decision route.
NIST describes SSDF as a shared vocabulary for secure software development. Documentation. NIST identifies software producers and software acquirers as its two main SSDF audiences. Documentation. Use that shared language when agreeing what a development partner must deliver and what the acquiring organisation must review. Define the evidence expected for the particular service instead of relying on an undefined promise that a product follows best practice.
NIST distinguishes understanding the SSDF document from the expertise needed to implement its practices. Documentation. Assign work to people with the relevant expertise and give the decision-maker a clear explanation of the findings. A business owner can specify the consequences that matter, while the engineering and security specialists establish appropriate technical responses and their practical limits.
Hypothetical example: an imported file changes the wrong account
Imagine a service imports a customer-provided file and uses a reference in it to choose the account to update. The proposed threat is that the reference could identify a different account from the one the submitting user is authorised to affect. This hypothetical scenario gives the worksheet a specific boundary to examine.
Draw the submitting user, upload handler, record lookup and write operation. Identify where the system establishes the user’s authority and where the file supplies data. Write the intended rejection behaviour for a mismatched account before choosing a test input.
In a controlled rehearsal, use synthetic accounts and files. Request both a permitted update and a cross-account attempt, preserving the relevant record state and response. Keep the check tied to the implementation version and identify any related operation the exercise did not cover.
Then consider the support route for an import that cannot proceed. Ask who receives the exception and what information they need to resolve it without bypassing the account boundary. Include that operational path in the design review rather than treating it as an afterthought.
What should happen after a defect is found?
NIST SSDF includes addressing vulnerability root causes to prevent recurrence. Documentation. Record the defect’s underlying assumption and the affected class of operation. Review whether another route uses the same unsafe decision and which checks should be added or changed. Keep the correction and its evidence connected to the threat model so the next similar change starts from what has been learned.
Prepare the release decision with the relevant scenarios, observations and unresolved issues. The reviewer should be able to see which risks were addressed, which assumptions remain and who owns them. Revisit the record when the software changes those boundaries again.
For the broader implementation scope, see web development. Keep ordinary release-risk coverage with software QA. Get started with the service boundary, data flow and acceptance questions you want the project brief to resolve.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.