← All craftbooks

Lightweight Threat Model

Review and QAevalv1.0.0released 2026-06-05workflow: build-loop

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

1. Scope the systemplannerentry

   draw the data-flow + trust boundaries, lock scope

   Show working prompt

   Step 1: Describe the feature/system and draw its data-flow as a simple diagram (text/markdown is fine): the external actors and clients, the processes/services, the data stores, and the data flows between them. Step 2: Mark the TRUST BOUNDARIES — every line a request crosses from less-trusted to more-trusted (internet→service, service→db, user→admin). Step 3: List the assets worth protecting (PII, credentials, money, integrity of records) and the security objectives (confidentiality/integrity/availability priorities). Step 4: State what is IN scope and explicitly OUT of scope. Step 5: Write the acceptance-criteria checklist for the model, e.g. 'every element and trust boundary is in the diagram', 'each element is analyzed against all six STRIDE categories', 'every credible threat has a likelihood, impact, and mitigation'. A threat model is a review/analysis deliverable, not shipped product source, so write the diagram + assets + scope + checklist to the ARTIFACT `reports/threat-model-scope.md` with `write_artifact` (not the workspace), and drop a one-line summary via `write_task_note`. No threat enumeration yet.

2. Enumerate threatsreviewer

   STRIDE each element, rate likelihood × impact

   Show working prompt

   Step 1: For EACH element and trust-boundary crossing in the diagram, walk the six STRIDE categories and ask what a malicious actor could do: Spoofing (impersonate an actor/service), Tampering (alter data in transit or at rest), Repudiation (deny an action without an audit trail), Information disclosure (read data they shouldn't), Denial of service (exhaust a resource), Elevation of privilege (gain rights they shouldn't). Step 2: For each credible threat capture: the element/flow it targets, the STRIDE category, a one-line attack scenario, the likelihood (high/med/low) and impact (high/med/low), and a resulting risk rating. Step 3: Drop threats that are not credible for THIS system and say why (so the model is honest, not exhaustive theater). Step 4: For each credible threat, draft a concrete mitigation (e.g. 'sign tokens + verify on every boundary', 'parameterize + least-privilege the db role', 'rate-limit + idempotency key'). Step 5: Note existing controls already covering a threat. Good looks like: threats anchored to specific diagram elements with a plausible scenario, not generic 'hackers could attack'. Write the STRIDE threat table to the ARTIFACT `reports/threat-model-stride.md` with `write_artifact`, and note progress with `write_task_note`. Do not write the final report yet.

3. Write the threat modelreviewer

   prioritized threats mapped to mitigations

   Show working prompt

   Step 1: Write the report to the ARTIFACT `reports/threat-model.md` with `write_artifact`, embedding the data-flow diagram and the trust boundaries up top. Step 2: Add a '## Threats' table ranked by risk (likelihood × impact): each row = element/flow, STRIDE category, attack scenario, likelihood, impact, risk, and the mitigation. Step 3: Add a '## Mitigation plan' ordered by priority — the must-do-before-ship controls first, with an owner/area for each. Step 4: Add an '## Accepted/low risks' section for threats consciously not mitigated and the rationale, and a '## Existing controls' note. Every credible threat must map to a concrete mitigation; no generic security platitudes. On a loop-back, fix only the named gaps. `write_task_note` the report path and the count of high-risk threats.

4. Evaluatereviewer

   Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

   Show working prompt

   Open the artifact `reports/threat-model.md` (with `read_artifact`) and grade it against the scope checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) the data-flow diagram and trust boundaries are present; (2) every element/boundary was analyzed against all six STRIDE categories; (3) each credible threat has a concrete attack scenario, a likelihood, and an impact; (4) threats are ranked by risk; (5) every credible threat maps to a specific mitigation with an owner/area; (6) non-credible or accepted risks are stated with rationale; (7) no generic 'hackers could attack' filler. If any criterion fails, name the exact gap and loop back.
   
   Then route — this is the whole point of the loop:
   
   - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
   - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "report" })` to loop back. The builder fixes exactly those gaps.
   
   Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.

5. Finishdeveloper

   All acceptance criteria met. Stamp a short summary and report DONE.

   Show working prompt

   Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s) (the artifacts under `reports/`), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

• threat model this
• STRIDE analysis
• what could go wrong with this design
• security design review
• map the attack surface
• model the threats

Source

View this craftbook on GitHub · MIT license