Threat Model Analyst
GitHubOfficialFirst committed by cheguvDistributed by GitHub
- Skill
- Review and audit
- Security
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Threat Model Analyst is a specialized agent skill designed to perform rigorous security audits using the STRIDE-A (STRIDE + Abuse) methodology. It operates in two primary modes: a full initial analysis for new systems and an incremental mode for tracking security posture changes over time. The skill enforces strict architectural modeling rules, particularly regarding Kubernetes sidecar co-location, and provides structured, evidence-based reporting including DFD diagrams, prioritized findings, and executive assessments.
What it does
- Performs full STRIDE-A threat modeling including DFD generation and architectural risk assessment.
- Executes incremental analysis to track new, resolved, and persistent threats between code versions.
- Identifies security gaps by verifying infrastructure components and platform defaults before flagging.
- Generates standardized security reports including architecture overviews and prioritized findings.
- Maps security findings to industry standards like CVSS 4.0, CWE, and OWASP.
- Enforces consistent diagramming conventions for complex system architectures.
When to use it
- When you need a comprehensive security audit of a new repository or system architecture.
- When you need to update an existing threat model to reflect recent code changes.
- When you need to compare the security posture between two specific commits or report versions.
- When you need to identify trust boundary violations or architectural security risks.
Advantages
- Reduces false positives by requiring evidence-based verification of security controls.
- Maintains continuity in security documentation through incremental change tracking.
- Ensures architectural diagrams accurately reflect Kubernetes pod-level sidecar co-location.
- Provides actionable, prioritized security findings mapped to recognized industry frameworks.
Usage examples
- “Perform a full STRIDE-A threat model analysis on this repository.”
- The agent will analyze the codebase, generate architecture diagrams, identify threats, and produce a comprehensive security report.
- “Run an incremental threat model analysis using the report from last week as a baseline.”
- The agent will compare the current codebase against the previous report to identify new, fixed, or remaining security threats.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/github/threat-model-analyst/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip threat-model-analyst.zip -d .agents/skills
Documentation by cheguv
Threat Model Analyst
You are an expert Threat Model Analyst. You perform security audits using STRIDE-A (STRIDE + Abuse) threat modeling, Zero Trust principles, and defense-in-depth analysis. You flag secrets, insecure boundaries, and architectural risks.
Getting Started
FIRST — Determine which mode to use based on the user's request:
Incremental Mode (Preferred for Follow-Up Analyses)
If the user's request mentions updating, refreshing, or re-running a threat model AND a prior report folder exists:
Action words: "update", "refresh", "re-run", "incremental", "what changed", "since last analysis"
AND a baseline report folder is identified (either explicitly named or auto-detected as the most recent
threat-model-*folder with athreat-inventory.json)OR the user explicitly provides a baseline report folder + a target commit/HEAD
Examples that trigger incremental mode:
"Update the threat model using threat-model-20260309-174425 as the baseline"
"Run an incremental threat model analysis"
"Refresh the threat model for the latest commit"
"What changed security-wise since the last threat model?"
→ Read incremental-orchestrator.md and follow the incremental workflow. The incremental orchestrator inherits the old report's structure, verifies each item against current code, discovers new items, and produces a standalone report with embedded comparison.
Comparing Commits or Reports
If the user asks to compare two commits or two reports, use incremental mode with the older report as the baseline. → Read incremental-orchestrator.md and follow the incremental workflow.
Single Analysis Mode
For all other requests (analyze a repo, generate a threat model, perform STRIDE analysis):
→ Read orchestrator.md — it contains the complete 10-step workflow, 34 mandatory rules, tool usage instructions, sub-agent governance rules, and the verification process. Do not skip this step.
Reference Files
Load the relevant file when performing each task:
| File | Use When | Content |
|---|---|---|
| Orchestrator | Always — read first | Complete 10-step workflow, 34 mandatory rules, sub-agent governance, tool usage, verification process |
| Incremental Orchestrator | Incremental/update analyses | Complete incremental workflow: load old skeleton, change detection, generate report with status annotations, HTML comparison |
| Analysis Principles | Analyzing code for security issues | Verify-before-flagging rules, security infrastructure inventory, OWASP Top 10:2025, platform defaults, exploitability tiers, severity standards |
| Diagram Conventions | Creating ANY Mermaid diagram | Color palette, shapes, sidecar co-location rules, pre-render checklist, DFD vs architecture styles, sequence diagram styles |
| Output Formats | Writing ANY output file | Templates for 0.1-architecture.md, 1-threatmodel.md, 2-stride-analysis.md, 3-findings.md, 0-assessment.md, common mistakes checklist |
| Skeletons | Before writing EACH output file | 8 verbatim fill-in skeletons (skeleton-*.md) — read the relevant skeleton, copy VERBATIM, fill [FILL] placeholders. One skeleton per output file. Loaded on-demand to minimize context usage. |
| Verification Checklist | Final verification pass + inline quick-checks | All quality gates: inline quick-checks (run after each file write), per-file structural, diagram rendering, cross-file consistency, evidence quality, JSON schema — designed for sub-agent delegation |
| TMT Element Taxonomy | Identifying DFD elements from code | Complete TMT-compatible element type taxonomy, trust boundary detection, data flow patterns, code analysis checklist |
When to Activate
Incremental Mode (read incremental-orchestrator.md for workflow):
Update or refresh an existing threat model analysis
Generate a new analysis that builds on a prior report's structure
Track what threats/findings were fixed, introduced, or remain since a baseline
When a prior
threat-model-*folder exists and the user wants a follow-up analysis
Single Analysis Mode:
Perform full threat model analysis of a repository or system
Generate threat model diagrams (DFD) from code
Perform STRIDE-A analysis on components and data flows
Validate security control implementations
Identify trust boundary violations and architectural risks
Write prioritized security findings with CVSS 4.0 / CWE / OWASP mappings
Comparing commits or reports:
To compare security posture between commits, use incremental mode with the older report as baseline
Files
- ATTRIBUTION.mdAdded by AutoGineer869 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md5.7 KiB
- references/analysis-principles.md28.9 KiB
- references/diagram-conventions.md18.5 KiB
- references/incremental-orchestrator.md33.5 KiB
- references/orchestrator.md53.8 KiB
- references/output-formats.md58.5 KiB
- references/skeletons/skeleton-architecture.md6.1 KiB
- references/skeletons/skeleton-assessment.md11.1 KiB
- references/skeletons/skeleton-dfd.md3.3 KiB
- references/skeletons/skeleton-findings.md7.7 KiB
- references/skeletons/skeleton-incremental-html.md5.3 KiB
- references/skeletons/skeleton-inventory.md5.3 KiB
- references/skeletons/skeleton-stride-analysis.md6.2 KiB
- references/skeletons/skeleton-summary-dfd.md2.8 KiB
- references/skeletons/skeleton-threatmodel.md2.2 KiB
- references/tmt-element-taxonomy.md8.5 KiB
- references/verification-checklist.md69.9 KiB
references/skeletons/skeleton-architecture.md
Skeleton: 0.1-architecture.md
⛔ Copy the template content below VERBATIM (excluding the outer code fence). Replace
[FILL]placeholders. Do NOT add/rename/reorder sections. ⛔ Key Components table columns are EXACTLY:Component | Type | Description. DO NOT rename toRole,Change,Function. ⛔ Technology Stack table columns are EXACTLY:Layer | Technologies(2 columns). DO NOT addVersioncolumn or renameLayertoCategory. ⛔ Security Infrastructure Inventory and Repository Structure sections are MANDATORY — do NOT omit them.
# Architecture Overview
## System Purpose
[FILL-PROSE: 2-4 sentences — what is this system, what problem does it solve, who are the users]
## Key Components
| Component | Type | Description |
|-----------|------|-------------|
[REPEAT: one row per component]
| [FILL: PascalCase name] | [FILL: Process / Data Store / External Service / External Interactor] | [FILL: one-line description] |
[END-REPEAT]
<!-- ⛔ POST-TABLE CHECK: Verify Key Components:
1. Every component has PascalCase name (not kebab-case or snake_case)
2. Type is one of: Process / Data Store / External Service / External Interactor
3. Row count matches the number of nodes in the Component Diagram below
If ANY check fails → FIX NOW. -->
## Component Diagram
```mermaid
[FILL: Architecture diagram using service/external/datastore styles — NOT DFD circles]
```
## Top Scenarios
[REPEAT: 3-5 scenarios. First 3 MUST include sequence diagrams.]
### Scenario [FILL: N]: [FILL: Title]
[FILL-PROSE: 2-3 sentence description]
```mermaid
sequenceDiagram
[FILL: participants, messages, alt/opt blocks]
```
[END-REPEAT]
<!-- ⛔ POST-SECTION CHECK: Verify Top Scenarios:
1. At least 3 scenarios listed
2. First 3 scenarios MUST have sequenceDiagram blocks
3. Each sequence diagram has participant lines and message arrows
If ANY check fails → FIX NOW. -->
## Technology Stack
| Layer | Technologies |
|-------|--------------|
| Languages | [FILL] |
| Frameworks | [FILL] |
| Data Stores | [FILL] |
| Infrastructure | [FILL] |
| Security | [FILL] |
<!-- ⛔ POST-TABLE CHECK: Verify Technology Stack has all 5 rows filled. If Security row is empty, list security-relevant libraries/frameworks found in the code. -->
## Deployment Model
[FILL-PROSE: deployment description — ports, protocols, bind addresses, network exposure, topology (single machine / cluster / multi-tier)]
**Deployment Classification:** `[FILL: one of LOCALHOST_DESKTOP | LOCALHOST_SERVICE | AIRGAPPED | K8S_SERVICE | NETWORK_SERVICE]`
<!-- ⛔ DEPLOYMENT CLASSIFICATION RULES:
LOCALHOST_DESKTOP — Single-process console/GUI app, no network listeners (or localhost-only), single-user workstation. T1 FORBIDDEN.
LOCALHOST_SERVICE — Daemon/service binding to 127.0.0.1 only. T1 FORBIDDEN.
AIRGAPPED — No internet connectivity. T1 forbidden for network-originated attacks.
K8S_SERVICE — Kubernetes Deployment/StatefulSet with ClusterIP or LoadBalancer. T1 allowed.
NETWORK_SERVICE — Public API, cloud endpoint, internet-facing. T1 allowed.
This classification is BINDING on all subsequent prerequisite and tier assignments. -->
### Component Exposure Table
| Component | Listens On | Auth Required | Reachability | Min Prerequisite | Derived Tier |
|-----------|------------|---------------|--------------|------------------|-------------|
[REPEAT: one row per component from Key Components table]
| [FILL: component name] | [FILL: port/address or "N/A — no listener"] | [FILL: Yes (mechanism) / No] | [FILL: one of: External / Internal Only / Localhost Only / No Listener] | [FILL: one of closed enum — see rules below] | [FILL: T1 / T2 / T3] |
[END-REPEAT]
<!-- ⛔ EXPOSURE TABLE RULES:
1. Every component from Key Components MUST have a row.
2. "Listens On" = the actual bind address from code (e.g., "127.0.0.1:8080", "0.0.0.0:443", "N/A — no listener").
3. "Reachability" MUST be one of these 4 values (closed enum):
- `External` — reachable from public internet or untrusted network
- `Internal Only` — reachable only within a private network (K8s cluster, VNet, etc.)
- `Localhost Only` — binds to 127.0.0.1 or named pipe, same-host only
- `No Listener` — does not accept inbound connections (outbound-only, console I/O, library)
4. "Min Prerequisite" MUST be one of these values (closed enum):
- `None` — only valid when Reachability = External AND Auth Required = No
- `Authenticated User` — Reachability = External AND Auth Required = Yes
- `Internal Network` — Reachability = Internal Only AND Auth Required = No
- `Privileged User` — requires admin/operator role
- `Local Process Access` — Reachability = Localhost Only (same-host process can connect)
- `Host/OS Access` — Reachability = No Listener (requires filesystem, console, or debug access)
- `Admin Credentials` — requires admin credentials + host access
- `Physical Access` — requires physical presence
⛔ FORBIDDEN values: `Application Access`, `Host Access` (ambiguous — use `Local Process Access` or `Host/OS Access` instead)
5. "Derived Tier" is mechanically determined from Min Prerequisite:
- `None` → T1
- `Authenticated User`, `Privileged User`, `Internal Network`, `Local Process Access` → T2
- `Host/OS Access`, `Admin Credentials`, `Physical Access`, `{Component} Compromise`, or any `A + B` → T3
6. No threat or finding for this component may have a LOWER prerequisite than Min Prerequisite.
7. No threat or finding for this component may have a HIGHER tier (lower number) than Derived Tier.
8. This table is the SINGLE SOURCE OF TRUTH for prerequisite floors and tier ceilings. STRIDE and findings MUST respect it. -->
## Security Infrastructure Inventory
| Component | Security Role | Configuration | Notes |
|-----------|---------------|---------------|-------|
[REPEAT: one row per security-relevant component found in code]
| [FILL] | [FILL] | [FILL] | [FILL] |
[END-REPEAT]
## Repository Structure
| Directory | Purpose |
|-----------|---------|
[REPEAT: one row per key directory]
| [FILL: path/] | [FILL] |
[END-REPEAT]Requirements and compatibility
Written for: GitHub Copilot
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- First committed by
cheguv
- Publisher
- GitHub (Official)
- Distributed by
- GitHub
- Source
- github/awesome-copilot · skills/threat-model-analyst · commit 797337f
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- cheguv, stbenjam
AutoGineer is not affiliated with or endorsed by cheguv or GitHub.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download threat-model-analyst.zip