threat-modellisted

# Threat Model Threat modelling is cheap before the build and expensive after. Do it at design time. ## Procedure 1. **Scope.** Name the system, its trust boundaries, and what is explicitly out of scope. Out-of-scope items are written down — silence reads as coverage. 2. **Data flow.** Diagram actors, processes, data stores, and every flow that crosses a trust boundary. Threats live at the crossings, not inside the boxes. 3. **Enumerate with STRIDE** at each crossing: | | Question | |---|---| | **S**poofing | Can an actor claim another identity? | | **T**ampering | Can data be modified in transit or at rest? | | **R**epudiation | Can an action be denied because nothing logged it? | | **I**nformation disclosure | What leaks, to whom, through which channel? | | **D**enial of service | What exhausts under load or deliberate abuse? | | **E**levation of privilege | How does a low-privilege actor gain more? | 4. **Rate** by exploitability and impact. Not by gut feel, not by scanner severity. 5. **Mitigate or accept.** Every threat gets a control, or a signed risk acceptance with a named owner and an expiry date. 6. **Verify.** Each mitigation names the specific test that proves it works. ## Output ```markdown # Threat Model: <system> ## Scope and trust boundaries ## Out of scope ## Data flow ## Threats | ID | Boundary | STRIDE | Threat | Exploitability | Impact | Mitigation | Verified by | ## Accepted risks | ID | Risk | Owner | Expiry | Rati