Threat Modeling

Threat Modeling

Core Mindset

Think like an attacker, build like a defender.

Threat modeling is done BEFORE building, not after. Security retrofitted is always weaker and more expensive than security designed in.

---

The STRIDE Framework

For every component, ask: can an attacker do this?

| Threat | Definition | Example | |---|---|---| | Spoofing | Pretend to be someone else | Forged JWT token | | Tampering | Modify data in transit or at rest | SQL injection, request body modification | | Repudiation | Deny performing an action | No audit log of who deleted a record | | Information Disclosure | Access data they shouldn't | Over-fetching API, verbose error messages | | Denial of Service | Make system unavailable | No rate limiting on auth endpoint | | Elevation of Privilege | Gain unauthorized access level | IDOR (accessing other users' data) |

---

Threat Modeling Process

1. DEFINE SCOPE       — What are we modeling? (feature, service, system)
2. IDENTIFY ASSETS    — What are we protecting? (data, services, credentials)
3. DRAW DATA FLOWS    — How does data move through the system?
4. IDENTIFY THREATS   — Apply STRIDE to each component and data flow
5. ASSESS RISK        — Likelihood × Impact for each threat
6. MITIGATE           — For each high-risk threat, define a control
7. VERIFY             — Confirm controls are implemented and working

---

Attack Surface Analysis

For any new feature, identify:

• Entry points — Where does user input enter the system?
• Trust boundaries — Where does data cross privilege levels?
• Data stores — What sensitive data is stored and where?
• External dependencies — What third-party services are called?

---

OWASP Top 10 (Quick Reference)

| # | Threat | Quick Check | |---|---|---| | A01 | Broken Access Control | Is every endpoint checking authorization? | | A02 | Cryptographic Failures | Is sensitive data encrypted at rest and in transit? | | A03 | Injection | Are all queries parameterized? All inputs validated? | | A04 | Insecure Design | Was security considered in the design phase? | | A05 | Security Misconfiguration | Are defaults hardened? Are secrets in env vars? | | A06 | Vulnerable Components | Are dependencies up to date? Any known CVEs? | | A07 | Auth Failures | Is auth implemented correctly? Session management secure? | | A08 | Software Integrity | Are supply chain and build pipeline trusted? | | A09 | Logging Failures | Are security events logged? Are logs protected? | | A10 | SSRF | Can users cause server to make requests to internal resources? |

---

Security Design Principles

• Least Privilege — Every component gets only the permissions it needs
• Defense in Depth — Multiple layers of security, no single point of failure
• Fail Secure — When something breaks, it should fail closed (deny access), not open
• Zero Trust — Never trust, always verify — even internal services
• Minimize Attack Surface — Less exposed = less exploitable

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jamestorrevillas
• Source: jamestorrevillas/dev-skills
• License: MIT

Install and usage instructions live in the source repository linked above.