agents24 仓库 threat-modeling-expert 安全威胁建模专家 Agent 实战指南：STRIDE、攻击树与风险优先级的完整方法论

agents24 仓库 threat-modeling-expert 安全威胁建模专家 Agent 实战指南：STRIDE、攻击树与风险优先级的完整方法论

【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents

本篇技术指南以 agents24 仓库plugins/security-scanning插件中的 threat-modeling-expert.md 为骨架，系统讲解一个面向安全架构评审与威胁识别的多智能体 Agent：它如何贯穿 STRIDE、攻击树、安全需求提取与缓解策略映射的完整工作流，并给出可直接落地复用的威胁建模模板、评分方法与源码级实现佐证。读完本文，你将掌握在代码库与架构评审场景中构建 secure-by-design 系统的八步威胁建模流程，并能将威胁直接转化为可测试的安全需求与缓解方案。

一、Agent 定位：一个专精威胁建模的安全专家

threat-modeling-expert是 agents24 仓库中security-scanning插件（目录）下的两个 Agent 之一，与 security-auditor.md 组成"审计—建模"互补体系。其 frontmatter 定义如下：

--- name: threat-modeling-expert description: Expert in threat modeling methodologies, security architecture review, and risk assessment. Masters STRIDE, PASTA, attack trees, and security requirement extraction. Use PROACTIVELY for security architecture reviews, threat identification, or building secure-by-design systems. model: opus ---

从元数据可以看出两个关键事实：其一，它的使用场景被显式标记为PROACTIVE（主动），即只要任务涉及安全架构评审、威胁识别或 secure-by-design 系统构建，编排层就应主动调度该 Agent；其二，它被指定运行在opus模型上，适合承载推理密度较高的安全分析任务。描述中列举了它的方法论武器库：STRIDE、PASTA、攻击树（attack trees）、安全需求提取——这四个方法论在插件的 skills 目录中均有对应实现。

二、Capabilities：七大核心能力域

该 Agent 对外承诺的七项能力（源自 threat-modeling-expert.md）如下：

• STRIDE 威胁分析：按 Spoofing / Tampering / Repudiation / Information Disclosure / DoS / Elevation of Privilege 六类系统化枚举威胁；
• 攻击树构建：以树形结构可视化攻击路径，识别防御缺口；
• 数据流图（DFD）分析：沿数据流而非孤立组件发现信任边界跨越；
• 安全需求提取：把威胁翻译成可测试、可追溯的安全需求；
• 风险优先级排序与评分：基于影响与可能性的乘积给出量化排序；
• 缓解策略设计：为每个威胁设计对应安全控制；
• 安全控制映射：将控制对应到网络、应用、数据、端点、流程等层级。

这些能力并非空洞的标签——每一项都在插件 skills 目录中有完整的方法论文档与可运行模板支撑（详见第四至七节）。

三、适用场景（When to Use）

根据原文档，以下场景应主动调用该 Agent：

• 设计新系统或新功能时：在设计期介入，成本最低；
• 评审架构安全缺口时：对照已知威胁模式审计现有设计；
• 准备安全审计时：为审计提供威胁模型与风险矩阵证据；
• 识别攻击向量时：枚举系统可能被攻破的路径；
• 为安全投入排定优先级时：用风险评分指导预算分配；
• 创建安全文档时：产出可复用的威胁模型文档；
• 培训团队的安全思维时：以结构化方法论统一团队认知。

值得注意的是，在实际插件编排中该 Agent 被用于存量系统的威胁建模。在 security-hardening.md 的 Phase 1 Step 2 中，安全加固编排器在完成漏洞扫描（Step 1）后，会以subagent_type: "threat-modeling-expert"调度它，并传入完整漏洞扫描结果作为上下文，要求其完成 STRIDE 威胁建模、攻击树构建、MITRE ATT&CK 映射与风险优先级排序，输出写入.security-hardening/02-threat-model.md。这说明该 Agent 的输入不应是空白系统——先有漏洞扫描或架构事实，再有威胁建模，是其正确的使用姿势。

四、八步工作流：从范围界定到残余风险记录

原文档给出了威胁建模的完整八步流程，这是整篇方法论的主干：

1. 定义系统范围与信任边界（Define system scope and trust boundaries）
2. 创建数据流图（Create data flow diagrams）
3. 识别资产与入口点（Identify assets and entry points）
4. 对每个组件应用 STRIDE（Apply STRIDE to each component）
5. 为关键路径构建攻击树（Build attack trees for critical paths）
6. 对威胁评分并排序（Score and prioritize threats）
7. 设计缓解措施（Design mitigations）
8. 记录残余风险（Document residual risks）

