Threat Modeling — Pre-Implementation Security Design

Run a structured threat-modeling session against a proposed feature, system, or architecture. This is the design-time security skill — different from audit (which inspects code that exists). Use this when there's a design doc, a feature spec, an architecture diagram — but not yet code.

When to use:

• New feature touching auth, payments, multi-tenant data, or sensitive PII
• New external integration (third-party API, OAuth provider, webhook receiver)
• New service / microservice being added to the architecture
• Significant refactor of a security-sensitive component
• Before committing to a major architecture decision (event-driven vs request/response, monolith split, AI-feature introduction)

Cross-references: owasp-audit (code-level checklist that lines up with the threats this surfaces), api-audit (API-specific category mapping), iam-audit (identity decisions touch every threat model).

Authorization

Model systems the user owns, builds or is authorized to assess, from designs, diagrams and code they provide. Threat modeling is design analysis; it doesn't test anything. Don't build an attack tree of someone else's product without their authorization.

The four questions