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-relevant threat catalog (pre-loaded)

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

Plus org-specific threat families layered on STRIDE:

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

# 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 — natural pair; threat model identifies risks, design review checks if architecture mitigates them.
• ai-tooling-data-flow-reviewer — 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).