下面结合插件 skills 中的具体模板，把每一步的落地细节讲透。

4.1 步骤 1–3：范围、信任边界、DFD 与资产清单

信任边界是威胁建模的第一个关键概念。在 stride-analysis-patterns/references/details.md 的威胁模型文档模板中，典型边界划分包括：

• External Boundary（外部边界）：Internet 到 DMZ；
• Internal Boundary（内部边界）：DMZ 到内网；
• Data Boundary（数据边界）：应用层到数据库。

资产清单则用"资产—敏感度—描述"结构化管理，示例包括用户凭证（High）、个人数据（High）、会话数据（Medium）、应用日志（Medium）、配置与密钥（High）。

同文件中的DFDAnalyzer提供了数据流图分析的自动化实现：每个 DFD 元素带trust_level（0 = 不可信，数值越大越可信），find_trust_boundary_crossings()自动找出跨越信任边界的数据流并按信任差排序，analyze_unencrypted_flows()专门标记未加密且跨信任边界的高危数据流，identify_threats_per_element()则按元素类型（外部实体 / 进程 / 数据存储 / 数据流）映射适用的 STRIDE 类别。这套代码直接印证了原文档"Focus on data flows, not just components"的最佳实践——威胁建模的抓手是数据如何流动，而不是组件堆了多高。

4.2 步骤 4：对每个组件应用 STRIDE

STRIDE 是六类威胁的缩写，其完整定义与对应的控制族在 stride-analysis-patterns/SKILL.md 中给出：

S - Spoofing → 认证类威胁（Authentication） T - Tampering → 完整性类威胁（Integrity） R - Repudiation → 不可否认性类威胁（Logging/Audit） I - Info Disclosure→ 机密性类威胁（Encryption） D - DoS → 可用性类威胁（Rate limiting） E - Elevation → 授权类威胁（Authorization）

威胁分析矩阵（逐类自问的关键问题与控制族对应）是原文档与 SKILL.md 共同强调的核心表格，应完整保留：

在 references/details.md 中，每类威胁都有成熟的落地模板。以 Spoofing 为例，其威胁表包括会话劫持（S1，影响 High / 可能性 Medium）、令牌伪造（S2）、撞库攻击（S3），对应缓解项为实施 MFA、安全会话管理、账户锁定策略；Tampering 类则覆盖 SQL 注入（T1，影响 Critical）、参数篡改（T2）、文件上传滥用（T3）。完整的六类威胁表、每类对应的缓解清单，均可直接复制到实际项目的威胁模型文档中。

同文件的StrideAnalyzer类提供了系统化的自动辅助：内置STRIDE_QUESTIONS字典，为每一类威胁预置了 4 个引导性问题（如 Tampering 类包含"数据在传输中能否被修改？""输入校验控制是否充分？"），generate_questionnaire()可为任意组件生成结构化问卷；suggest_mitigations()则为每类威胁返回 5 条推荐缓解措施。Threat数据类还内置了risk_score（= impact × likelihood）与risk_level分级逻辑——这正是工作流第 6 步评分机制的最小实现。

4.3 步骤 5：为关键路径构建攻击树

攻击树把"攻击者想达成什么目标"（根节点）分解为多层子目标与叶子攻击步骤。其结构与节点类型定义在 attack-tree-construction/SKILL.md：

每个攻击叶子节点都应标注四类属性：Cost（成本：$ / $$ / $$$）、Time（时间：小时 / 天 / 周）、Skill（技能：低 / 中 / 高）、Detection（被发现的概率：低 / 中 / 高）。

attack-tree-construction/references/details.md 给出了可运行的攻击树数据模型。核心聚合逻辑体现了攻击树的语义：

• calculate_path_difficulty()：OR 节点取子节点最小值（攻击者会挑最容易的路），AND 节点取最大值；
• calculate_path_cost()：OR 节点取最小值，AND 节点求和；
• find_easiest_path()/find_cheapest_path()/find_stealthiest_path()：分别找出难度最低、成本最低、最不易被发现的三条关键路径；
• get_unmitigated_attacks()：直接列出所有尚未配置缓解措施的叶子攻击——这是防御缺口的快速清单；
• AttackPathAnalyzer.coverage_analysis()：给定已缓解攻击集合，计算被阻断路径占总路径的百分比，量化安全投入的实际覆盖效果；
• prioritize_mitigations()：按"阻断路径数 × 覆盖率影响"对缓解措施排序，指导防御投资优先级。

