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).

The four questions

Adam Shostack's framing — every threat model answers these four: