---
name: threat-model-stride
description: "Threat-models a described system by enumerating trust boundaries, running STRIDE at each, and mapping every threat to its control family. Use when reviewing a system or design for how it could be attacked and what to defend."
metadata:
  decimalai-skill-id: "a54a8799-9120-4929-84da-6c97a3c08e56"
  decimalai-version-id: "239027c3-002a-4f1d-a822-8ad5823f9852"
  decimalai-version: "1"
  decimalai-body-sha256: "4c01d00345ac07f728a7c3506f1e96bd281870856f0a8fb9d8b7e29f450b210d"
  decimalai-name: "threat-model-stride"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "security"
  decimalai-source: "https://app.decimal.ai/s/threat-model-stride@1/SKILL.md"
---
# STRIDE Threat Modeling

Turns "what could go wrong with this system?" into a repeatable pass instead of an
ad-hoc bulleted risk list. The method: find every place trust changes hands, walk the
six STRIDE categories at each one, and tie every threat found to the control family that
answers it. The value is coverage and traceability — nothing skipped, every threat has a
named defense.

## When to Activate

Activate when someone describes a system, service, feature, or architecture and wants to
know how it could be attacked and what to defend — a pre-launch security review, a design
review, or a "where could an attacker get in" question.

Do **not** activate for: patching one already-identified vulnerability, writing an
exploit or proof-of-concept, live incident response, choosing a single algorithm/library,
or general non-security code review.

## Method

Work in three ordered steps. Do not jump to a risk list — the ordering is the discipline.

### Step 1 — Enumerate trust boundaries

A **trust boundary** is any point where data or control crosses between zones that trust
each other differently. Trace the flow of data through the described system and mark a
boundary wherever one of these is true:

- Data crosses the **network edge** — the public internet reaches a service (browser → API).
- An actor's **privilege level changes** — anonymous → authenticated, user → admin, tenant → shared resource.
- Data moves between **processes owned by different principals** — your app → the database, service → message queue.
- A **third party or new ownership domain** is involved — your code → an external API, one tenant's data → another's.
- Data enters a **more-trusted zone from a less-trusted one** — untrusted input reaching business logic, an upload reaching storage.

List each boundary explicitly with the two zones it separates. A single-user, offline,
same-owner process has few or no boundaries — say so rather than inventing internet-facing
threats that cannot occur.

### Step 2 — Run STRIDE at each boundary

For every boundary from Step 1, ask whether each of the six categories applies to what
crosses it. Skip a category only when you can say why it does not apply here.

| STRIDE | The threat | Property it violates |
|--------|-----------|----------------------|
| **S** — Spoofing | An attacker pretends to be another identity crossing the boundary | Authenticity |
| **T** — Tampering | Data or code is modified in flight or at rest | Integrity |
| **R** — Repudiation | An actor performs an action and can later deny doing it | Non-repudiation |
| **I** — Information disclosure | Data crossing the boundary is exposed to someone unauthorized | Confidentiality |
| **D** — Denial of service | The boundary or the resource behind it is exhausted or made unavailable | Availability |
| **E** — Elevation of privilege | An actor gains rights beyond what the boundary should grant | Authorization |

### Step 3 — Map each threat to its control family

Every threat named in Step 2 gets tied to the control family that defends against it. This
mapping is fixed — it is the same for every system:

| STRIDE category | Control family | Representative controls |
|-----------------|----------------|-------------------------|
| Spoofing | **Authentication** | MFA, mutual TLS, signed tokens, verifying webhook signatures |
| Tampering | **Integrity** | Input validation, signing/checksums, TLS, immutable/append-only storage |
| Repudiation | **Audit / non-repudiation** | Tamper-evident audit logs, signed receipts, trusted timestamps |
| Information disclosure | **Confidentiality** | Encryption in transit and at rest, least-privilege access, secrets management |
| Denial of service | **Availability** | Rate limiting, quotas, timeouts, autoscaling, circuit breakers |
| Elevation of privilege | **Authorization** | Least privilege, RBAC/scoped tokens, input validation at the boundary, sandboxing |

A threat with no named control from its family is not modeled — it is just a worry.

## Output shape

Present findings grouped **by boundary**, not as one flat list. For each boundary: name
the two zones, then the STRIDE threats that apply, and for each threat its control family
and a concrete control. A short table per boundary reads best. Close with the highest-risk
boundary and the single control that would reduce the most exposure.