文件还提供了AttackTreeBuilder流式构建器（goal → or_node → and_node → attack → end → build），并附一个完整的"账户接管（Account Takeover）"示例：将"窃取凭证 / 绕过认证 / 社会工程"作为三个 OR 子目标展开，其中"社会工程"分支下的"账户恢复攻击"是典型的 AND 节点（需要同时完成"收集个人信息"与"致电客服"两个叶子），且三个叶子攻击被分别赋予难度、成本、检测风险属性与缓解措施。此外还提供MermaidExporter与PlantUMLExporter，可将攻击树一键导出为可视化图表用于利益相关方沟通。

4.4 步骤 6：风险评分与排序

风险排序采用"影响 × 可能性"的风险矩阵。在 STRIDE 模板中，评分映射为 4×4 矩阵（Low/Med/High/Crit 各 1–4 分，乘积 1–16 分），并在风险表中有完整示例：

代码层面的分级规则见Threat.risk_level：≥12 为 Critical，≥6 为 High，≥3 为 Medium，其余为 Low。排序之后，模板进一步按时间窗给出处置节奏：立即行动（输入校验框架、认证端点限流、审计日志）、30 天短期（部署带 OWASP 规则集的 WAF、敏感操作启用 MFA、PII 静态加密）、90 天长期（安全意识培训、渗透测试、漏洞赏金计划）——这为第 7 步缓解设计提供了可直接套用的行动编排模板。

4.5 步骤 7：设计缓解措施与步骤 8：记录残余风险

缓解设计遵循 threat-mitigation-mapping/SKILL.md 的三类控制体系：

Preventive（预防性）──► 阻止攻击发生（防火墙、输入校验） Detective（检测性）────► 发现进行中的攻击（IDS、日志监控） Corrective（纠正性）───► 响应并从攻击中恢复（应急响应、备份恢复）

控制按层级分布：Network（防火墙、WAF、DDoS 防护）、Application（输入校验、认证）、Data（加密、访问控制）、Endpoint（EDR、补丁管理）、Process（安全培训、应急响应）。多个层级叠加形成纵深防御（Defense in Depth），其分层示意图在 SKILL.md 中以"洋葱模型"形式给出。

threat-mitigation-mapping/references/details.md 的模板将"缓解"工程化：SecurityControl数据类为每个控制记录control_type、layer、effectiveness、实施成本/维护成本、implementation_status与mitigates_threats，并通过coverage_score()计算"有效性 × 实施状态"的覆盖得分；MitigationMapping.calculate_coverage()给出每个威胁的缓解覆盖率百分比；MitigationPlan.get_gaps()自动识别三类缺口——覆盖不足（<50%）、缺少纵深防御（层级不足 2 层）、控制类型单一（缺少检测/纠正性控制）。

ControlLibrary内置了 12 个标准控制（AUTH-001 MFA、AUTH-002 账户锁定、VAL-001 输入校验框架、VAL-002 WAF、ENC-001 静态加密、ENC-002 TLS、LOG-001 安全事件日志、LOG-002 日志完整性保护、ACC-001 RBAC、AVL-001 限流、AVL-002 DDoS 防护等），每个控制都标注了适用威胁类别、技术栈与合规引用（如 PCI-DSS 8.3、NIST 800-63B、GDPR Art. 32），可直接作为企业控制库的起点。MitigationAnalyzer还提供总体风险削减率计算、关键缺口识别、预算内控制选择（贪心算法按"有效性/成本"比排序）与分阶段实施路线图（Phase 1 处理 Critical 影响威胁，Phase 2 处理 High 影响威胁）。残余风险则体现在MitigationMapping.residual_risk字段中——记录缓解后的剩余风险水平，正是工作流第 8 步的落点。

五、把威胁变成需求：安全需求提取

威胁建模的价值最终要落到可执行的需求上。原文档 Capabilities 中的"安全需求提取"对应 security-requirement-extraction/SKILL.md，其核心链路为：

业务需求 → 安全需求 → 技术控制 "保护客户数据" → "PII 静态加密" → "AES-256 + KMS 密钥轮换"

安全需求分三类：功能性（系统必须做什么，如"系统必须认证用户"）、非功能性（系统必须如何表现，如"认证须在 2 秒内完成"）、约束（施加的限制，如"必须使用经批准的密码库"）。每条需求还应具备四个属性：可追溯性（关联到威胁/合规项）、可测试性、优先级、风险等级。

