Threat

Deep threat modeling workflow—system decomposition, trust boundaries, STRIDE-style threats, mitigations, prioritization, and tracking. Use when designing new...

Security Scan

The skill is an instruction-only threat-modeling facilitator whose requirements and instructions align with its stated purpose and do not request elevated access or external installs.

Purpose & Capability

Name/description match the SKILL.md content. The workflow covers system decomposition, trust boundaries, STRIDE threats, mitigations, prioritization and tracking — all coherent with the stated purpose. No unrelated capabilities (cloud creds, CI tokens, etc.) are requested.

Instruction Scope

SKILL.md is a guidance document for running threat-model workshops and producing artifacts. It does not instruct the agent to read files, access environment variables, call external endpoints, or collect secrets. Prompts and outputs are limited to threat-modeling artifacts and facilitation.

Install Mechanism

No install spec and no code files — instruction-only. This minimizes disk writes and reduces supply-chain risk.

Credentials

No required environment variables, credentials, or config paths are declared. The guidance discusses assets and sensitive data conceptually but does not request or demand secrets or unrelated credentials.

Persistence & Privilege

always is false and model invocation is permitted (default). The skill does not request persistent presence or to modify other skills or system-wide settings.

Assessment

This skill is a high-level facilitator for threat-modeling workshops and is internally consistent with that purpose. Because it is instruction-only (no installs or required secrets), it has a low technical footprint. Before using it: avoid pasting real secrets (API keys, private keys, or PII) into the chat or outputs; confirm any artifacts the agent generates are stored according to your team policy; and prefer explicit, on-demand invocation rather than long-running or automated runs if you want tighter control over what project information the agent can access. If you need the agent to integrate with ticketing or issue trackers, review those integration steps separately for required credentials and scope.

Threat Modeling (Deep Workflow)

Threat modeling turns architecture into attack scenarios and mitigations before code hardens incorrectly. It is team-facing—security is a collaborative exercise, not a gate at the end.

When to Offer This Workflow

Trigger conditions:

• New service, major data flow change, public API, partner integration
• Compliance asks for “threat model” artifact
• Post-incident “how do we prevent class of issues”

Initial offer:

Use six stages: (1) scope & assets, (2) diagram & trust boundaries, (3) threats (STRIDE), (4) mitigations & controls, (5) prioritize & owners, (6) validate & iterate. Confirm time box (1–2 hour workshop vs async).

---

Stage 1: Scope & Assets

Goal: Agree what we model and what we protect.

Questions

1. In scope: apps, infra, data stores, admin tools, CI/CD?
2. Crown jewels: data (PII, keys), money, availability, reputation
3. Adversaries: script kiddies, malicious insiders, nation-state (usually pick realistic tiers)

Output

Scope paragraph + asset list with sensitivity.

Exit condition: Shared understanding of what hurts if lost.

---

Stage 2: Diagram & Trust Boundaries

Goal: Visual model with boundaries where trust changes.

Practices

• DFD-ish diagram: external actors, services, data stores, queues
• Mark trust boundaries: internet boundary, partner VPC, employee laptop, CI system
• Note auth mechanisms crossing boundaries (mTLS, JWT, API keys)

Pitfalls

• Missing CI/CD and admin paths—attackers love them
• Over-detailed diagram—keep level consistent

Exit condition: Diagram everyone in the room recognizes as their system.

---

Stage 3: Threats (STRIDE)

Goal: Systematic brainstorm—not exhaustive fantasy.

STRIDE prompts

• Spoofing: impersonation of user/service
• Tampering: data/code/config changed in transit or at rest
• Repudiation: actions not attributable—audit gaps
• Information disclosure: leaks to unauthorized
• Denial of service: resource exhaustion, dependency attacks
• Elevation of privilege: user becomes admin, lateral movement

Technique

• Walk each boundary + each asset with STRIDE columns—rapid ideation, defer judgment
• Capture threats as short scenarios: “Attacker with leaked API key calls admin endpoint”

Exit condition: Threat list with assumptions stated (e.g., “requires MITM”).

---

Stage 4: Mitigations & Controls

Goal: Map threats to controls—prevent, detect, respond.

Control types

• Prevent: authZ checks, input validation, encryption
• Detect: logging, alerts, IDS, anomaly detection
• Respond: kill switches, incident playbooks

Avoid

• Control theater—checkbox without real enforcement

Exit condition: Each high threat has at least one planned control or accepted risk with owner.

---

Stage 5: Prioritize & Owners

Goal: Ruthless prioritization—fix what matters.

Factors

• Impact × likelihood (even qualitative MoSCoW)
• Ease of exploitation vs cost to fix

Tracking

• Tickets per mitigation; link to threat ID
• Residual risk explicitly accepted by appropriate authority when not fixed

Exit condition: Roadmap of mitigations with dates.

---

Stage 6: Validate & Iterate

Goal: Model ages—revisit on major changes.

Triggers for refresh

• New data flow, new integration, auth redesign
• Pen test findings that contradict assumptions

Light validation

• Red team scenarios for top threats if mature org

---

Final Review Checklist

• Assets and scope agreed
• Trust boundaries diagram current
• STRIDE pass completed for boundaries
• Mitigations mapped; owners assigned
• Residual risk explicit where unmitigated

Tips for Effective Guidance

• Facilitate, don’t lecture—engineers own the system facts.
• Prefer scenarios over abstract “Tampering risk.”
• Link to requirements (“every admin action audited”) for traceability.

Handling Deviations

• No time workshop: async diagram + STRIDE spreadsheet review.
• Tiny feature: mini threat model—still document trust boundary with external API.