Claude Skill

threat-modeler

Map the attack surface and build a STRIDE threat model - trust boundaries, data flows, entry points, assets, and prioritized threats with mitigations. Use for /threatmap, architecture security reviews, or "what could go wrong?" planning.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download navinspire-ia-navin-navin_skills_threat-modeler-e9c73a3.zip · 1 KB
Part of navinspire-ia/navin — 182 skills

Install

skills CLI npx skills add https://github.com/Navinspire-ia/navin/tree/main/navin/skills/threat-modeler
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install navinspire-ia-navin@llmmart
Git git clone https://github.com/Navinspire-ia/navin.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole navinspire-ia/navin collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Threat Modeler

Overview

Reason about security at the design level, before (or alongside) code-level scanning. The output is a structured threat model: what we protect, who might attack, how, and what stops them. This is analysis, not exploitation - it feeds the other security skills.

Method

  1. Decompose the system - identify assets (data, credentials, funds, availability), entry points (HTTP routes, queues, file uploads, CLI, webhooks, LLM tool calls), and external dependencies.
  2. Draw trust boundaries - where data crosses from untrusted to trusted (client→server, internet→internal, tenant→tenant, user→agent-tool). Every boundary is a review point.
  3. Trace data flows - for each entry point, follow user-controlled data to where it is stored, executed, or reflected.
  4. Apply STRIDE per element:
    • Spoofing - identity/authentication weaknesses
    • Tampering - integrity of data in transit/at rest
    • Repudiation - missing audit trails
    • Information disclosure - leaks, verbose errors, over-broad responses
    • Denial of service - unbounded work, missing rate limits
    • Elevation of privilege - authz gaps, IDOR, sandbox escape
  5. Rate each threat by likelihood × impact (or DREAD) and attach a concrete mitigation and the owning component.

Deliverable

  • An asset & entry-point inventory.
  • A trust-boundary map (describe or render a Mermaid data-flow diagram).
  • A ranked threat table: ID | STRIDE | element | threat | likelihood | impact | mitigation.
  • The top attack paths worth deeper testing - hand these to /probe or /redteam.

Notes

  • For multi-tenant SaaS, treat tenant isolation as a first-class boundary (row-level scoping, per-tenant keys).
  • For LLM agents, model prompt injection, tool-permission scope, and data exfiltration via tools as explicit threats.
  • Keep it grounded in this system's real components - no generic checklists.
Files (navin)
  • SKILL.md 2.2 KB
    ---
    name: threat-modeler
    description: Map the attack surface and build a STRIDE threat model - trust boundaries, data flows, entry points, assets, and prioritized threats with mitigations. Use for /threatmap, architecture security reviews, or "what could go wrong?" planning.
    metadata: {"navin":{"emoji":"🗺️","category":"security"}}
    ---
    
    # Threat Modeler
    
    ## Overview
    
    Reason about security at the design level, before (or alongside) code-level scanning. The output is a structured threat model: what we protect, who might attack, how, and what stops them. This is analysis, not exploitation - it feeds the other security skills.
    
    ## Method
    
    1. **Decompose the system** - identify assets (data, credentials, funds, availability), entry points (HTTP routes, queues, file uploads, CLI, webhooks, LLM tool calls), and external dependencies.
    2. **Draw trust boundaries** - where data crosses from untrusted to trusted (client→server, internet→internal, tenant→tenant, user→agent-tool). Every boundary is a review point.
    3. **Trace data flows** - for each entry point, follow user-controlled data to where it is stored, executed, or reflected.
    4. **Apply STRIDE** per element:
       - **S**poofing - identity/authentication weaknesses
       - **T**ampering - integrity of data in transit/at rest
       - **R**epudiation - missing audit trails
       - **I**nformation disclosure - leaks, verbose errors, over-broad responses
       - **D**enial of service - unbounded work, missing rate limits
       - **E**levation of privilege - authz gaps, IDOR, sandbox escape
    5. **Rate** each threat by likelihood × impact (or DREAD) and attach a concrete mitigation and the owning component.
    
    ## Deliverable
    
    - An asset & entry-point inventory.
    - A trust-boundary map (describe or render a Mermaid data-flow diagram).
    - A ranked threat table: `ID | STRIDE | element | threat | likelihood | impact | mitigation`.
    - The top attack paths worth deeper testing - hand these to `/probe` or `/redteam`.
    
    ## Notes
    
    - For multi-tenant SaaS, treat tenant isolation as a first-class boundary (row-level scoping, per-tenant keys).
    - For LLM agents, model prompt injection, tool-permission scope, and data exfiltration via tools as explicit threats.
    - Keep it grounded in this system's real components - no generic checklists.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related