ShulkwiSEC PASTA Threat Modeling
You are running a structured threat modeling session. Your goal: systematically identify threats, map the attack surface, and produce concrete, actionable security findings — not a theoretical list, but material an engineer can act on tomorrow.
Use the PASTA framework (7 stages) as your analytical backbone. Frame the session using Adam Shostack's 4 questions as the human-readable narrative. Three core activities drive the work: Component Mapping, Critical Assessment, and Logic Flaw Identification. Produce Mermaid diagrams at key stages so findings are visual and shareable.
CHAIN COMMITMENTS — DECLARE BEFORE STARTING
Read this before executing any workflow phase. Commit to MANDATORY chains before your first tool call.
| Trigger | Chain | Mandatory? | Claude Code | opencode |
|---|---|---|---|---|
| After producing the threat model | /remediate |
MANDATORY | Skill(skill="remediate") |
cat ~/.config/opencode/commands/remediate.md |
| After producing the threat model (if findings.json exists) | /gh-export |
OPTIONAL | Skill(skill="gh-export") |
cat ~/.config/opencode/commands/gh-export.md |
You WILL invoke /remediate after completing the threat model. This is not optional.
Logging: Before invoking any skill above, call session(action="set_skill", options={"skill":"<name>","reason":"<why>","chained_from":"<this-skill>"}) — this writes the SKILL_CHAIN entry to pentest.log.
Shostack's 4 Questions — The Session Frame
Answer these four questions across the full session. They're not sequential steps; they're a lens. Keep coming back to them.
| # | Question | What it forces |
|---|---|---|
| 1 | What are we working on? | Shared mental model: scope, components, data flows |
| 2 | What can go wrong? | Threat identification across STRIDE, business logic, misuse cases |
| 3 | What are we going to do about it? | Concrete mitigations and design changes — nothing abstract |
| 4 | Did we do a good job? | Retrospective: coverage, depth, actionability, business alignment |
If you're missing information to answer Q1, ask before proceeding. A threat model built on wrong assumptions is worse than none.
Q1 + Q2 must be written as prose. After completing all PASTA stages, write one focused paragraph answering Q1 ("What are we working on?") and one answering Q2 ("What can go wrong?") as a standalone executive summary section. These paragraphs are for stakeholders who will not read the full report — make them self-contained and concrete.
Three Core Activities
These activities map to the PASTA stages below. Always perform all three — they find different threat classes.
Activity 1 — Component Mapping
Purpose: Build the shared mental model. You can't protect what you haven't named.
Document every component, data flow, and external integration in the application:
- What processes exist and what do they do?
- What data stores are used and what do they hold?
- What external systems does the application talk to?
- Where does sensitive data flow — and where does it rest?
→ Produces the Component Map and Data Flow Diagram (Stage 3)
Activity 2 — Critical Assessment
Purpose: Focus your energy where compromise would hurt most.
After mapping, assess and rank by business criticality:
- Which components, if compromised, would cause the greatest damage? (data breach, financial loss, regulatory penalty, reputational harm)
- Which flows carry the most sensitive or business-critical data?
- Where are single points of failure?
- Which threats should be fixed this sprint vs. tracked vs. accepted?
→ Informs threat prioritization in the Risk Register (Stage 7)
Activity 3 — Logic Flaw Identification
Purpose: Find the vulnerabilities STRIDE misses. Standard scanners won't catch these.
Think like an attacker targeting the application's intended behavior:
- Can a workflow be completed out of order or skipped?
- Can numeric values be manipulated (negative quantities, integer overflow, price tampering)?
- Are state transitions enforced server-side, or only in the UI?
- Can a low-privilege user access higher-privilege functionality through parameter changes?
- Are there race conditions in multi-step or multi-user flows (TOCTOU)?
- Can the same action be triggered multiple times (double-spend, replay)?
- What happens at edge cases in business rules (zero values, boundary inputs)?
→ Produces the Business Logic Flaws section (Stage 5)
PASTA Stage Workflow
Work through all stages in order. Each builds on the previous.
Stage 0 — Codebase Scan (mandatory if source directories are provided)
Before drawing any diagram or identifying any threat, read the code. A threat model built on a description alone misses the real attack surface. If the user provides one or more source directories:
- Glob for key file types:
**/*.{kt,java,py,ts,js,go,yaml,yml,properties,env,tf,json} - Prioritise reading: controllers/routes, security config, auth/auth middleware, background jobs, environment/config files (all profiles — dev, staging, prod), external API integrations, data models
- Note and carry forward: every external service called, every place credentials or secrets are handled, every place user input touches storage or an external API, any config value that differs between environments (e.g.
useSSL=falsein production)
Do not proceed to Stage 1 until this scan is complete. Evidence from code always overrides assumptions from description.
Stage 1 — Define Business Objectives (Shostack Q1)
Before touching architecture, capture business context:
- Business purpose: What does this application/feature do for the business?
- Assets to protect: Data confidentiality, integrity, availability, reputation — what matters most?
- Compliance constraints: GDPR, PCI-DSS, HIPAA, SOC2, ISO 27001, etc.
- Risk appetite: What level of residual risk is acceptable to the business?
Output: A 3–5 bullet objectives statement. Ask the user for missing context before proceeding.
Stage 2 — Define Technical Scope
Establish what is in and out of scope:
- Technologies, languages, frameworks, cloud providers
- Deployment model: on-prem / cloud / hybrid / serverless / containers / mobile
- External integrations and third-party dependencies
- Authentication and authorization mechanisms (SSO, OAuth, API keys, etc.)
Output: Scope boundary statement + component inventory table:
| Component | Type | Technology | In Scope? |
|---|---|---|---|
| API Gateway | Process | AWS API GW | Yes |
| User DB | Data Store | PostgreSQL | Yes |
| Payment Processor | External | Stripe API | Partial |
Stage 3 — Application Decomposition (Activity 1: Component Mapping)
This is the most important visual stage. Decompose the application and model data flows. If you're unsure where to start, draw the component map first — threats become obvious once the architecture is visual.
3a. Component Map — All components and their connections:
flowchart TD
User["👤 User (Browser)"]
CDN["CDN / WAF"]
API["API Server"]
Auth["Auth Service (OAuth2)"]
DB["Primary Database"]
Cache["Redis Cache"]
Queue["Message Queue"]
Worker["Background Worker"]
ExtPay["💳 Payment Provider (External)"]
ExtEmail["✉️ Email Provider (External)"]
User -->|HTTPS| CDN
CDN -->|HTTPS| API
API -->|JWT validation| Auth
API -->|SQL| DB
API -->|Read/Write| Cache
API -->|Publish| Queue
Queue -->|Consume| Worker
Worker -->|SQL| DB
API -->|REST/TLS| ExtPay
Worker -->|SMTP/TLS| ExtEmail
style ExtPay fill:#ffd,stroke:#aa0
style ExtEmail fill:#ffd,stroke:#aa0
style User fill:#ddf,stroke:#44a
3b. Data Flow Diagram (DFD) — Where sensitive data travels and which trust zones it crosses:
flowchart LR
subgraph External["External Zone"]
U["User"]
P["Payment API"]
end
subgraph DMZ["DMZ"]
WAF["WAF / CDN"]
end
subgraph AppZone["Application Zone"]
API["API Server"]
Auth["Auth Service"]
end
subgraph DataZone["Data Zone"]
DB[("Database")]
Secrets["Secrets Manager"]
end
U -- "PII, credentials\n[HTTPS]" --> WAF
WAF -- "Sanitized request\n[HTTPS]" --> API
API -- "Credential check\n[mTLS]" --> Auth
API -- "Card data\n[TLS 1.3]" --> P
API -- "User records\n[encrypted]" --> DB
API -- "API keys\n[TLS]" --> Secrets
3c. Trust Boundaries — Annotate every point where data crosses a trust zone. Each boundary is a potential attack surface. Common boundaries:
- External → DMZ (user-facing entry points)
- DMZ → Application (de-perimeterization risk)
- Application → Data (privilege and access control)
- Application → External APIs (third-party trust)
Stage 4 — Threat Analysis (Shostack Q2 + Activity 2: Critical Assessment)
Apply STRIDE to every component and data flow from Stage 3. For each component, reason through all six threat categories:
| STRIDE | Threat Type | Ask yourself... |
|---|---|---|
| Spoofing | Identity impersonation | Can an attacker pretend to be a legitimate user or service? |
| Tampering | Data modification | Can data be altered in transit or at rest? |
| Repudiation | Deny actions | Can users deny having taken an action? Are audit logs sufficient? |
| Information Disclosure | Data leakage | What sensitive data could be exposed unintentionally? |
| Denial of Service | Availability | What could an attacker exhaust to make the service unavailable? |
| Elevation of Privilege | Access escalation | Can a low-privilege user gain higher privileges? |
Threat Table — one row per threat:
| ID | Component | STRIDE | Threat Description | Likelihood | Impact | Risk |
|---|---|---|---|---|---|---|
| T-01 | API Server | S | Attacker replays stolen JWT to impersonate another user | Medium | High | High |
| T-02 | Database | I | SQL injection via unsanitized input exposes PII | Low | Critical | High |
| T-03 | Auth Service | E | Privilege escalation via misconfigured RBAC | Low | Critical | High |
Risk scoring: Critical / High / Medium / Low (Likelihood × Impact). After populating the table, apply Activity 2 — identify which threats sit on the most business-critical components and flag them for priority treatment.
After completing the STRIDE table, run the completeness check before moving to Stage 5:
- Every T-XX must have a corresponding RTM row. List the T-IDs and verify one-to-one coverage.
- If any T-XX is missing from the RTM, add it before proceeding. Never leave this to the human to catch.
Stage 5 — Vulnerability & Logic Flaw Analysis (Activity 3: Logic Flaws Identification)
5a. Map to weakness classes — Connect High/Critical threats to CWE IDs. Flag known CVEs if specific library versions are in scope.
5b. Business Logic Flaw Review — Work through this checklist against every user-facing flow:
- Can the flow be started, resumed, or completed out of order?
- Can numeric values be set to negative, zero, maximum, or overflow values?
- Are state transitions enforced server-side (not just in the frontend)?
- Can a lower-privileged role access higher-privilege functionality via API parameter changes?
- Are all external inputs validated — including HTTP headers, query params, and cookies?
- Can a successful action be replayed or triggered multiple times?
- Are there race conditions in concurrent or multi-step workflows?
- What happens when a multi-step flow is abandoned mid-way?
For each flow involving money, access control, or multi-step workflows, spend dedicated time here — standard STRIDE analysis reliably misses these.
Stage 6 — Attack Modeling
Build attack trees for the top 2–3 highest-risk threats. Trees show how an attacker chains steps to achieve a goal — they make chained-attack paths visible in ways flat threat tables don't.
Example: "Unauthorized Database Access"
flowchart TD
Goal["🎯 Goal: Access PII in Database"]
A1["Exploit SQL injection"]
A2["Steal valid session token"]
A3["Compromise internal service"]
A1a["Find unsanitized input\n(search, filter, sort params)"]
A1b["Craft malicious SQL payload"]
A1c["Extract data via UNION / error"]
A2a["Phish user credentials"]
A2b["Sniff unencrypted traffic"]
A2c["Brute-force weak password"]
A3a["Exploit misconfigured cloud storage"]
A3b["SSRF via API endpoint"]
Goal --> A1
Goal --> A2
Goal --> A3
A1 --> A1a --> A1b --> A1c
A2 --> A2a
A2 --> A2b
A2 --> A2c
A3 --> A3a
A3 --> A3b
style Goal fill:#f88,stroke:#a00
style A1 fill:#fcc,stroke:#c44
style A2 fill:#fcc,stroke:#c44
style A3 fill:#fcc,stroke:#c44
Produce one attack tree per major High/Critical risk. Focus on paths that are realistic given your component map.
Stage 7 — Risk & Traceability Matrix (RTM) + Mitigations (Shostack Q3)
7a. RTM — fixed column format, always
The RTM is always a single flat table with exactly these columns — no exceptions, no individual cards:
| ID | Component | Use Case | Abuse Case | How to Test | Vulnerable | Severity | GH Issue |
|---|---|---|---|---|---|---|---|
| RTM-01 | API Server | User authenticates via JWT | Attacker replays stolen JWT to impersonate another user | 1. Capture a valid JWT. 2. Replay after logout. 3. Verify token is invalidated. | Likely — no token binding visible | High | — |
Rules:
- Every T-XX from Stage 4 must appear as an RTM row. Run the completeness check: list all T-IDs, confirm each has an RTM row. Fail loudly if any are missing.
- Every business logic flaw from Stage 5 must appear as an RTM row. These get their own RTM IDs (they don't correspond to a T-XX).
- Every open/unresolved question with a security consequence must appear as an RTM row. Assign severity as worst-case-if-unanswered. These rows must also appear in Section 9 (Open Questions). Mark them visually distinct in HTML (e.g. blue row background).
- GH Issue column is always blank (
—). It is reserved for manual back-linking after GitHub issues are created. Never populate it automatically. - Sort by Severity (Critical first), then business impact.
- Include a STRIDE→RTM mapping note below the table so traceability is explicit.
7b. Mitigation Tiers
For each High/Critical risk, provide three horizons:
- Immediate action — fix within current sprint / hotfix
- Short-term control — fix within next release cycle
- Long-term hardening — architectural improvement
Example:
- RTM-02 SQL Injection
- Immediate: Parameterized queries on all DB calls; enable WAF in block mode
- Short-term: Integrate SAST (e.g., Semgrep, CodeQL) into CI pipeline
- Long-term: Migrate to ORM with query builder that prevents raw SQL
Retrospective: Did We Do a Good Job? (Shostack Q4)
After completing all stages, check these four criteria honestly:
- Coverage — Every component and data flow from Stage 3 was analyzed for threats
- Depth — We went beyond obvious STRIDE threats to find logic flaws and chained attacks
- Actionability — Mitigations are specific enough for an engineer to implement without further research
- Business alignment — The highest-risk items map to the most business-critical components
If any check fails, call it out explicitly and note it as a follow-up action item.
Output Structure
Always produce two files in the project directory (use a threat-model/ subdirectory if the project root is clear):
File 1: threat-model-[app-name].md
Markdown with all sections:
# Threat Model: [Application Name]
## Executive Summary
### What are we working on? (1 paragraph — Shostack Q1)
### What can go wrong? (1 paragraph — Shostack Q2)
## 1. Objectives & Scope
## 2. Component Map (Mermaid)
## 3. Data Flow Diagram (Mermaid)
## 4. Threat Inventory (STRIDE table)
## 5. Business Logic Flaws
## 6. Attack Trees (Mermaid — top 2–3 threats)
## 7. Risk & Traceability Matrix (RTM) — single flat table: ID | Component | Use Case | Abuse Case | How to Test | Vulnerable | Severity | GH Issue
## 8. Mitigations by Tier
## 9. Open Questions / Dialogue Items (also present as RTM rows)
## 10. Retrospective
File 2: threat-model-[app-name].html
A self-contained styled HTML report. Use this template — inline all CSS/JS so it works without a server:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Threat Model: [App Name]</title>
<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
<style>
:root {
--red: #e53e3e; --orange: #dd6b20; --yellow: #d69e2e; --green: #38a169;
--blue: #3182ce; --purple: #805ad5; --gray: #718096;
--bg: #f7fafc; --card: #ffffff; --border: #e2e8f0;
--text: #1a202c; --muted: #4a5568;
}
* { box-sizing: border-box; margin: 0; padding: 0; }
body { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
background: var(--bg); color: var(--text); line-height: 1.6; }
.header { background: linear-gradient(135deg, #1a202c 0%, #2d3748 100%);
color: white; padding: 3rem 2rem; text-align: center; }
.header h1 { font-size: 2.2rem; font-weight: 700; margin-bottom: .5rem; }
.header .subtitle { color: #a0aec0; font-size: 1rem; }
.header .meta { margin-top: 1rem; display: flex; gap: 1.5rem; justify-content: center;
font-size: .85rem; color: #cbd5e0; flex-wrap: wrap; }
.container { max-width: 1100px; margin: 0 auto; padding: 2rem 1.5rem; }
.toc { background: var(--card); border: 1px solid var(--border); border-radius: 10px;
padding: 1.5rem; margin-bottom: 2rem; }
.toc h2 { font-size: 1rem; text-transform: uppercase; letter-spacing: .05em;
color: var(--muted); margin-bottom: 1rem; }
.toc ol { padding-left: 1.4rem; }
.toc li { margin: .3rem 0; }
.toc a { color: var(--blue); text-decoration: none; }
.toc a:hover { text-decoration: underline; }
.section { background: var(--card); border: 1px solid var(--border); border-radius: 10px;
padding: 2rem; margin-bottom: 1.5rem; }
.section h2 { font-size: 1.4rem; font-weight: 700; margin-bottom: 1.2rem;
padding-bottom: .6rem; border-bottom: 2px solid var(--border); }
.section h3 { font-size: 1.1rem; font-weight: 600; margin: 1.4rem 0 .6rem; color: var(--muted); }
p { margin-bottom: .8rem; }
ul, ol { padding-left: 1.4rem; margin-bottom: .8rem; }
li { margin: .25rem 0; }
table { width: 100%; border-collapse: collapse; margin: 1rem 0; font-size: .9rem; }
th { background: #edf2f7; font-weight: 600; text-align: left; padding: .6rem .8rem;
border: 1px solid var(--border); }
td { padding: .55rem .8rem; border: 1px solid var(--border); vertical-align: top; }
tr:nth-child(even) td { background: #f7fafc; }
.badge { display: inline-block; padding: .2rem .6rem; border-radius: 9999px;
font-size: .75rem; font-weight: 700; text-transform: uppercase; }
.badge-critical { background: #fed7d7; color: #c53030; }
.badge-high { background: #feebc8; color: #c05621; }
.badge-medium { background: #fefcbf; color: #975a16; }
.badge-low { background: #c6f6d5; color: #276749; }
.diagram-wrap { background: #f8f9fa; border: 1px solid var(--border); border-radius: 8px;
padding: 1.5rem; margin: 1rem 0; overflow-x: auto; text-align: center; }
.diagram-label { font-size: .8rem; color: var(--muted); text-align: center;
margin-top: .5rem; font-style: italic; }
.activity-badge { display: inline-block; padding: .15rem .5rem; border-radius: 4px;
font-size: .75rem; font-weight: 700; background: #ebf4ff; color: #2b6cb0;
margin-bottom: .5rem; }
.checklist li { list-style: none; padding-left: 0; }
.checklist li::before { content: "✅ "; }
.checklist li.fail::before { content: "❌ "; }
code { background: #edf2f7; padding: .1rem .35rem; border-radius: 4px;
font-family: 'SF Mono', 'Fira Code', monospace; font-size: .88em; }
pre { background: #2d3748; color: #e2e8f0; padding: 1rem; border-radius: 8px;
overflow-x: auto; margin: .8rem 0; }
pre code { background: none; color: inherit; padding: 0; }
.risk-card { border-left: 4px solid; border-radius: 0 8px 8px 0;
padding: 1rem 1.2rem; margin: .8rem 0; background: var(--card);
box-shadow: 0 1px 3px rgba(0,0,0,.05); }
.risk-card.critical { border-color: var(--red); }
.risk-card.high { border-color: var(--orange); }
.risk-card.medium { border-color: var(--yellow); }
.risk-card.low { border-color: var(--green); }
.risk-card h4 { font-size: .95rem; font-weight: 600; margin-bottom: .4rem; }
.risk-card p { font-size: .88rem; color: var(--muted); margin: 0; }
footer { text-align: center; color: var(--muted); font-size: .8rem; padding: 2rem; }
</style>
</head>
<body>
<div class="header">
<h1>🛡️ Threat Model: [APP NAME]</h1>
<div class="subtitle">PASTA Framework · Shostack 4-Question Method</div>
<div class="meta">
<span>📅 [DATE]</span>
<span>🔍 [SCOPE]</span>
<span>⚠️ [N] High/Critical Findings</span>
</div>
</div>
<div class="container">
<div class="toc">
<h2>Table of Contents</h2>
<ol>
<li><a href="#executive">Executive Summary</a></li>
<li><a href="#objectives">Objectives & Scope</a></li>
<li><a href="#components">Component Map</a></li>
<li><a href="#dfd">Data Flow Diagram</a></li>
<li><a href="#threats">Threat Inventory (STRIDE)</a></li>
<li><a href="#logic">Business Logic Flaws</a></li>
<li><a href="#attack-trees">Attack Trees</a></li>
<li><a href="#rtm">Risk & Traceability Matrix (RTM)</a></li>
<li><a href="#mitigations">Mitigations by Tier</a></li>
<li><a href="#dialogue">Open Questions / Dialogue Items</a></li>
<li><a href="#retro">Retrospective</a></li>
</ol>
</div>
<div class="section" id="executive">
<h2>Executive Summary</h2>
<h3>What are we working on?</h3>
<p><!-- [ONE PARAGRAPH — Shostack Q1: describe the system, its purpose, key data flows, and deployment context in plain language for a stakeholder who won't read the full report] --></p>
<h3>What can go wrong?</h3>
<p><!-- [ONE PARAGRAPH — Shostack Q2: summarise the most significant threat themes, highest-severity findings, and key unknowns. Be concrete — name components and data types.] --></p>
</div>
<div class="section" id="objectives">
<h2>1. Objectives & Scope</h2>
<!-- [CONTENT] -->
</div>
<div class="section" id="components">
<h2>2. Component Map</h2>
<div class="activity-badge">Activity 1: Component Mapping</div>
<div class="diagram-wrap">
<div class="mermaid">
[COMPONENT MAP MERMAID]
</div>
</div>
<div class="diagram-label">Figure 1 — Application Component Map</div>
</div>
<div class="section" id="dfd">
<h2>3. Data Flow Diagram</h2>
<div class="activity-badge">Activity 1: Component Mapping</div>
<div class="diagram-wrap">
<div class="mermaid">
[DFD MERMAID]
</div>
</div>
<div class="diagram-label">Figure 2 — Data Flow with Trust Boundaries</div>
</div>
<div class="section" id="threats">
<h2>4. Threat Inventory (STRIDE)</h2>
<div class="activity-badge">Activity 2: Critical Assessment</div>
<table>
<thead>
<tr><th>ID</th><th>Component</th><th>STRIDE</th><th>Threat</th><th>Likelihood</th><th>Impact</th><th>Risk</th></tr>
</thead>
<tbody>
<!-- rows: <span class="badge badge-high">High</span> for risk cells -->
</tbody>
</table>
</div>
<div class="section" id="logic">
<h2>5. Business Logic Flaws</h2>
<div class="activity-badge">Activity 3: Logic Flaws Identification</div>
<!-- [CONTENT] -->
</div>
<div class="section" id="attack-trees">
<h2>6. Attack Trees</h2>
<!-- one diagram-wrap per tree -->
</div>
<div class="section" id="rtm">
<h2>7. Risk & Traceability Matrix (RTM)</h2>
<div class="activity-badge">Activity 2: Critical Assessment</div>
<p style="font-size:.85rem;color:#4a5568;margin-bottom:.8rem;">
<!-- [N] entries total: [N] STRIDE threats + [N] business logic findings + [N] open questions (blue rows).
STRIDE mapping: T-01→RTM-XX, ... GH Issue column is blank — fill in manually after creating issues. -->
</p>
<table>
<thead>
<tr>
<th>ID</th><th>Component</th><th>Use Case</th><th>Abuse Case</th>
<th>How to Test</th><th>Vulnerable</th><th>Severity</th><th>GH Issue</th>
</tr>
</thead>
<tbody>
<!-- RULE: every T-XX from STRIDE table must have a row here. Every business logic flaw must have a row.
Every open question with security consequence must have a row (style="background:#ebf8ff;").
Sort: Critical first, then High, Medium, Low. GH Issue always "—". -->
</tbody>
</table>
</div>
<div class="section" id="mitigations">
<h2>8. Mitigations by Tier</h2>
<!-- tier-immediate: fix this sprint. tier-short: next release. tier-long: architectural. -->
</div>
<div class="section" id="dialogue">
<h2>9. Open Questions / Dialogue Items</h2>
<!-- These items also appear as RTM rows (blue). List them here as numbered questions for the team. -->
</div>
<div class="section" id="retro">
<h2>10. Retrospective</h2>
<ul class="checklist">
<li>Coverage: every component and data flow analyzed for threats</li>
<li>Completeness: every T-XX from STRIDE table has an RTM row</li>
<li>Depth: logic flaws and chained attacks explored beyond STRIDE</li>
<li>Actionability: mitigations specific enough to implement without further research</li>
<li>Business alignment: highest-risk items map to most business-critical components</li>
<li>Open questions resolved (or tracked as RTM rows with worst-case severity)</li>
</ul>
</div>
</div>
<footer>Generated by Claude · PASTA Threat Modeling · Shostack 4-Question Framework</footer>
<script>
mermaid.initialize({ startOnLoad: true, theme: 'neutral',
themeVariables: { fontSize: '14px' } });
</script>
</body>
</html>
Fill in all [CONTENT], [MERMAID], table rows, and risk cards with actual analysis. The only external resource is the Mermaid CDN script.
Risk badge helper: In Risk column cells use <span class="badge badge-critical">Critical</span>, badge-high, badge-medium, badge-low.
Dashboard Integration (when MCP tools are available)
If pentest-agent MCP tools are available (e.g. when chained from /pentester), push data to the live dashboard:
- Call
report(action="diagram", data={...})for the Component Map (Stage 3a) and the Data Flow Diagram (Stage 3b) — this makes them visible in the live dashboard at localhost:7777 - Call
report(action="diagram", data={...})for each Attack Tree (Stage 6) - Optionally call
report(action="finding", data={...})for any High/Critical threats that are concrete enough to be actionable findings (e.g. a specific missing security control on a specific component) - Save the full threat model as
threat-model/threat-model-<app-name>.md— the dashboard Threat Model tab automatically picks up any.mdfile in that folder and lets the user select it from a dropdown.
Skip this if MCP tools are not available (standalone analysis). The markdown + HTML reports are always produced regardless.
Mermaid Syntax Rules
- Always use
flowchart TD(notgraph TD) — required for Mermaid v11 - Quote any node label containing spaces, special characters, or punctuation:
A["Login /api/auth"] - Never use em-dashes or Unicode punctuation inside labels — use plain ASCII
- Keep node IDs short and alphanumeric
Quality Tips
- Be specific: "Data could be leaked" is not actionable. Name the component, the mechanism, and the data.
- Diagrams first: Drawing the component map almost always surfaces threats that weren't obvious from description alone.
- Logic flaws take dedicated effort: Budget time for Activity 3 on every flow involving money, access control, or multi-step workflows. Don't rush it.
- Prioritize ruthlessly: A 50-item threat list with no priorities is useless. Always sort the risk register by business impact.
- Mitigations must be concrete: If an engineer can't implement a mitigation without asking a follow-up question, it's too vague.