# Pathrule Pattern: Threat Modeling (1.0.0)
# ::pathrule:package:threat-modeling

### [RULE] Every material threat receives a recorded response  (path: /docs/security)
<!-- scope: folder | priority: high | strict -->

Threats are mitigated, eliminated, transferred, or explicitly accepted with evidence and ownership. An unranked threat list creates the appearance of review while leaving the team unable to tell which risks block delivery. Enforce this boundary in /docs/security so invalid work stops before it reaches another subsystem or creates an externally visible side effect.

- Describe the attacker capability, targeted asset, trust boundary crossed, preconditions, and plausible impact in system-specific terms.
- Choose a response and connect mitigation responses to a concrete requirement, implementation owner, and verification method.
- Require a named risk owner and review date for acceptance or transfer; developers cannot accept business risk by omission.
- Reopen the decision when data sensitivity, exposure, identity, dependency, or architecture assumptions change.

Verification: Sample every high-impact path and trace it from model to code or test evidence; fail review for orphan threats, orphan controls, and expired acceptances.

---

### [MEMORY] The model is a map of trust, not a diagram of components  (path: /docs/security)

Component boxes alone do not reveal where data changes authority, validation, ownership, or confidentiality. Show actors, assets, processes, stores, external systems, data flows, and trust boundaries, then annotate identity and protection on each crossing.

Split broad diagrams until reviewers can reason about one sensitive flow without guessing hidden hops. Include control-plane, support, recovery, CI, and third-party paths because attackers do not stay on the happy-path architecture. Record assumptions such as private-network reachability or upstream validation as testable dependencies, not facts. Keep the decision explicit at /docs/security; moving it into an incidental caller makes behavior depend on which route happened to execute first.

See /src/api for enforcement points and /infra for workload and network trust boundaries. That related boundary consumes this decision and carries the evidence that proves it still holds.

---

### [SKILL] run-threat-model  (path: /)

---
name: run-threat-model
description: Run a structured threat-model workshop and turn findings into owned, testable security work.
---

# Run Threat Model

Run this procedure whenever the governed surface changes or its operational evidence becomes stale.

1. Define scope, assets, security objectives, attacker capabilities, and out-of-scope assumptions before discussing controls.
2. Draw data flows with identities, stores, external systems, protocols, and trust boundaries; walk one real scenario end to end.
3. Use STRIDE or another prompt set at each boundary, then write concrete abuse paths and rank them with product and operations input.
4. Choose responses, create mitigation requirements and verification tasks, assign risk owners, and schedule the next review trigger.

Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

---

### [SKILL] review-threat-model  (path: /docs/security)

---
name: review-threat-model
description: Review an existing threat model for architecture drift, unresolved risks, and ineffective mitigations.
---

# Review Threat Model

Run this procedure whenever the governed surface changes or its operational evidence becomes stale.

1. Compare the model with current deployment manifests, routes, identities, stores, third parties, and privileged support or recovery paths.
2. Re-run abuse-path prompts for changed boundaries and identify assumptions that no longer have evidence.
3. Trace each open and high-impact threat to a current response, owner, test, monitoring signal, and acceptance expiry where relevant.
4. Publish the delta, create follow-up work with measurable outcomes, and record the event that will trigger the next review.

Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.