Threat modeling methodology and risk assessment process. Use when designing new features, reviewing architecture for security, performing STRIDE analysis, creating attack trees, or assessing risk with CVSS/DREAD. Also use when authentication/authorization is added, data flows cross trust boundaries, third-party integrations are introduced, sensitive data handling changes, or analyzing security incidents. Essential for data flow diagrams and security design reviews.
Threat modeling finds security issues before code is written. This skill guides systematic identification of threats through structured analysis—because finding vulnerabilities in design is 100x cheaper than finding them in production.
Core principle: Think like an attacker, document like an engineer. Threat modeling isn't about paranoia—it's about systematic analysis of what could go wrong.
Before identifying threats:
Define Scope
Create Data Flow Diagram
Identify Assets
Systematically find threats:
Apply STRIDE to Each Component
Consider Attack Paths
Document Assumptions
Then address what matters:
Score Risks
Identify Mitigations
Track to Resolution
Apply to each component in your data flow diagram:
| Threat | Property Violated | Questions to Ask |
|---|---|---|
| Spoofing | Authentication | Can someone pretend to be someone else? |
| Tampering | Integrity | Can data be modified without detection? |
| Repudiation | Non-repudiation | Can someone deny they did something? |
| Information Disclosure | Confidentiality | Can sensitive data leak? |
| Denial of Service | Availability | Can the system be made unavailable? |
| Elevation of Privilege | Authorization | Can someone gain unauthorized access? |
❌ CRITICAL: No authentication between services
"Internal services trust each other"
→ Lateral movement after any compromise
❌ CRITICAL: Secrets in code or config
"API keys are in the codebase"
→ Anyone with repo access has keys
❌ HIGH: No input validation at trust boundary
"We trust data from the mobile app"
→ Mobile app can be reverse-engineered
❌ HIGH: Logging sensitive data
"We log requests for debugging"
→ Logs become attack target
❌ MEDIUM: No rate limiting
"We don't expect much traffic"
→ Brute force attacks enabled
❌ CRITICAL: Sensitive data over unencrypted channel
"It's internal network only"
→ Insiders can sniff traffic
❌ HIGH: No encryption at rest for PII
"Database is behind firewall"
→ Backup tapes, logs, replicas exposed
❌ HIGH: Cross-origin data access
"Frontend needs to call multiple APIs"
→ CORS misconfiguration risks
❌ MEDIUM: Storing more data than needed
"We might need it later"
→ Larger attack surface, compliance risk
| Excuse | Reality |
|---|---|
| "It's behind the firewall" | Firewalls get bypassed. Defense in depth. |
| "Only admins have access" | Admin credentials get stolen. Limit blast radius. |
| "We trust our employees" | Insider threat is real. Verify, don't trust. |
| "It's low priority data" | Low-priority breaches make news too. Protect it. |
| "We'll add security later" | Security debt compounds. Build it in. |
| "No one would attack us" | Automated attacks don't discriminate. |
Before finalizing threat model:
Scope:
Analysis:
Prioritization:
Tracking:
## STRIDE Analysis: [Component Name]
**Component Description:** [What it does]
**Data Handled:** [What data flows through it]
**Trust Level:** [Who can access it]
### Spoofing
- **Threat:** [Description]
- **Likelihood:** [Low/Medium/High]
- **Impact:** [Low/Medium/High]
- **Mitigation:** [How to prevent]
### Tampering
- **Threat:** [Description]
- **Mitigation:** [How to prevent]
[Continue for R, I, D, E...]
| Factor | 1 (Low) | 2 (Medium) | 3 (High) |
|---|---|---|---|
| Damage | Minor inconvenience | Service disruption | Data breach |
| Reproducibility | Complex conditions | Sometimes works | Reliable exploit |
| Exploitability | Expert knowledge | Some skill needed | Script kiddie |
| Affected Users | Single user | Subset of users | All users |
| Discoverability | Requires insider | Can find by probing | Publicly known |
Score: (D + R + E + A + D) / 5
**As a** [malicious actor type],
**I want to** [malicious action],
**So that** [attacker's goal].
**Attack Vector:** [How they would do it]
**Prerequisites:** [What they need]
**Impact:** [What happens if successful]
Example:
As a external attacker, I want to inject SQL into the login form, So that I can dump the user database.
Attack Vector: Submit
' OR '1'='1in username field Prerequisites: Knowledge of SQL injection, access to login page Impact: Full database compromise, credential theft
┌─────────────┐
│ Process │ ○ Application logic (trust boundary)
└─────────────┘
╔═════════════╗
║ Data Store ║ ═ Database, file system
╚═════════════╝
┌ ─ ─ ─ ─ ─ ─ ┐
External │ □ User, third-party system
│ Entity
└ ─ ─ ─ ─ ─ ─ ┘
───────► → Data flow (label with data type)
┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ Trust boundary (networks, privilege levels)
# Generate diagram from code
# (Use draw.io, Mermaid, or Threat Dragon)
# Automated threat analysis
pip install pytm # Python threat modeling
threatspec # Threat modeling as code
# Track findings
# Create issues in your tracker with:
# - Threat description
# - DREAD score
# - Mitigation plan
# - Owner
# - Target date
Detailed patterns and examples in references/:
stride-examples.md - STRIDE analysis walkthroughsattack-patterns.md - Common attack patterns by componentmitigation-catalog.md - Standard mitigations for common threats