关于 security-threat-model
security-threat-model 是一项为服务或功能生成 STRIDE 威胁模型的技能，面向需要记录安全风险与决策的工程团队。它将资产、信任边界、威胁、风险评分和缓解措施纳入结构化报告。
主要功能
- 01收集架构、数据和现有控制信息
- 02按 STRIDE 分类分析威胁
- 03登记资产与信任边界
- 04评估威胁风险等级
- 05制定缓解措施与责任分配
- 06记录已接受风险和复审周期
适用场景
- 01为新服务或功能开展安全评估
- 02记录架构变更带来的威胁
- 03整理风险缓解计划与责任人
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/security-threat-model确认已加载。
详细介绍
安全威胁建模技能
为服务或功能生成完整的、基于 STRIDE 的威胁模型。威胁模型不只是可能出错事项的列表，而是对攻击者、资产、边界和控制措施进行结构化分析，帮助工程团队做出有依据且有文档记录的安全决策。
优秀的威胁模型应足够具体，让新工程师能够理解要保护什么、每项控制措施为何存在，以及团队接受了哪些风险。
所需输入
如果尚未提供，请询问以下信息：
- 服务名称和描述 — 服务的功能以及使用者
- 架构概览 — 组件、依赖项、数据流（可提供图示说明或 ASCII 图）
- 部署环境 — 云服务提供商、VPC／网络拓扑、运行环境（Kubernetes、ECS、VM、无服务器）
- 数据敏感性 — 此服务处理哪些数据？PII、支付数据、凭据、仅限内部使用的数据？
- 现有控制措施 — 身份验证方法、传输中／静态加密、当前 WAF／防火墙、现有安全扫描
- 信任级别 — 涉及哪些主体？（匿名公众、已通过身份验证的用户、内部服务、管理员）
输出格式
安全威胁模型：[服务名称]
服务： [名称] | 团队： [团队名称] 作者： [姓名] | 审阅者： [安全负责人／同行] 日期： [日期] | 下次审查： [日期 — 建议 6 个月后或重大架构变更后] 分类： [内部／机密]
1. 概述
[用 2–3 句话描述服务、它在系统中的作用，以及此威胁模型的范围。说明哪些内容在范围内，哪些内容明确不在范围内。]
范围内：
- [组件或数据流]
- [组件或数据流]
范围外：
- [例如：第三方支付处理方内部机制]
- [例如：企业网络／终端用户设备]
2. 资产清单
资产是值得保护的对象，包括数据、能力和声誉价值。
| 资产 | 描述 | 敏感性 | 负责人 |
|---|---|---|---|
| [例如：用户 PII] | 姓名、电子邮件地址、个人资料数据 | 高 — 受 GDPR 监管 | [团队] |
| [例如：API 凭据] | 服务间身份验证令牌 | 严重 | [团队] |
| [例如：会话令牌] | 用户身份验证状态 | 高 | [团队] |
| [例如：审计日志] | 用户和管理员操作记录 | 中 | [团队] |
| [例如：服务可用性] | [X] 端点的正常运行时间 | 中 | [团队] |
数据分类说明：
- 严重 — 凭据材料；泄露会导致系统直接遭到入侵
- 高 — PII、财务数据、健康数据；受监管或声誉影响大
- 中 — 内部配置、非敏感业务数据
- 低 — 公开信息、匿名化数据
3. 信任边界与架构
信任边界是划分不同信任级别区域的界线。数据或请求跨越边界时，往往会出现威胁。
┌─────────────────────────────────────────────────────────────────┐
│ INTERNET (Untrusted) │
│ │
│ [Public User] [Bot / Attacker] │
└──────────────────────────────┬──────────────────────────────────┘
│ HTTPS
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
Trust Boundary: Public → DMZ
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼
┌──────────────────────────────────────────────────────────────────┐
│ DMZ / Edge Layer │
│ ┌────────────┐ ┌──────────────┐ │
│ │ WAF / CDN │────▶│ API Gateway │ │
│ └────────────┘ └──────┬───────┘ │
└──────────────────────────────┼───────────────────────────────────┘
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
Trust Boundary: Edge → Application VPC
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼
┌──────────────────────────────────────────────────────────────────┐
│ Application VPC (Private) │
│ ┌──────────────┐ ┌────────────┐ ┌──────────────────┐ │
│ │ [Service A] │────▶│ [Service B]│────▶│ [Database] │ │
│ └──────────────┘ └────────────┘ └──────────────────┘ │
│ ▲ │
│ │ │
│ ┌──────────────┐ │ │
│ │ Admin (IAM) │─────────────┘ │
└──────────────────────────────────────────────────────────────────┘
已识别的信任边界：
| 边界 | 来源 | 目标 | 身份验证机制 | 加密 |
|---|---|---|---|---|
| TB-1 | 公共互联网 | API 网关 | [JWT／OAuth／API key] | TLS 1.2+ |
| TB-2 | API 网关 | 服务 A | [mTLS／内部 JWT／IAM 角色] | [是／否] |
| TB-3 | 服务 A | 数据库 | [连接字符串 + IAM／用户名+密码] | [是／否] |
| TB-4 | 管理员 | 服务 B | [IAM 角色／VPN + MFA] | TLS |
4. STRIDE 威胁分析
STRIDE 是一种威胁分类框架。针对每个重要组件，逐一列出各类别中的威胁。
STRIDE 说明：
- S — 欺骗：冒充其他用户、服务或系统
- T — 篡改：未经授权修改数据或代码
- R — 抵赖：否认某项操作已发生；审计跟踪不足
- I — 信息泄露：向未经授权的对象暴露数据
- D — 拒绝服务：导致服务不可用
- E — 权限提升：获得超出授权范围的能力
组件：[API 网关 / 认证层]
| ID | 类别 | 威胁 | 攻击向量 | 现有控制措施 |
|---|---|---|---|---|
| T-001 | S | 攻击者伪造 JWT 令牌，以其他用户身份进行认证 | 签名密钥强度不足或算法混淆（alg:none） | [例如：使用 RS256 并轮换密钥 / 无] |
| T-002 | S | 攻击者重放窃取的会话令牌 | 通过 XSS 或网络嗅探窃取 | [例如：令牌过期 + 刷新令牌轮换] |
| T-003 | T | 攻击者修改请求标头以绕过租户隔离 | 未验证租户 ID 标头 | [例如：在服务端解析租户 / 无] |
| T-004 | R | 管理员认证事件没有审计记录 | 未配置认证失败日志 | [例如：已启用 CloudTrail / 无] |
| T-005 | I | 认证错误消息泄露电子邮件地址是否存在 | 错误响应信息过于详细 | [例如：规范化错误响应 / 无] |
| T-006 | D | 凭据填充攻击耗尽速率限制并阻止合法用户登录 | 自动化登录尝试 | [例如：按 IP 限速 + CAPTCHA / 无] |
| T-007 | E | 利用遭入侵的低权限令牌调用管理员端点 | 管理员路由缺少角色检查 | [例如：所有路由均使用 RBAC 中间件 / 无] |
组件：[应用服务 / 业务逻辑]
| ID | 类别 | 威胁 | 攻击向量 | 现有控制措施 |
|---|---|---|---|---|
| T-008 | T | 通过未经清理的用户输入进行 SQL/NoSQL 注入 | 查询未使用参数化 | [例如：使用带参数化查询的 ORM / 无] |
| T-009 | T | 批量赋值——攻击者设置其无权设置的字段（例如 isAdmin: true） | API 接受未在允许列表中的额外字段 | [例如：输入验证 / 无] |
| T-010 | I | 不安全的直接对象引用——用户访问其他用户的资源 | 未根据资源 ID 检查所有权 | [例如：所有权中间件 / 无] |
| T-011 | I | 应用日志中包含敏感数据（PII、令牌） | 调试模式下记录过多日志 | [例如：日志脱敏 / 无] |
| T-012 | D | 未受保护的高开销端点触发大型数据库扫描 | 没有分页或查询开销限制 | [例如：强制分页 / 无] |
| T-013 | R | 未记录业务关键状态变更 | [operation] 未触发审计事件 | [例如：审计日志表 / 无] |
组件：[数据库]
| ID | 类别 | 威胁 | 攻击向量 | 现有控制措施 |
|---|---|---|---|---|
| T-014 | I | 数据库暴露在互联网中（安全组配置错误） | 从 VPC 外部直接连接 | [例如：无公网 IP，安全组仅允许应用子网访问] |
| T-015 | I | 备份快照未加密，或可被错误的账户访问 | 未加密的快照、公开的 S3 | [例如：已加密的快照、私有 S3 存储桶] |
| T-016 | T | 通过权限过大的数据库账户提升权限 | 应用使用超级用户数据库账户 | [例如：每个服务使用遵循最小权限原则的数据库角色 / 无] |
| T-017 | D | 查询失控或批量删除导致数据丢失或服务中断 | 没有查询超时或软删除 | [例如：语句超时，对关键表启用软删除 / 无] |
组件：[内部服务间通信]
| ID | 类别 | 威胁 | 攻击向量 | 现有控制措施 |
|---|---|---|---|---|
| T-018 | S | 恶意内部服务冒充可信服务 | 服务之间没有双向认证 | [例如：mTLS / 服务网格 / 无] |
| T-019 | I | 内部流量在共享网络上被嗅探 | 服务间调用未加密 | [例如：使用 TLS 的服务网格 / 无] |
| T-020 | E | 遭入侵的内部服务调用特权端点 | 内部令牌没有限定权限范围 | [例如：权限范围受限的服务令牌 / 无] |
5. 风险登记表
为每项威胁评分：可能性（1–5） × 影响（1–5） = 风险评分（1–25）
优先级范围：严重（20–25） | 高（12–19） | 中（6–11） | 低（1–5）
| ID | 威胁摘要 | 可能性 | 影响 | 评分 | 优先级 | 状态 |
|---|---|---|---|---|---|---|
| T-001 | JWT 伪造 — 绕过身份验证 | 2 | 5 | 10 | 中 | [Open / Mitigated / Accepted] |
| T-002 | 会话令牌重放 | 3 | 4 | 12 | 高 | [Open / Mitigated / Accepted] |
| T-007 | 因缺少角色检查导致权限提升 | 3 | 5 | 15 | 高 | [Open / Mitigated / Accepted] |
| T-008 | SQL 注入 | 2 | 5 | 10 | 中 | [Open / Mitigated / Accepted] |
| T-010 | IDOR — 跨用户访问数据 | 3 | 4 | 12 | 高 | [Open / Mitigated / Accepted] |
| T-014 | 数据库暴露于互联网 | 1 | 5 | 5 | 低 | [Open / Mitigated / Accepted] |
| T-018 | 恶意内部服务冒充 | 2 | 4 | 8 | 中 | [Open / Mitigated / Accepted] |
6. 缓解措施表
对于优先级为中或更高的每项未处理威胁，请制定具体的缓解措施。
| ID | 威胁 | 缓解措施 | 负责人 | 目标日期 | 工单 |
|---|---|---|---|---|---|
| T-002 | 会话令牌重放 | 实现刷新时的令牌轮换 — 立即在服务端使旧令牌失效 | [工程师姓名] | [日期] | [JIRA-123] |
| T-007 | 权限提升 | 为所有 /admin/* 路由添加 RBAC 中间件；编写角色边界集成测试 | [工程师姓名] | [日期] | [JIRA-124] |
| T-010 | IDOR | 为所有获取资源的服务方法添加所有权断言；将其加入代码审查清单 | [工程师姓名] | [日期] | [JIRA-125] |
| T-011 | 日志中的 PII | 审查包含 PII 字段的日志调用；在日志记录器中间件中添加脱敏处理 | [工程师姓名] | [日期] | [JIRA-126] |
| T-018 | 恶意服务冒充 | 通过服务网格启用 mTLS，或为每项服务签发受限服务令牌 | [工程师姓名] | [日期] | [JIRA-127] |
7. 已接受的风险
已接受的风险是指团队决定目前不予缓解的威胁。每项已接受的风险都必须指定负责人和审核日期。
| ID | 威胁 | 接受原因 | 风险负责人 | 审核日期 |
|---|---|---|---|---|
| T-014 | 数据库公开暴露 | 数据库未分配公网 IP；已有控制措施 — 因可能性较低而接受 | [姓名] | [日期] |
| [ID] | [威胁] | [原因 — 例如：“在当前规模下，投入超过风险；当流量达到 10 倍时重新评估”] | [姓名] | [日期] |
8. 安全控制措施摘要
| 控制措施 | 类型 | 涵盖的威胁 | 是否已实施 |
|---|---|---|---|
| 有效期为 15 分钟的 JWT RS256 | 预防性 | T-001, T-002 | [Yes / Partial / No] |
| 所有路由上的 RBAC 中间件 | 预防性 | T-007, T-020 | [Yes / Partial / No] |
| 参数化查询（ORM） | 预防性 | T-008 | [Yes / Partial / No] |
| 速率限制（每个 IP 每分钟 100 个请求） | 预防性 | T-006, T-012 | [Yes / Partial / No] |
| CloudTrail / 审计日志记录 | 检测性 | T-004, T-013 | [Yes / Partial / No] |
| CI 流水线中的自动化 SAST | 检测性 | T-008, T-009 | [Yes / Partial / No] |
| 加密备份 + 私有 S3 | 预防性 | T-015 | [Yes / Partial / No] |
| 最小权限数据库角色 | 预防性 | T-016 | [Yes / Partial / No] |
| 事件响应操作手册 | 纠正性 | 全部 | [Yes / Partial / No] |
9. 审核周期
| 触发条件 | 操作 |
|---|---|
| 每 6 个月 | 全面审核威胁模型 — 更新风险评分，关闭已缓解事项 |
| 重大架构变更 | 更新信任边界图，并对新增组件重新执行 STRIDE 分析 |
| 安全事件 | 审核相关威胁；添加任何新发现的攻击途径 |
| 新的数据分类 | 将资产添加到登记表；评估是否适用新的 STRIDE 类别 |
| 添加第三方依赖项 | 评估新依赖项的供应链威胁 |
下次计划审核： [日期] 审核负责人： [姓名 / 安全负责人]
质量检查
- 已为每个信任边界命名，并明确指定其身份验证机制，而非留作“TBD”
- 风险登记表中的每项严重和高风险都已指定缓解措施、负责人和目标日期
- 每项已接受的风险都已指定风险负责人和复审日期，不存在无人负责的已接受风险
- 资产登记表包含数据敏感级别，并且至少有一项凭据材料
- STRIDE 分析涵盖所有主要组件，而不仅是 API 层
- 缓解措施足够具体，可以创建为工单，而不是“提升安全性”
- ASCII 信任边界图与提供的架构说明一致
反模式
- 不要将 STRIDE 分析限制在 API 层；每个组件都可能存在威胁，包括数据库和内部服务
- 不要将缓解措施写成“提升安全性”这类含糊指令；每项缓解措施都必须足够具体，可以创建为工单
- 不要接受没有指定负责人和复审日期的风险；无人负责的已接受风险不属于受管理的风险
- 不要只撰写涵盖理论威胁的威胁模型；应使用风险登记表，按可能性和影响确定优先级
- 不要省略资产登记表；如果不知道要保护什么，STRIDE 分析就没有依据
评论
支持 Markdown