Lightweight STRIDE Threat Model for a New Endpoint or Service

Tier: Core · Workflow area: Architecture & Design

The lightweight version is different: AI drafts a STRIDE pass against your actual endpoint spec in minutes, you validate and prune it as the engineer who knows the system, and the mitigations land as tickets in the same sprint. It will not replace a security review for your auth service — it raises the floor for the forty endpoints that would otherwise get nothing.

When to use

• •
  A new endpoint, webhook receiver, file upload, or internal service is about to be built or has just been designed (pairs with pb-36 as Lens 3, expanded).
• •
  An existing endpoint is getting new powers — broader scope, new data category, exposure to a new caller class.
• •
  A client or compliance checklist asks "was this threat-modeled?" and the honest answer is currently no.

Do not rely on this alone for authentication systems, payment flows, or crypto design — those earn the real security review. This playbook's output is also that review's best pre-read.

Prerequisites

• •
  A concrete description of the thing: endpoint spec (method, path, auth, request/response schema), the data it touches with sensitivity labels, callers and downstream dependencies, and the trust boundaries crossed. One page; the AI cannot threat-model what you have not described.
• •
  A STRIDE crib: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
• •
  Your ticket tracker open — a threat model whose mitigations do not become tickets is a PDF.

The workflow

1. 1.

   Draft the model with the spec pinned.

   Copy

   Threat-model this endpoint using STRIDE. Spec:
   POST /v1/webhooks/payment-provider — receives payment status callbacks.
   Auth: HMAC signature header (shared secret per provider). Body: JSON,
   provider's schema. On success: updates payment status in Postgres, emits
   payment.updated event. Callers: 2 external providers over the internet.
   Data: payment IDs, amounts, last-4 card digits.
   For each STRIDE category: 2-4 concrete threats SPECIFIC to this spec (not
   generic "use HTTPS" advice), each with: attack scenario in one sentence,
   what the attacker gains, likelihood (H/M/L) and impact (H/M/L) with a
   one-line justification, and a specific mitigation naming the component
   that changes. Mark any threat that depends on an assumption about our
   infra you cannot verify with [ASSUMES: ...].
   

2. 2.

   Validate as the system expert. Walk every threat: Is it real here? (The model does not know your WAF exists — kill mitigations already in place, but record them as "existing control", which is half the compliance value.) Is the likelihood honest for your exposure? Did it miss the threat only an insider would know (the admin bypass header from 2022, the staging endpoint sharing the secret)? Add those — the model's list is a floor, your knowledge is the ceiling.

3. 3.

   Interrogate the gaps. Two follow-ups that reliably harvest more: What threats emerge from the interaction of this endpoint with the payment.updated consumers downstream? and Which threats change if the HMAC secret leaks — what is the blast radius and how would we detect and rotate? Secret-compromise blast radius is the question lightweight models of webhook endpoints most often skip.

4. 4.

   Convert to tickets with acceptance criteria. For each accepted threat above your risk line:

   Copy

   Turn accepted threats T2 (replay of captured callback) and T5 (status
   spoof via schema-valid forged body) into engineering tickets: title,
   context paragraph, specific change (timestamp + nonce validation with 5-min
   window; provider IP allowlist as defense-in-depth), acceptance criteria
   including the negative test that proves the mitigation (replayed request
   returns 401 and increments a metric), and an effort guess.
   

   Below-the-line threats get an explicit "accepted risk" entry with a named accepter — the honest artifact auditors actually respect.

5. 5.

   File the model next to the code. docs/threat-models/payment-webhook.md: the validated table (threat, rating, mitigation-or-accepted, existing controls), dated, with a revisit trigger ("re-run when a new provider is added or the event gains consumers"). Re-running the same prompt after a change and diffing the output is the cheapest threat-model refresh in existence.

Tool variants

• Claude / ChatGPT with the spec pasted: the default; reasoning-tier models produce noticeably better interaction-threats (step 3).
• Repo agent (Claude Code / Copilot agent): when the endpoint exists in code, let the agent read the handler and middleware first — it will catch that the "HMAC validation" is actually inside a try/except-pass, which no spec-only pass can see.
• Deterministic pairing: run Semgrep (free CE) rules for the mitigation patterns (missing auth decorator, raw SQL) — deterministic tools verify presence; the LLM proposes what should be present.

Verification

• •
  Every threat in the final table is either mitigated (ticket linked), accepted (named accepter), or covered by a recorded existing control — no orphans.
• •
  All [ASSUMES] tags resolved with what you actually verified.
• •
  Each mitigation ticket carries a negative test in its acceptance criteria; when the ticket closes, that test exists and fails against the unmitigated behavior.
• •
  At least one threat in the table came from you, not the model — if not, you validated too gently.

Pitfalls

• Generic-checklist output. If the threats would apply to any endpoint ("attacker may intercept traffic"), your spec was too thin — the fix is a better input, not a longer output.
• Threat-modeling the design instead of the deployment. The spec says HMAC; production has the legacy unauthenticated route still mounted. Repo/infra grounding (agent variant) or your own knowledge must close this gap.
• Rating inflation and fatigue. If everything is High/High, nothing gets fixed. Force-rank if needed; the point is the top five getting tickets, not a complete taxonomy.
• One-and-done. The model is dated and trigger-conditioned for a reason; an endpoint that gained three consumers since its threat model has no threat model.

Restricted-environment variant

Threat models are doubly sensitive: they contain both client architecture and a curated list of its weaknesses. Never run them through unsanctioned tools. Use the client's approved tenant; failing that, abstract the spec (neutral names, keep auth mechanism/data categories/trust boundaries — those drive the threats) and re-concretize locally. Local Ollama models produce a usable first-pass STRIDE table from a well-written spec — the categories scaffold the weaker model effectively — but step 3's interaction questions degrade most; run those as a written exercise with a colleague. Store finished models with the same access controls as incident reports, not in the world-readable wiki.

Success criteria

• •
  The endpoint shipped with a validated threat-model table, mitigation tickets in the sprint, and explicit accepted-risk entries.
• •
  Negative tests from the tickets are in CI, proving mitigations against replay/spoof/DoS behaviors.
• •
  Time cost was under two hours end-to-end — cheap enough that the next endpoint gets one too.
• •
  When the security team does review the service, they start from your table instead of a blank page — and find little to add at this altitude.