threat-model-generation

威胁模型生成

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

何时使用此技能

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

输入

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

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

说明

请按顺序执行以下步骤：

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

扫描代码库以了解系统：

1. 识别语言和框架

   • 检查 package.json、requirements.txt、go.mod、Cargo.toml 等文件
   • 记录主要技术栈（例如 Next.js、Django、Go 微服务）

2. 绘制组件和服务图

   • 查找 apps/、services/、packages/ 目录
   • 识别入口点：API 路由、CLI 命令、Web 处理程序
   • 记录数据库、缓存、消息队列

3. 识别外部接口

   • HTTP 端点（REST、GraphQL）
   • 文件上传处理程序
   • Webhook 接收器
   • OAuth/SSO 集成
   • 接受用户输入的 CLI 命令

4. 追踪数据流

   • 用户输入如何进入系统？
   • 敏感数据存储在哪里？
   • 会调用哪些外部服务？

步骤 2：识别信任边界

定义安全区域：

1. 公共区域（不可信）

   • 所有外部 HTTP 端点
   • 无需身份验证的公共 API
   • 用户上传的文件

2. 已验证身份区域（部分可信）

   • 需要有效会话/令牌的端点
   • 用户特定的数据访问
   • 受速率限制的 API

3. 内部区域（可信）

   • 服务间通信
   • 仅限管理员使用的端点
   • 数据库连接
   • 密钥管理

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

步骤 3：盘点关键资产

按敏感程度对数据分类：

1. PII（个人身份信息）

   • 用户电子邮件、姓名、地址、电话号码
   • 记录保护措施

2. 凭据与密钥

   • 密码哈希、API 密钥、OAuth 令牌
   • JWT 签名密钥、加密密钥
   • 记录轮换策略

3. 业务关键数据

   • 交易记录、客户数据
   • 专有算法、商业机密
   • 记录访问控制

步骤 4：应用 STRIDE 分析

针对每个主要组件，分析以下六个类别中的威胁：

S - 身份欺骗

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

T - 数据篡改

• 攻击者能否修改传输中或静态存储的数据？
• 检查：SQL 注入、XSS、大规模赋值、缺少输入验证

R - 抵赖

• 用户能否否认自己执行过的操作？
• 检查：缺少审计日志、日志记录不足、没有不可篡改的记录

I - 信息泄露

• 攻击者能否访问他们不应访问的数据？
• 查找：IDOR、详细错误信息、硬编码的密钥、日志中的数据泄露

D - 拒绝服务

• 攻击者能否干扰服务的可用性？
• 查找：缺少速率限制、资源耗尽、算法复杂度

E - 权限提升

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

对于每个识别出的威胁：

• 描述攻击场景
• 列出易受攻击的组件
• 展示需要留意的代码模式
• 说明现有缓解措施
• 找出差距
• 评定严重性（CRITICAL/HIGH/MEDIUM/LOW）和可能性

步骤 5：记录漏洞模式

创建一个针对此代码库技术栈的代码模式库：

# Example: SQL Injection patterns for Python
# VULNERABLE
sql = f"SELECT * FROM users WHERE id = {user_id}"

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

包含以下模式：

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

步骤 6：生成输出文件

创建两个文件：

1. .factory/threat-model.md

使用 stride-template.md 中的模板，生成一份全面的威胁模型，其中包含：

• 系统概述和架构说明
• 信任边界和安全区域
• 攻击面清单
• 关键资产分类
• 对每个组件进行 STRIDE 威胁分析
• 漏洞模式库
• 安全测试策略
• 假设和接受的风险
• 版本变更日志

文档应使用自然语言编写，包含代码示例，并针对大模型理解进行优化。

2. .factory/security-config.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
  }
}

根据以下信息进行自定义：

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

成功标准

以下条件均满足时，技能即告完成：

• .factory/threat-model.md 已生成，且所有章节均已填充
• .factory/security-config.json 已生成，且包含有效的 JSON
• 所有主要组件均已完成 STRIDE 分析
• 漏洞模式与技术栈相匹配
• 文档使用自然语言编写（便于大模型阅读）
• 不留有占位文本

验证

完成前运行以下检查：

# Verify threat model exists and is non-empty
test -s .factory/threat-model.md && echo "✓ Threat model exists"

# Verify config is valid JSON
cat .factory/security-config.json | jq . > /dev/null && echo "✓ Config is valid 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"

调用示例

生成初始威胁模型：

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

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

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

根据合规要求生成：

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

参考资料

• STRIDE 威胁建模
• OWASP 威胁建模
• 模板：stride-template.md（位于此技能目录中）