# Threat Model Helper

> threat-model-helper

- Skill: `themarmack/threat-model-helper` (Agent Skill)
- Install (CLI): `npx skillmds@latest add themarmack/threat-model-helper`
- Raw SKILL.md: https://api.skillmd.com/api/skills/themarmack/threat-model-helper/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: themarmack (https://skillmd.com/u/themarmack)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/themarmack/threat-model-helper

---


# threat-model-helper

The org's first-pass threat-modeling tool. Most services in a regulated organization's portfolio either lack a threat model entirely or have one frozen from initial design. This skill makes "generate a fresh STRIDE pass" cheap enough to do at any milestone.

## When to use

- New service entering architecture review.
- Retrofit for a service that has no threat model on file.
- Re-threat-model after a material change (new dependency, new data flow, new integration with an AI tool).
- Pre-incident-response prep: think through what could go wrong before it does.

## When NOT to use

- Code-level vulnerability hunting → `codeql-pattern-finder` or `iac-security-reviewer`.
- Single-control review → `secure-design-reviewer` for architecture doc; `actions-workflow-hardener` for workflows.
- Compliance gap analysis → [`compliance-framework-lookup`](../compliance-framework-lookup/SKILL.md).

## Compliance-relevant threat catalog (pre-loaded)

For each new service, the skill walks through these threat families, scoring whether each applies + at what likelihood:

| Family | Description | Default applicability |
|--------|-------------|----------------------|
| S — Spoofing | Identity forgery | medium baseline |
| T — Tampering | Data integrity violation | medium baseline |
| R — Repudiation | Lack of audit trail / non-repudiation | high baseline (SOX evidence) |
| I — Information disclosure | Regulated-data exfiltration | **HIGH baseline** for any service touching customer/card data |
| D — Denial of service | Availability impact | medium baseline |
| E — Elevation of privilege | Auth bypass / privilege escalation | medium baseline |

Plus **org-specific threat families** layered on STRIDE:

| Bank-specific family | Description | When applicable |
|----------------------|-------------|-----------------|
| Regulated-data egress | Data leaving the org's boundary via AI tool / 3rd-party / log | Any service where Copilot, Cursor, etc. could see the data |
| Prompt injection from upstream | Untrusted content reaching an LLM context | Any service whose data feeds Copilot Chat / knowledge bases / RAG |
| CI/CD supply-chain | Mini-Shai-Hulud-class workflow compromise | Any service with non-trivial CI |
| Model output as control bypass | Using an LLM to make a decision that should be policy-enforced | Any service where AI generates user-facing decisions |
| Audit-trail completeness | Per [[audit-per-suggestion-traceability]] objection — what's the per-event evidence trail? | Any SOX-relevant service |

## Required inputs

- **Service description**: 3-5 sentences on what it does.
- **Component diagram** (text or ASCII OK): components + data stores + external integrations.
- **Data flows**: which data moves between which components.
- **Trust boundaries**: explicit boundary lines (network, identity, data-classification).
- **Data classification**: regulated? PII? card data? PHI? public?
- **AI tool integration**: does Copilot / any LLM see the data?

## Workflow

1. Walk through each STRIDE letter; for each, score applicability HIGH/MEDIUM/LOW given the service description.
2. Walk through each org-specific family; same scoring.
3. For HIGH and MEDIUM threats, produce a concrete attack scenario + recommended control mapped to the org's control catalog (or external standard if internal catalog isn't named in the input).
4. Highlight the **top 5 threats by likelihood × impact** at the top.
5. Note **out-of-scope but adjacent threats** (e.g., the service doesn't touch X but neighbor service does).
6. **Persist the threat model** — after presenting it in chat, write the full note via `vault-writer.write_research` to `vault/research/appsec/YYYY-MM-DD-threat-model-{service-slug}.md` (frontmatter per `research.yml`, `topic: appsec`) so `secure-design-reviewer` and future re-threat-model passes can query it.

## Output structure

```markdown
# Threat Model — {service name}

## Service summary
{1-paragraph description}

## Top 5 threats (likelihood × impact)
1. ...

## STRIDE table
| Threat | Likelihood | Impact | Scenario | Control |
|--------|-----------|--------|----------|---------|

## Bank-specific threat families
[same table shape]

## Out-of-scope but adjacent
- {one-liners}

## Sources
{linked vault notes, frameworks referenced}
```

Lands at `vault/research/appsec/YYYY-MM-DD-threat-model-{service-slug}.md` (workflow step 6).

## Composes with

- [`secure-design-reviewer`](../secure-design-reviewer/SKILL.md) — natural pair; threat model identifies risks, design review checks if architecture mitigates them.
- [`ai-tooling-data-flow-reviewer`](../ai-tooling-data-flow-reviewer/SKILL.md) — for AI-integration-specific data-flow concerns.
- `vault-querier` — pull related vault notes (existing facts about AI tool data handling, supply-chain attack patterns).
- `vault-writer.write_research` — persists the threat model (workflow step 6).

## Acceptance test (for step 24 done-criteria)

One threat model exercised against a hypothetical service description. Confirm: STRIDE table populated, org-specific families layered on top, top-5 ordered by likelihood × impact, controls mapped (named control or external framework reference).