Threat Model

Threat Model Skill

Analyze architecture documents, data flows, and code for security threats (STRIDE) and privacy threats (LINDDUN). Produces STIG V-ID-tagged findings with risk scores.

Invocation

• /threat-model — full STRIDE + LINDDUN analysis of project
• /threat-model stride — security threats only
• /threat-model linddun — privacy threats only (GDPR focus)
• /threat-model <file-or-dir> — analyze specific architecture doc or code path

How It Works

1. Discover assets

Find all analyzable assets in the project:

• Architecture docs in docs/architecture/, docs/design/, docs/plans/
• Schema files: convex/schema.ts, database schemas, API definitions
• Authentication/authorization code: OIDC config, auth middleware, ABAC policies
• Data flow code: diode gateways, message publishers/subscribers, API routes
• Infrastructure config: Docker, Kubernetes, NATS, Keycloak configuration

List all discovered assets before analysis. Group them by:

• Trust boundaries (classification levels, network zones, authentication domains)
• Data flows (cross-boundary data movement, message channels)
• Data stores (databases, caches, outbox/inbox tables)
• External interfaces (APIs, OIDC providers, register services)

2. STRIDE analysis (per component/data flow)

For each component and data flow, evaluate all six STRIDE categories:

See references/stride-framework.md for detailed detection questions and mitigations per category.

3. LINDDUN analysis (privacy-focused, for GDPR)

For each data flow involving personal data, evaluate all seven LINDDUN categories:

See references/linddun-framework.md for detailed detection questions and GDPR mappings.

4. Risk scoring

Each identified threat receives a risk score:

• Likelihood (1-5): How likely is exploitation given current controls?

  • 1 = Rare (requires insider + multiple failures)
  • 2 = Unlikely (requires significant effort/access)
  • 3 = Possible (known attack patterns exist)
  • 4 = Likely (low barrier, high motivation)
  • 5 = Almost certain (trivially exploitable)

• Impact (1-5): What is the consequence if exploited?

  • 1 = Negligible (no data loss, brief disruption)
  • 2 = Minor (limited data exposure, recoverable)
  • 3 = Moderate (significant data exposure, operational impact)
  • 4 = Major (classified data breach, extended outage)
  • 5 = Critical (national security impact, complete compromise)

• Risk score = Likelihood x Impact

• CAT mapping from risk score:

  • Risk 15-25: CAT I (critical/high — must remediate before deployment)
  • Risk 8-14: CAT II (medium — fix within maintenance cycle)
  • Risk 1-7: CAT III (low — track and remediate)

• Severity label:

  • Risk 20-25: CRITICAL
  • Risk 15-19: HIGH
  • Risk 8-14: MEDIUM
  • Risk 1-7: LOW

5. Output format

Produce findings as pipeline-compatible JSON:

{
  "tool": "threat-model",
  "framework": "STRIDE+LINDDUN",
  "timestamp": "2026-03-13T10:00:00Z",
  "target": "<analyzed-scope>",
  "findings": [
    {
      "id": "TM-001",
      "framework": "STRIDE",
      "category": "Spoofing",
      "stig_vid": "V-222425",
      "cat": "I",
      "component": "Diode Gateway",
      "threat": "XML envelope spoofing via crafted NATS messages",
      "likelihood": 3,
      "impact": 5,
      "risk_score": 15,
      "severity": "HIGH",
      "mitigations_present": ["HMAC envelope signing"],
      "mitigations_missing": ["Message origin verification", "Replay detection"],
      "recommendation": "Add source authentication and nonce-based replay prevention",
      "code_pointers": ["packages/diode-gateway/src/publisher.ts:42"]
    }
  ],
  "summary": {
    "total_threats": 12,
    "by_framework": {"STRIDE": 8, "LINDDUN": 4},
    "by_cat": {"I": 3, "II": 6, "III": 3},
    "risk_matrix": {"critical": 2, "high": 4, "medium": 4, "low": 2}
  }
}

See references/output-formats.md for full field documentation.

6. Human-readable report

In addition to JSON, produce a markdown threat report using the template at assets/threat-report-template.md. The report includes:

• Executive summary with risk posture overview
• Asset inventory and trust boundary diagram
• STRIDE findings grouped by category with risk scores
• LINDDUN findings grouped by category with GDPR references
• Risk matrix visualization (likelihood x impact)
• Prioritized recommendations
• STIG compliance impact summary

STIG V-ID Mapping Table

See references/stig-threat-mappings.md for the complete mapping with finding patterns.

Integration with /stig-compliance

Output JSON feeds directly into /stig-compliance review as design-level evidence. Findings use the pipeline-compatible format with Source: threat-model (semantic) attribution.

Threat model findings complement tool-based scans from /static-analysis, /sca, /container-security, and /dast by providing architecture-level and design-level threat identification that automated tools cannot detect.

Limitations

• Analysis is semantic (Claude-based) — not a substitute for automated scanning tools
• Risk scores are qualitative assessments, not quantitative measurements
• LINDDUN analysis requires understanding of data processing purposes (may need DPIA input)
• Threat identification is bounded by the architecture documentation available
• Does not replace formal threat modeling workshops with stakeholders