threat-model

Threat Model

Purpose

Provide a repeatable, evidence-first threat modeling workflow for GitHub Copilot users who need durable Markdown output and Mermaid diagrams, including a fallback path for GitHub Copilot CLI users who cannot call the VS Code Mermaid Chart tools directly.

When to use

Use this skill when you need to:

• threat model a repository, feature, architecture, or PR diff
• prepare a security architecture review with data flows and trust boundaries
• produce a 4Q report with actionable mitigations and a validation plan
• work from GitHub Copilot CLI and still validate Mermaid diagrams before publishing the report

Inputs to collect

• in-scope components, deployables, and entry points
• deployment and reachability assumptions
• privileged roles and high-impact workflows
• sensitive data categories and likely consequence of misuse
• existing controls, especially authn/authz, ingress, logging, and environment isolation
• repository evidence for code paths, IaC, manifests, and configuration

How to use

1. Collect repository evidence before relying on operator answers.

2. Ask only the branching intake questions that materially change exposure, privilege, or data-sensitivity scoring.

3. Draft the report in a root-level file named Threat Model Review - YYYY-MM-DD.md.

4. Use the bundled Mermaid helper scripts when the Mermaid Chart extension tools are unavailable:

   npm run threat-model:mermaid-docs -- --list
   npm run threat-model:mermaid-docs -- --type flowchart
   npm run threat-model:mermaid-docs -- --type sequenceDiagram
   npm run threat-model:mermaid-validate -- --file "Threat Model Review - 2026-04-15.md"
   

5. Fix Mermaid failures and rerun validation until the script exits successfully.

6. Deliver the final report plus a short PR-ready summary.

Rules

• MUST use this evidence hierarchy for factual claims: repo-confirmed, runtime/deployment evidence, operator-stated, ASSUMPTION, UNKNOWN.
• MUST keep confirmed facts separate from inference.
• MUST ask 4-8 concise intake questions when reachability, privileged workflows, data sensitivity, or environment isolation are unclear.
• MUST produce at least these diagrams unless the repository clearly cannot support them: DFD Level 0, DFD Level 1, trust-boundary view, and top 2-3 sequence diagrams.
• MUST validate every Mermaid block before finalizing the report.
• MUST include at least 3 code-anchored or IaC-anchored findings that do not depend primarily on operator answers.
• MUST assign an overall application risk score from 0-100 with confidence, volatility, and top score drivers.
• MUST mark mitigations as PRESENT, ABSENT, or UNKNOWN.
• MUST mark threats as Mitigated, Partially Mitigated, Open, or Unknown based on whether controls materially close the exploit path.
• SHOULD prefer simple Mermaid syntax over advanced styling.
• SHOULD call out contradictions between repo evidence and operator statements before finalizing prioritization.
• MAY omit optional diagrams when the repository does not expose the needed evidence; label the gap as UNKNOWN.