references/details.md 提供了威胁→需求的自动化转化器RequirementExtractor：内置STRIDE_MAPPINGS，把六类 STRIDE 威胁映射到安全域与需求句式模板（如 Spoofing → 认证域："为 {target} 实施强认证"；Repudiation → 审计日志域："为 {target} 记录所有安全事件"）。_calculate_priority()沿用影响×可能性评分（≥12 Critical，≥6 High，≥3 Medium），_generate_acceptance_criteria()与_generate_test_cases()为每条需求自动生成验收标准与安全测试用例（如 Spoofing 的测试用例包含"会话令牌不可伪造"）。SecurityRequirement.to_user_story()把需求转成带验收标准的标准用户故事格式，RequirementSet.traceability_matrix()生成威胁→需求的追溯矩阵，ComplianceMapper则将需求映射到 PCI-DSS、HIPAA、GDPR、SOC2、NIST CSF、ISO 27001、OWASP 等框架的控制编号，并提供gap_analysis()识别合规缺口（missing_controls / weak_coverage）。"每条需求都必须可追溯到一个威胁"，是这套模板反复强调的铁律。

六、方法论最佳实践：Do's 与 Don'ts

综合原文档与四个 SKILL.md，威胁建模专家的实践准则可归纳如下：

应该做（Do's）：

• 让开发者参与威胁建模会议（原文档核心建议）；
• 聚焦数据流而非孤立组件；考虑内部威胁（insider threats）；
• 架构变化时同步更新威胁模型；把威胁链接到安全需求；
• 把缓解措施跟踪到具体实现；定期评审而非只在设计期做一次（原文档）；
• STRIDE 分析应覆盖全部六个类别、系统化推进、结合 DFD 视觉辅助（stride SKILL）；
• 攻击树应从清晰目标出发、穷举攻击向量、为攻击标注成本/技能/检测属性、用红队专家验证（attack-tree SKILL）；
• 需求提取应做到具体可测、包含验收标准、早期映射合规框架（requirement-extraction SKILL）；
• 缓解映射应覆盖全部威胁、分层叠加控制、混合控制类型、跟踪有效性（mitigation-mapping SKILL）。

不要做（Don'ts）：

• 不要跳过任何 STRIDE 类别（每类都会暴露不同威胁）；不要假设某组件天然安全；不要孤立作业；不要忽视低概率高影响威胁；不要止步于识别而不跟进缓解（stride SKILL）；
• 攻击树不要过度简化、不要忽略 AND 节点依赖、不要忘记内部威胁、不要跳过缓解、不要让它静态化（attack-tree SKILL）；
• "Be secure" 不是需求；不要忽略需求的理由；不要无视优先级；不要忘记可测试性；不要孤立开发需求（requirement-extraction SKILL）；
• 不要依赖单一控制（单点故障）；不要忽视成本（ROI 重要）；不要跳过测试；不要"设置完就不管"；不要只依赖技术而忽略人与流程（mitigation-mapping SKILL）。

七、仓库定位：Agent、Skill、Command 三层联动

threat-modeling-expert并非孤立文件，它处于三层结构中（security-scanning 插件目录）：

• Agent 层：threat-modeling-expert.md（本文主体）与 security-auditor.md（负责漏洞扫描与修复）；
• Skill 层：本文第四至六节引用的四个方法论技能包——stride-analysis-patterns、attack-tree-construction、security-requirement-extraction、threat-mitigation-mapping，每个技能包由 SKILL.md（方法论速查）与 references/details.md（模板与可运行代码）组成；
• Command 层：security-hardening.md（安全加固编排器，四阶段 13 步）与 security-sast.md（多语言 SAST 扫描）。

在security-hardening的编排中，该 Agent 处于评估阶段的承上启下位置：上游读取漏洞扫描结果（01-vulnerability-scan.md），下游为架构评审（Step 3）提供威胁模型输入，其输出必须落盘到.security-hardening/02-threat-model.md供后续步骤读取——这体现了该插件"每步产物落盘、禁止依赖上下文记忆"的强约束设计。若需要先完成静态代码层面的脆弱点识别，可配合 security-sast.md 使用，其中还内置了 SQL 注入、XSS、硬编码密钥、路径穿越、不安全反序列化、命令注入、不安全随机数等七类漏洞的脆弱/安全代码对照与 Bandit、Semgrep、ESLint Security 等工具的配置示例，可作为威胁建模前的"事实输入源"。

八、总结

threat-modeling-expert是 agents24 仓库中方法论密度极高的一个安全 Agent：它以 STRIDE 保证威胁枚举的系统性，以攻击树揭示攻击路径与防御缺口，以风险矩阵实现量化排序，以需求提取把分析结果沉淀为可测试、可追溯的安全需求，以缓解映射把控制落到纵深防御的各层，最终以残余风险记录完成闭环。配合插件的四个技能包（SKILL.md + references/details.md 双文件结构）与security-hardening命令编排，这套方法论既能驱动 Agent 完成自动化安全评审，也能作为团队威胁建模的标准化参考模板直接复制使用——无论你是在设计新系统、审计存量架构还是准备安全合规评审，这八步流程与配套模板都足以支撑一场结构化的安全分析。

【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents