threat-model-generation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Threat Model Generation

威胁模型生成

Generate a comprehensive security threat model for a repository using the STRIDE methodology. This skill analyzes the codebase architecture and produces an LLM-optimized threat model document that other security skills can reference.

使用STRIDE方法论为代码仓库生成全面的安全威胁模型。该技能会分析代码库架构，并生成一份经LLM优化的威胁模型文档，供其他安全技能参考。

When to Use This Skill

何时使用此技能

First-time setup - New repository needs initial threat model
Architecture changes - Significant changes to components, APIs, or data flows
Security audit - Periodic review or compliance requirement
Manual request - Security team requests updated threat model

首次设置 - 新代码仓库需要初始威胁模型
架构变更 - 组件、API或数据流发生重大变更
安全审计 - 定期审查或合规要求
手动请求 - 安全团队要求更新威胁模型

Inputs

输入项

Before running this skill, gather or confirm:

Input	Description	Required
Repository path	Root directory to analyze	Yes (default: current directory)
Existing threat model	Path to existing `.factory/threat-model.md` if updating	No
Compliance requirements	Frameworks to consider (SOC2, GDPR, HIPAA, etc.)	No
Security contacts	Email addresses for security team notifications	No

运行此技能前，请收集或确认以下信息：

输入项	描述	是否必填
代码仓库路径	待分析的根目录	是（默认：当前目录）
现有威胁模型	若需更新，提供现有 `.factory/threat-model.md` 的路径	否
合规要求	需要考虑的框架（SOC2、GDPR、HIPAA等）	否
安全联系人	安全团队通知的电子邮件地址	否

Instructions

操作步骤

Follow these steps in order:

按以下顺序执行步骤：

Step 1: Analyze Repository Structure

步骤1：分析代码仓库结构

Scan the codebase to understand the system:

Identify languages and frameworks
- Check
```
package.json
```
  ,
```
requirements.txt
```
  ,
```
go.mod
```
  ,
```
Cargo.toml
```
  , etc.
- Note the primary tech stack (e.g., Next.js, Django, Go microservices)
Map components and services
- Look for
```
apps/
```
  ,
```
services/
```
  ,
```
packages/
```
  directories
- Identify entry points: API routes, CLI commands, web handlers
- Note databases, caches, message queues
Identify external interfaces
- HTTP endpoints (REST, GraphQL)
- File upload handlers
- Webhook receivers
- OAuth/SSO integrations
- CLI commands that accept user input
Trace data flows
- How does user input enter the system?
- Where is sensitive data stored?
- What external services are called?

扫描代码库以了解系统：

识别语言与框架
- 检查
```
package.json
```
  、
```
requirements.txt
```
  、
```
go.mod
```
  、
```
Cargo.toml
```
  等文件
- 记录主要技术栈（如Next.js、Django、Go微服务）
映射组件与服务
- 查找
```
apps/
```
  、
```
services/
```
  、
```
packages/
```
  目录
- 识别入口点：API路由、CLI命令、Web处理器
- 记录数据库、缓存、消息队列
识别外部接口
- HTTP端点（REST、GraphQL）
- 文件上传处理器
- Webhook接收器
- OAuth/SSO集成
- 接受用户输入的CLI命令
追踪数据流
- 用户输入如何进入系统？
- 敏感数据存储在何处？
- 调用了哪些外部服务？

Step 2: Identify Trust Boundaries

步骤2：确定信任边界

Define security zones:

Public Zone (untrusted)
- All external HTTP endpoints
- Public APIs without authentication
- User-uploaded files
Authenticated Zone (partially trusted)
- Endpoints requiring valid session/token
- User-specific data access
- Rate-limited APIs
Internal Zone (trusted)
- Service-to-service communication
- Admin-only endpoints
- Database connections
- Secrets management

Document where trust boundaries exist and what validates transitions between zones.

定义安全区域：

公共区域（不可信）
- 所有外部HTTP端点
- 无需认证的公共API
- 用户上传的文件
认证区域（部分可信）
- 需要有效会话/令牌的端点
- 用户特定数据访问
- 限流API
内部区域（可信）
- 服务间通信
- 仅管理员可访问的端点
- 数据库连接
- 密钥管理

记录信任边界的位置，以及验证区域间转换的机制。

Step 3: Inventory Critical Assets

步骤3：盘点关键资产

Classify data by sensitivity:

PII (Personally Identifiable Information)
- User emails, names, addresses, phone numbers
- Document protection measures
Credentials & Secrets
- Password hashes, API keys, OAuth tokens
- JWT signing keys, encryption keys
- Document rotation policies
Business-Critical Data
- Transaction records, customer data
- Proprietary algorithms, trade secrets
- Document access controls

按敏感度分类数据：

PII（个人身份信息）
- 用户邮箱、姓名、地址、电话号码
- 记录保护措施
凭证与密钥
- 密码哈希、API密钥、OAuth令牌
- JWT签名密钥、加密密钥
- 记录轮换策略
业务关键数据
- 交易记录、客户数据
- 专有算法、商业机密
- 记录访问控制

Step 4: Apply STRIDE Analysis

步骤4：应用STRIDE分析

For each major component, analyze threats in all six categories:

针对每个主要组件，分析六大类威胁：

S - Spoofing Identity

S - 身份伪造（Spoofing Identity）

Can attackers impersonate users or services?
Are authentication mechanisms secure?
Look for: weak session handling, API key exposure, missing MFA

攻击者能否冒充用户或服务？
认证机制是否安全？
检查点：会话处理薄弱、API密钥暴露、缺少MFA

T - Tampering with Data

T - 数据篡改（Tampering with Data）

Can attackers modify data in transit or at rest?
Look for: SQL injection, XSS, mass assignment, missing input validation

攻击者能否篡改传输中或存储的数据？
检查点：SQL注入、XSS、批量赋值、缺少输入验证

R - Repudiation

R - 抵赖（Repudiation）

Can users deny actions they performed?
Look for: missing audit logs, insufficient logging, no immutable trails

用户能否否认自己执行的操作？
检查点：缺少审计日志、日志记录不足、无不可变追踪轨迹

I - Information Disclosure

I - 信息泄露（Information Disclosure）

Can attackers access data they shouldn't?
Look for: IDOR, verbose errors, hardcoded secrets, data leaks in logs

攻击者能否访问无权查看的数据？
检查点：IDOR、详细错误信息、硬编码密钥、日志中的数据泄露

D - Denial of Service

D - 拒绝服务（Denial of Service）

Can attackers disrupt service availability?
Look for: missing rate limits, resource exhaustion, algorithmic complexity

攻击者能否破坏服务可用性？
检查点：缺少限流、资源耗尽、算法复杂度问题

E - Elevation of Privilege

E - 权限提升（Elevation of Privilege）

Can attackers gain unauthorized access levels?
Look for: missing authorization checks, role manipulation, privilege escalation

For each identified threat:

Describe the attack scenario
List vulnerable components
Show code patterns to look for
Note existing mitigations
Identify gaps
Assign severity (CRITICAL/HIGH/MEDIUM/LOW) and likelihood

攻击者能否获得未授权的访问级别？
检查点：缺少授权检查、角色篡改、权限提升

针对每个识别出的威胁：

描述攻击场景
列出易受攻击的组件
展示需排查的代码模式
记录现有缓解措施
识别缺口
分配严重程度（CRITICAL/HIGH/MEDIUM/LOW）和发生概率

Step 5: Document Vulnerability Patterns

步骤5：记录漏洞模式

Create a library of code patterns specific to this codebase's tech stack:

python

undefined

创建针对该代码库技术栈的代码模式库：

python

undefined

Example: SQL Injection patterns for Python

示例：Python的SQL注入模式

VULNERABLE

存在漏洞

sql = f"SELECT * FROM users WHERE id = {user_id}"

SAFE

安全写法

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))


Include patterns for:

- SQL injection
- XSS (Cross-Site Scripting)
- Command injection
- Path traversal
- Authentication bypass
- IDOR (Insecure Direct Object Reference)

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))


包含以下模式：

- SQL注入
- XSS（跨站脚本）
- 命令注入
- 路径遍历
- 认证绕过
- IDOR（不安全直接对象引用）

Step 6: Generate Output Files

步骤6：生成输出文件

Create two files:

创建两个文件：

.factory/threat-model.md

.factory/threat-model.md

Use the template in

stride-template.md

to generate a comprehensive threat model with:

System overview with architecture description
Trust boundaries and security zones
Attack surface inventory
Critical assets classification
STRIDE threat analysis for each component
Vulnerability pattern library
Security testing strategy
Assumptions and accepted risks
Version changelog

The document should be written in natural language with code examples, optimized for LLM comprehension.

使用

stride-template.md

中的模板生成全面的威胁模型，包含：

系统概述与架构描述
信任边界与安全区域
攻击面盘点
关键资产分类
各组件的STRIDE威胁分析
漏洞模式库
安全测试策略
假设与已接受风险
版本变更日志

文档需使用自然语言编写，包含代码示例，优化以适配LLM理解。

.factory/security-config.json

.factory/security-config.json

Generate configuration metadata:

json

{
  "threat_model_version": "1.0.0",
  "last_updated": "<ISO timestamp>",
  "security_team_contacts": [],
  "compliance_requirements": [],
  "scan_frequency": "on_commit",
  "severity_thresholds": {
    "block_merge": ["CRITICAL"],
    "require_review": ["HIGH", "CRITICAL"],
    "notify_security_team": ["CRITICAL"]
  },
  "vulnerability_patterns": {
    "enabled": [
      "sql_injection",
      "xss",
      "command_injection",
      "path_traversal",
      "auth_bypass",
      "idor"
    ],
    "custom_patterns_path": null
  }
}

Customize based on:

Detected compliance requirements (from docs, configs, or user input)
Security team contacts (if provided)
Tech stack (enable relevant vulnerability patterns)

生成配置元数据：

json

{
  "threat_model_version": "1.0.0",
  "last_updated": "<ISO timestamp>",
  "security_team_contacts": [],
  "compliance_requirements": [],
  "scan_frequency": "on_commit",
  "severity_thresholds": {
    "block_merge": ["CRITICAL"],
    "require_review": ["HIGH", "CRITICAL"],
    "notify_security_team": ["CRITICAL"]
  },
  "vulnerability_patterns": {
    "enabled": [
      "sql_injection",
      "xss",
      "command_injection",
      "path_traversal",
      "auth_bypass",
      "idor"
    ],
    "custom_patterns_path": null
  }
}

根据以下信息自定义：

检测到的合规要求（来自文档、配置或用户输入）
安全团队联系人（若提供）
技术栈（启用相关漏洞模式）

Success Criteria

成功标准

The skill is complete when:

```
.factory/threat-model.md
```
exists with all sections populated
```
.factory/security-config.json
```
exists with valid JSON
All major components have STRIDE analysis
Vulnerability patterns match the tech stack
Document is written in natural language (LLM-readable)
No placeholder text remains

满足以下条件时，技能执行完成：

```
.factory/threat-model.md
```
已存在且所有章节均已填充内容
```
.factory/security-config.json
```
已存在且为有效JSON
所有主要组件均已完成STRIDE分析
漏洞模式与技术栈匹配
文档使用自然语言编写（LLM可读）
无占位文本残留

Verification

验证

Run these checks before completing:

bash

undefined

完成前运行以下检查：

bash

undefined

Verify threat model exists and is non-empty

验证威胁模型存在且非空

test -s .factory/threat-model.md && echo "✓ Threat model exists"

test -s .factory/threat-model.md && echo "✓ 威胁模型已存在"

Verify config is valid JSON

验证配置为有效JSON

cat .factory/security-config.json | jq . > /dev/null && echo "✓ Config is valid JSON"

cat .factory/security-config.json | jq . > /dev/null && echo "✓ 配置为有效JSON"

Check threat model has key sections

检查威胁模型包含关键章节

grep -q "## 1. System Overview" .factory/threat-model.md && echo "✓ Has System Overview" grep -q "## 5. Threat Analysis" .factory/threat-model.md && echo "✓ Has Threat Analysis" grep -q "## 6. Vulnerability Pattern Library" .factory/threat-model.md && echo "✓ Has Pattern Library"

undefined

grep -q "## 1. System Overview" .factory/threat-model.md && echo "✓ 包含系统概述" grep -q "## 5. Threat Analysis" .factory/threat-model.md && echo "✓ 包含威胁分析" grep -q "## 6. Vulnerability Pattern Library" .factory/threat-model.md && echo "✓ 包含模式库"

undefined

Example Invocations

调用示例

Generate initial threat model:

Generate a threat model for this repository using the threat-model-generation skill.

Update existing threat model after architecture change:

Update the threat model - we added a new payments service in services/payments/.

Generate with compliance requirements:

Generate a threat model for this repository. We need to comply with SOC2 and GDPR.

生成初始威胁模型：

使用threat-model-generation技能为当前代码仓库生成威胁模型。

架构变更后更新现有威胁模型：

更新威胁模型 - 我们在services/payments/中新增了支付服务。

生成带合规要求的威胁模型：

为当前代码仓库生成威胁模型，需符合SOC2和GDPR合规要求。

References

参考资料

STRIDE Threat Modeling
OWASP Threat Modeling
Template:
```
stride-template.md
```
(in this skill directory)

STRIDE Threat Modeling
OWASP Threat Modeling
模板：
```
stride-template.md
```
（位于此技能目录中）