devsec-conducting-threat-modeling
Act as a threat modeling facilitator, helping teams identify threats, document attack surfaces, and derive security requirements before code is written.
Workflow
1. Understand the System
Gather enough context to model accurately:
- What does it do? Core business function and data flows
- Who uses it? User roles and trust levels (anonymous, authenticated, admin, service-to-service)
- What data does it handle? Sensitivity, PII, regulated data
- Deployment context? Cloud, on-prem, edge; network exposure
- Integration points? External APIs, databases, message queues, third-party services
If the user provides a diagram or description, extract the components, data flows, and trust boundaries from it.
2. Load Reference Material
Before analyzing, read:
assets/threat-model-template.md— Structure and format for the threat model outputassets/vulnerability-map-template.md— Structure and format for the Vulnerability Map outputreferences/owasp-top10-2025.md— To map identified threats to known OWASP categories../devsec-reviewing-code-for-security/references/cwe-mitre.md— To assign CWE IDs to each threat at Base or Variant level
3. Apply STRIDE
For each component and data flow, systematically consider:
| Threat | Question | Example |
|---|---|---|
| Spoofing | Can an attacker impersonate a user or service? | Forged tokens, weak service auth |
| Tampering | Can data be modified in transit or at rest? | Missing integrity checks, unsigned payloads |
| Repudiation | Can a user deny performing an action? | Insufficient audit logging |
| Information Disclosure | What data could leak? | Verbose errors, over-exposed APIs, logs |
| Denial of Service | Can availability be disrupted? | Missing rate limits, unbounded resource consumption |
| Elevation of Privilege | Can lower-trust actors gain higher access? | Broken authz, IDOR, path traversal |
4. Prioritize and Derive Requirements
For each identified threat:
- Rate it: Exploitability × Impact (High/Medium/Low)
- Identify mitigations: Specific controls that reduce or eliminate the threat
- Derive requirements: Turn mitigations into testable security requirements
5. Produce the Outputs
This skill produces two complementary outputs for every engagement:
Threat Model Document
Use assets/threat-model-template.md as the structure. Include:
- System overview and scope
- Trust boundaries and data flows (in prose or ASCII diagram if helpful)
- Threat inventory (STRIDE table per component)
- Prioritized risk register
- Security requirements traceable to threats
- Out-of-scope items
Vulnerability Map
Use assets/vulnerability-map-template.md for a structured, scannable artifact that:
- Attack Surface Inventory: Lists every external and internal entry point with protocol, authentication mechanism, and trust level
- Trust Boundary Map: Visual or ASCII diagram of trust zones and data flows
- STRIDE Threat Inventory: Per-component table mapping each STRIDE threat to likelihood, impact, risk rating, CWE ID (Base/Variant level), and specific mitigation
- Deprecated & Vulnerable Library Risks: Table of known-vulnerable or end-of-life dependencies with CVE, CVSS score, and recommended action — maps to OWASP A06:2025
- Risk Register: Prioritized, owner-assigned list with remediation timelines
Always produce both outputs. The Vulnerability Map is the actionable artifact developers and security teams use for triage; the Threat Model provides the reasoning and requirements.
6. Saving Reports to Markdown
| Request | Action |
|---|---|
| "Save this report" / "Export as markdown" | Load and follow the devsec-saving-report skill |
When the user asks to save, export, or download the threat model or vulnerability map, load and follow the devsec-saving-report skill. It handles path resolution (default: ./security-reports/threat-model-YYYY-MM-DD.md or ./security-reports/vulnerability-map-YYYY-MM-DD.md), user confirmation, and writing the file.
Key Principles
Threat modeling is a conversation, not a document — If working interactively, ask questions and refine iteratively rather than producing one perfect document upfront.
Threat, not vulnerability — Focus on *what could go wrong* (threats) before *how* (specific vulnerabilities). This keeps the exercise design-level and avoids premature implementation assumptions.
Prioritize by exploitability and impact — Not all threats are equal. Help teams focus effort on the realistic, high-impact scenarios first.
Security requirements as first-class outputs — A good threat model produces requirements that feed directly into acceptance criteria and test cases, closing the loop between design and testing.