What this prompt does
This prompt runs a systematic STRIDE analysis across every component you describe in [architecture_description], producing numbered threat IDs, likelihood x impact risk scores, and prioritised mitigations in a single pass. The structure forces the model to touch all six STRIDE categories per component rather than stopping at the obvious spoofing and injection vectors most ad-hoc security reviews miss — repudiation and elevation of privilege are the two categories engineers chronically skip, and the template explicitly calls them out.
The [data_classification] and [compliance] variables do real work here. Feeding in "PII + PCI-DSS" versus "internal metrics + no regulatory requirement" changes which threats get elevated risk scores and which mitigations the model prioritises. The final compliance control mapping section ties every critical finding back to the specific standard you named, giving you an artefact you can drop directly into an audit package.
When to use it
- Designing a new API gateway or microservice boundary before writing a line of code
- Pre-launch security review for a SaaS product handling financial or health data
- Preparing evidence for ISO 27001, SOC 2, or PCI-DSS auditors who require documented threat modelling
- Onboarding a new team member who needs to understand the attack surface of an inherited system
- Responding to a security incident by re-modelling the affected component to find adjacent risks
- Architecture review sessions where you want a structured threat register as a discussion anchor
Example output
Threat ID: T-007
STRIDE Category: Elevation of Privilege
Component: Internal Admin API (/api/v1/admin)
Attack Vector:
1. Attacker obtains a valid user JWT via phishing
2. Sends forged request with manually crafted role claim ("role": "admin")
3. API trusts the claim without server-side role lookup
4. Full admin access granted
Impact: Confidentiality (HIGH), Integrity (HIGH), Availability (LOW)
Likelihood: 4 | Impact: 5 | Risk Score: 20 (CRITICAL)
Mitigation: Validate role claims server-side against the users table on every
request; never trust JWT payload for authorisation decisions. Priority: P0.
Residual Risk: Low (score ~4) after server-side role enforcement.
Pro tips
- Fill
[architecture_description]in DFD terms. List components as nodes ("React SPA → API Gateway → Auth Service → PostgreSQL") with data flows between them. Vague prose produces vague threats. - Set
[top_count]to 5 for boards, 10 for engineering teams. The summary section is the artefact executives actually read; calibrate it to your audience. - Use real compliance shorthand. "PCI-DSS v4.0 Req 6.4" gets you more precise control mapping than "PCI-DSS". The model knows the standard numbers.
- Run it twice for large systems — once per trust boundary (e.g., public-facing tier, internal service mesh). A single monolithic pass over a 10-component architecture dilutes the threat density per component.
- Pair with a follow-up prompt asking for abuse cases. STRIDE covers structural threats; adversarial abuse cases (account takeover flows, scraping attacks) live in the business logic layer and need a separate sweep.
