tools-only 内容摘要
在当前，软件工程正在经历一个重大的时代变革，从瀑布式开发、敏捷迭代到 AI 辅助编程，从研发理念到流程到技术都面临巨大的变化。在此过程中，安全领域的工作也同样面临适应性调整的需求，安全工程的实施路径从"文档驱动、阶段割裂"转向"代码驱动、验证闭环"，从"门限卡口、工具外置"转向"极致左移、快速迭代"。
第一章 传统软件生命周期中SDL与研发安全流程的定位
1.1 安全开发生命周期（SDL）的理论与实践
传统的安全开发生命周期（Security Development Lifecycle, SDL）的核心理念是将安全性嵌入软件开发的各个阶段。这一方法论起源于 2002 年微软应对 Code Red、Nimda 等蠕虫病毒后启动的"可信计算"（Trustworthy Computing）计划。当时的核心观点是：安全性需要从设计之初内建于产品中，而非事后补救。
在理论化的 SDL 模型中，各阶段承担不同的安全职责：
需求分析阶段：团队梳理合规性需求（如数据保护法规、行业安全标准）并定义安全特性（如是否需要身份和权限的隔离、加密算法强度、认证机制种类、审计日志功能）。由于此阶段缺乏具体系统设计，安全工作主要停留在原则性声明层面。
设计阶段：SDL 理论中威胁建模（Threat Modeling）的主要应用阶段。架构师与安全专家对照系统架构图，试图在编码前识别潜在设计缺陷。典型的威胁建模方法例如微软的 STRIDE 模型即为此阶段设计的重要方法论。
实施阶段：引入静态代码分析（SAST）和安全编码规范。具备经验的开发人员通过安全编码规范来执行安全的设计模式，IDE通过安全插件进行实时漏洞模式检测，SAST工具在必要的阶段节点进行定期弱点扫描。但这些工具本质上是模式匹配器，能捕获特定危险模式（如 strcpy 的不安全使用），但难以评估代码在业务流程中的实际风险，尤其是复杂的业务逻辑风险。
验证阶段：动态应用安全测试（DAST）、交互式应用安全测试（IAST）及人工渗透测试在此阶段执行。这些技术虽然能发现实际问题，但在产品接近完成时发现的缺陷修复成本较高，实际的执行过程往往也由于岗位立场缘故使研发人员和安全人员陷入对立和纠葛当中。
发布与响应阶段：运行时监控、安全事件响应、漏洞补丁发布。此阶段发现的问题源于设计阶段的威胁识别存在覆盖不足，同时漏洞的修复成本和衍生风险都被显著放大。
1.2 传统开发流程中安全活动的嵌入点
理解传统 SDL 的设计假设，需要分析传统开发流程的时间分布特征：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 传统软件开发流程的时间分布 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 需求分析 设计 实施（编码） 验证（测试） 发布 │
│ ├──────────┼─────────────┼───────────────────────┼─────────────────────────┼────┤ │
│ │ 15% │ 20% │ 30% │ 30% │ 5% │ │
│ │ │ │ │ │ │ │
│ │ │ │ ┌───────────────────────────────────┐ │ │ │
│ │ │ │ │ 主要迭代周期（编码↔测试） │ │ │ │
│ │ │ │ │ 占整体研发时间的 60%+ │ │ │ │
│ │ │ │ └───────────────────────────────────┘ │ │ │
│ │ │ │ │ │ │ │
│ ├──────────┼─────────────┼───────────────────────┼─────────────────────────┼────┤ │
│ │ │ 威胁建模 │ SAST/代码审查 │ IAST/DAST/渗透测试/安全测试│ │ │
│ │ │ (理论位置) │ │ (实际安全工作嵌入点) │ │ │
│ │ │ │ │ │ │ │
│ └──────────┴─────────────┴───────────────────────┴─────────────────────────┴────┘ │
│ │
│ 关键观察： │
│ ───────────────────────────────────────────────────────────────────────────── │
│ • 威胁建模理论上应在设计阶段进行，但由于可执行性与信息的匮乏，实际常被推迟至测试阶段执行 │
│ • 验证阶段（测试）提供了充足的时间窗口，成为安全工作的主要嵌入点 │
│ • 安全测试、渗透测试、合规审计等重投入活动在此阶段执行 │
│ • 在传统研发生命周期中，这种模式"验证阶段"的时间buff足够长，能容纳安全活动的时间和人力投入 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
基于传统的软件工程方法而建立的传统 SDL 模型的一项假设是：开发流程存在明确的阶段边界，安全活动可在特定阶段执行。尤其是验证阶段，由于其较长的时间跨度和明确的质量门禁角色，成为安全工作的主要嵌入点。
1.3 STRIDE 威胁建模方法概述
威胁建模过程中常用的 STRIDE 模型由微软工程师 Loren Kohnfelder 和 Praerit Garg 于 1999 年提出，包含六种威胁类别：
| 类别 | 全称 | 定义 | 典型防护机制 |
|---|---|---|---|
| S | Spoofing (仿冒) | 假冒他人身份获取非法访问 | 认证、数字签名、多因素验证 |
| T | Tampering (篡改) | 未授权修改数据或代码 | 完整性校验、数字签名、审计日志 |
| R | Repudiation (抵赖) | 否认已执行的操作 | 审计日志、时间戳、不可否认性签名 |
| I | Information Disclosure (信息泄露) | 敏感信息暴露给未授权方 | 加密、访问控制、数据脱敏 |
| D | Denial of Service (拒绝服务) | 使合法用户无法访问服务 | 资源限流、冗余设计、故障转移 |
| E | Elevation of Privilege (权限提升) | 以低权限身份获取高权限 | 最小权限原则、沙箱隔离、边界验证 |
STRIDE 的设计目标是提供一个结构化思考框架，帮助非安全专家系统性地审视设计中的潜在威胁。
传统 STRIDE 实践流程：
- 数据流图（DFD）绘制：将系统分解为外部实体、处理过程、数据存储和数据流四类元素，并标注信任边界
- 逐元素威胁枚举：针对 DFD 中的每个元素和交互，依据 STRIDE 模型系统性地提问
- 缓解措施设计：为识别出的威胁设计对应的安全控制
1.4 理论与实践的差异分析
STRIDE的方法论指南与微软官方文档指出，威胁建模"在设计阶段进行时最为有效"。然而，行业实践观察表明：设计阶段的威胁建模的理论模型在多数组织中存在实施障碍。
STRIDE落地的难点主要存在以下几点原因：
首先，"设计阶段"在现代开发中边界模糊。在敏捷开发环境下，设计与实现高度交织。Sprint 1 完成的模块设计可能在 Sprint 3 因需求变更而调整，导致原有威胁模型失效。
其次，有效的 STRIDE 分析需要具体的设计信息。抽象架构图（如"用户 → 负载均衡 → Web 服务器 → 数据库"）难以支撑有意义的威胁分析。只有具备具体实现细节（如"使用 JWT 进行会话管理"、"数据库存储明文密码"）时，威胁枚举才能产生实质性结论。这些细节通常在实现阶段才会确定。
最后，资源约束是关键的瓶颈（以及带来的显著成本提升）。有效的 STRIDE 分析需要架构师、开发者和安全专家的协同参与，在快节奏产品开发中难以为每个设计决策召开威胁建模的分析和决策会议。从业界实际执行的经验来看，在产品研发过程中，完整的落地威胁建模相关工作带来的直接成本损耗达到软件整体的3-5%。
常见的替代实践模式：
由于传统SDL及威胁建模本身存在的诸多制约因素和问题，行业在实际执行中往往采用其他一些简化或替代的执行路径：
- 实现阶段威胁建模：在代码编写期间或之后（测试阶段）进行，此时有更具体的系统信息可供分析；这也是最常见的实际场景。
- Sprint 级增量威胁建模：在敏捷环境中，将威胁建模拆解为每个 Sprint 的固定活动
- 开发者驱动的轻量级检查：用 STRIDE 思想编制简化清单，由开发者在代码审查时自行对照检查
- 威胁建模即代码：使用 pytm、threagile 等工具，将威胁模型以代码形式定义
1.5 代码审查的局限性分析
代码审查是传统SDL中另一项重要的门限安全控制机制，如果威胁建模是宏观层面的架构审计，代码审查（Code Review）则是微观层面的实现检验。在传统 SDL 中，Code Review 位于实施阶段尾声或 CI 流水线关口。
然而现实中，代码审查存在以下在具体实施上的限制与困境：
上下文限制是主要障碍。在微服务架构中，完整业务流程可能跨越多个服务、涉及多次 RPC 调用。审查者面对的是单次提交的 Diff（几十到几百行代码变更），难以构建跨越数千行代码的完整调用链路。一个看似完备的输入验证函数，如果位于错误的信任边界之后，则无法发挥防御作用。
认知负荷限制审查深度。研究表明，代码审查的有效性在超过 200-400 行代码后显著下降。审查者易发现语法错误或显式注入漏洞，但难以察觉架构违规、时序竞争条件或业务逻辑缺陷。
| 维度 | 传统 STRIDE 威胁建模 | 传统代码审查 |
|---|---|---|
| 分析对象 | 设计文档、架构图、DFD | 代码变更（Diff/PR） |
| 理论阶段 | 设计阶段（早期） | 开发阶段（中后期） |
| 实际阶段 | 常被推迟或省略 | CI 流水线关口 |
| 核心限制 | 抽象与实现脱节，设计信息不足 | 上下文缺失，认知负荷 |
| 依赖资源 | 架构与攻防复合专家 | 开发者个体安全意识 |
| 输出形式 | 静态文档、风险列表 | 代码评论、修改建议 |
| 验证能力 | 弱（难以自动化验证） | 中（可通过测试验证，覆盖率有限） |
第二章 传统SDL方法的困境：认知瓶颈与验证缺口
2.1 文档与代码的同步性/一致性问题
传统 STRIDE 分析以设计文档或架构图为起点，但是软件的迭代与开发是动态演进过程，设计文档在编码初期即开始与实际代码产生偏差（Implementation Drift），伴随工程规模的扩大和代码的变更增长，之间的同步性差异越来越大。
典型示例：安全团队在 Q1 基于架构师提供的设计文档进行威胁建模，识别 15 项高风险威胁。到 Q3 产品上线时，开发过程中的技术债务、架构调整和需求变更使实际系统与当初设计存在显著差异，版本之间的差异使得人工预设的“威胁模型”与现实真实运行的系统实例之间存在“阴影区域”。
部分高风险漏洞恰恰产生于设计与实现的差异中。例如，设计文档规定"所有 API 调用必须经过认证中间件"，但实际实现中可能存在绕过认证的调试端点，这类问题在静态设计文档分析中经常是被忽略的。
2.2 专家资源的可用性限制
有效的 STRIDE 分析需要系统架构理解能力和攻防实战经验，以评估 API 端点的权限提升风险为例，分析者需了解：
- Web 框架认证中间件实现机制
- JWT 令牌的常见签名弱点（如算法混淆攻击）
- RBAC/ABAC 访问控制模型的实现陷阱
- 相关历史漏洞（如 CVE-2015-9235 JWT None 算法漏洞）
具备"架构视野 + 攻防深度"复合能力的专家在行业中供给有限。缺乏合格人员以及充沛的工作时间资源分配时，威胁建模和代码审计都常常退化为形式主义的检查清单填写。
2.3 验证闭环的缺失
传统 STRIDE 的产出是静态威胁列表和缓解建议。开发团队进行修复后，安全团队如何验证修复有效性？
现有方法普遍缺乏低成本、可自动化的验证机制。威胁建模产出的是描述性内容（"此处存在 SQL 注入风险"），而非可执行测试用例（"使用 ' OR 1=1 -- payload 测试此端点"）。识别-修复-验证链条的断裂使已知风险可能长期存在于系统中。
2.4 STRIDE 对实现信息的依赖性
当缺乏详细分层设计和代码实现时，STRIDE 分析能否产生有意义的结论？
传统的静态STRIDE分析还存在一个问题，就是安全设计-评估-控制-验证的脱节，"该框架主要在概念设计阶段进行理论威胁分析，而非在产品发布后的安全评估阶段。"STRIDE 设计假设分析者拥有足够具体的系统信息，信息不足时，分析趋于抽象化——可以说"用户认证模块可能存在仿冒威胁"，但无法指出具体攻击路径或漏洞位置。
2.5 流程嵌入点的隐性依赖
传统 SDL 和 STRIDE 方法论存在一个潜在性假设条件：开发流程存在足够长的验证阶段，为安全活动提供时间窗口。
在传统开发模式中：
- 编码与测试分离：开发者编写代码，测试团队独立执行测试
- 测试阶段时间充足：验证阶段通常占项目周期的 25-35%
- 安全活动可嵌入测试阶段：渗透测试、安全审计、合规检查在此阶段执行
这种模式下，即使威胁建模未能在设计阶段完成，安全团队仍有机会在测试阶段进行补救——执行安全测试、发现漏洞、要求修复。测试阶段成为安全工作的"缓冲区"。
然而，这一假设在新的开发范式下面临挑战（详见第三章）。
传统威胁建模面临时机选择困境：
- 过早实施：设计信息不足，分析流于抽象
- 过晚实施：修复成本较高，错过早期干预时机
- 持续实施：缺乏自动化支持，人工成本难以承受
第三章 AI 辅助编程的带来的变革和安全影响：开发主循环阶段的结构性左移
3.1 编程范式变化与开发主循环的重构
AI 辅助编程工具（如 GitHub Copilot、Claude Code）改变了软件开发的工作模式。这些工具将代码生成的边际成本显著降低，开发者从逐字符编码转变为描述意图并审查 AI 生成结果。此角色转变带来开发速度和代码体积、复杂度的显著增长。
更为强大和智能的AI辅助编程工具对于整个软件生态带来的更深层的影响在于：开发流程的主循环发生了结构性左移。
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 开发主循环的结构性左移：传统模式 vs AI 辅助模式 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【传统开发模式】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ 需求分析 ──► 设计 ──────► 编码 ◄───────────────────► 测试 ──► 发布 │
│ 15% 20% │ │ 5% │
│ │ 主循环（60%） │ │
│ │ ┌─────────────────────────┐│ │
│ └───►│ 编码 ↔ 测试迭代 │◄┘ │
│ │ （人工编码 + 独立测试） │ │
│ └─────────────────────────┘ │
│ ▲ │
│ │ │
│ 安全工作嵌入点：测试阶段 │
│ • 充足的时间窗口 │
│ • 明确的阶段边界 │
│ • 可容纳重投入活动 │
│ │
│ ═══════════════════════════════════════════════════════════════════════════════════ │
│ │
│ 【AI 辅助开发模式 (Vibe Coding)】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ 需求/意图 ◄─────────────────────────────────► 代码生成 ──► 发布 │
│ │ 主循环（70%+） │ 5% │
│ │ ┌─────────────────────────────────┐ │ │
│ └────────►│ 需求/设计 ↔ 代码+测试 │◄┘ │
│ │ （意图描述 → AI 生成 → 审查） │ │
│ │ 测试嵌入编码，非独立阶段 │ │
│ └─────────────────────────────────┘ │
│ ▲ │
│ │ │
│ 传统安全工作嵌入点？ │
│ • 测试阶段被压缩/消失 │
│ • 阶段边界模糊化 │
│ • 无法容纳长周期安全活动 │
│ │
│ ═══════════════════════════════════════════════════════════════════════════════════ │
│ │
│ 【结构性变化分析】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ ┌────────────────┬────────────────────┬────────────────────────────────────────┐ │
│ │ 维度 │ 传统模式 │ AI 辅助模式 │ │
│ ├────────────────┼────────────────────┼────────────────────────────────────────┤ │
│ │ 主循环位置 │ 编码 ↔ 测试 │ 需求/设计 ↔ 代码 │ │
│ │ 测试阶段 │ 独立阶段，时间充足 │ 嵌入编码过程，自动化执行 │ │
│ │ 阶段边界 │ 明确 │ 模糊化 │ │
│ │ 迭代周期 │ 天/周级 │ 分钟/小时级 │ │
│ │ 安全嵌入点 │ 测试阶段（明确） │ 消失或碎片化 │ │
│ │ 安全工作模式 │ 批量、周期性 │ 需要实时、持续 │ │
│ └────────────────┴────────────────────┴────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
即将到来的变革：开发主循环从"编码↔测试"左移到"需求/设计↔代码"
在传统模式中，开发者的主要工作是编写代码并通过测试验证。编码和测试是两个相对独立的活动，由不同的人员或在不同的时间执行。这种分离为安全工作提供了自然的嵌入点——在测试阶段，安全团队有时间和机会执行威胁建模、渗透测试和安全审计。
在 AI 辅助模式（Vibe Coding）中：
- 编码成本大幅降低：开发者描述意图，AI 生成代码
- 测试融入编码过程：AI 生成的代码通常包含测试，或开发者立即运行测试验证
- 主循环左移：开发者的主要工作变成了"描述需求/设计"和"审查/调整 AI 生成的代码"
- 传统测试阶段压缩：独立的、长周期的测试阶段被压缩甚至消失
这种结构性变化导致：传统安全工作失去了合适的流程嵌入点和卡口位置。
3.2 安全工作流程嵌入的危机
传统安全活动的设计假设是：存在一个足够长的阶段（通常是测试阶段），能够容纳以下工作：
| 安全活动 | 典型时间投入 | 传统嵌入点 | AI 辅助模式下的状态 |
|---|---|---|---|
| 威胁建模 | 1-3 天/模块 | 设计/测试阶段 | 阶段边界模糊，难以安排 |
| 安全代码审查 | 2-4 小时/PR | 开发阶段 | 代码生成速度超过审查能力 |
| 渗透测试 | 1-4 周/系统 | 测试阶段 | 测试阶段被压缩 |
| 安全审计 | 2-4 周/项目 | 发布前 | 发布周期压缩 |
| 合规检查 | 1-2 周/项目 | 测试/发布阶段 | 无足够时间窗口 |
当开发主循环左移后，这些依赖"测试阶段时间窗口"的安全活动面临结构性挑战：
- 时间窗口消失：大量测试自动化以及流程和编码过程的进一步融合，不再有完整的"测试阶段"
- 速度不匹配：AI 在分钟内生成模块，传统安全活动需要天/周
- 流程断裂：安全活动找不到合适的嵌入点
- 人力瓶颈：安全专家无法跟上代码生成的速度
3.3 安全响应速度的结构性差距
传统安全流程基于人工编码速度设计。威胁建模会议需要数小时专家讨论；SAST 扫描报告需要数天人工审核；渗透测试周期以周计。在过去的编码速度下，这些周期是可接受的。
当 AI 将编码速度提升一个数量级时，安全手段的响应速度差距变得显著：
- 实时性不足：当 AI 在数分钟内生成新模块时，传统"召集专家、安排会议、绘制白板"式威胁建模流程无法嵌入 CI/CD 流水线
- AI 生成风险：AI 可能"幻觉"出不存在的依赖包（Package Hallucination），或复用训练数据中过时、脆弱的代码模式（如硬编码凭据、已弃用的加密算法）
- 业务逻辑理解差距：AI 生成的代码在语法层面可能正确，但在业务逻辑层面可能存在缺陷（例如，正确实现支付扣款逻辑，但忽略金额为负数的边界情况）
3.4 代码复杂度的非线性增长
这种生产效率提升伴随安全相关成本：代码复杂度的非线性增长。
AI 模型倾向于生成结构完整、功能齐全的代码，但可能引入开发者未完全理解的库、模式和依赖。一个需求可能生成数百行代码，涉及多个第三方库交互。系统攻击面被扩大，而开发者对其中的安全隐患可能缺乏认知。
3.5 传统威胁建模面临的系统性挑战
综合以上分析，传统 STRIDE 和威胁建模方法在 AI 辅助编程环境下面临的挑战可归纳为：
| 挑战维度 | 具体表现 | 根本原因 |
|---|---|---|
| 流程嵌入危机 | 找不到合适的执行时机 | 开发主循环左移，测试阶段压缩 |
| 速度不匹配 | 分析速度远低于生成速度 | 人工驱动 vs AI 驱动 |
| 专家瓶颈 | 专家数量无法匹配代码增长 | 安全人才供给有限 |
| 方法论过时 | 假设前提（阶段分离）不再成立 | 基于传统开发流程设计 |
核心问题：传统威胁建模方法论是为"有明确阶段边界的开发流程"设计的。当这一前提被 AI 辅助编程颠覆后，方法论本身需要重构，而非简单加速。
安全体系需具备与 AI 生成能力相匹配的响应速度和理解深度——这正是 skill-threat-modeling 项目的设计目标。
第四章 Skill-threat-modeling 的架构与设计原则
设计理念：LLM 自主驱动与"Context, not Control"原则
为了应对Vibe Coding带来的研发变革浪潮和新的挑战，我们设计了这个名为skill-threat-modeling的自动化工具集。skill-threat-modeling是一套开放式的Agent Skillset，也极易转化为等效的Agent工作流运行，核心的知识库体系也能为其他AI驱动的系统进行补充和支持。
skill-threat-modeling 的核心设计理念可概括为：LLM 自主驱动，上下文赋能，开放式工作流，集成知识体系。这一理念区别于传统安全工具的"规则驱动、强制约束"模式。
传统安全工具通常采用"控制"（Control）范式：预定义检测规则、强制执行流程、输出固定格式报告。工具的能力边界由规则库的覆盖范围决定。这种模式在处理已知模式时有效，但面对新型攻击向量或复杂业务逻辑时常常存在局限。
skill-threat-modeling 采用知识库引导的意图感知上下文（Context）范式：明确目标和意图，提供信息参考和指导，而非严格控制流程。其核心理念是：
- LLM 具备推理能力：Claude 等大语言模型具有代码理解、逻辑推理和攻击路径构建能力。Skill 的作用不是替代这些能力，而是增强和引导；
- 上下文定义目标：每个阶段的 Skill 提供该阶段的意图定义、知识参考和输出期望，而非逐步操作指令；
- 知识库赋能决策：安全知识库（CWE、CAPEC、ATT&CK 等）作为参考资源供 LLM 灵活查询和引用，而非强制映射规则；
"Context, not Control"原则的实践含义：
| 维度 | Control 模式 | Context 模式 |
|---|---|---|
| 执行逻辑 | 预定义规则驱动 | LLM 推理驱动 |
| 流程约束 | 强制步骤序列 | 阶段目标导向 |
| 知识应用 | 规则库匹配 | 知识库查询参考 |
| 输出格式 | 固定模板 | 结构化但灵活 |
| 扩展能力 | 依赖规则更新 | 依赖 LLM 推理 |
这一设计使 skill-threat-modeling 能够适应各种技术栈和业务场景。例如，面对一个使用非主流框架的项目，传统基于规则的工具可能因缺乏对应规则而失效；而基于 Context 模式的 Skill 可通过 LLM 对代码的语义理解完成分析。
skill-threat-modeling 项目的核心基于第一性原理（First Principles）进行架构设计，即剥离既有形式，分析问题本质。
4.1 应对开发主循环左移的设计策略
基于第三章的分析，skill-threat-modeling 针对"开发主循环左移"问题提出以下设计策略：
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ skill-threat-modeling 应对开发主循环左移的设计策略 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【传统安全工作的问题】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ • 依赖独立的测试阶段作为嵌入点 │
│ • 人工驱动，响应速度慢 │
│ • 批量执行，无法持续 │
│ • 与开发流程脱节 │
│ │
│ 【skill-threat-modeling 的设计应对】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ 策略 1: 与代码同步（Code-First） │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • 直接分析源代码，而非等待设计文档 │ │
│ │ • 威胁建模可在代码生成后立即执行 │ │
│ │ • 不依赖独立的测试阶段 │ │
│ │ • 可嵌入 AI 编程环境的实时工作流 │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ 策略 2: AI 驱动分析（LLM Autonomous） │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • 用 AI 分析 AI 生成的代码 │ │
│ │ • 响应速度与代码生成速度匹配 │ │
│ │ • 无需人工专家全程参与 │ │
│ │ • 可自动化、可持续执行 │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ 策略 3: 融入新主循环（Integrated Workflow） │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • 适应"需求/设计 ↔ 代码"的新主循环 │ │
│ │ • 可在代码生成后立即触发 │ │
│ │ • 支持增量分析和持续威胁建模 │ │
│ │ • 输出可直接指导下一轮代码生成 │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ 策略 4: 知识密度提升（Knowledge Density） │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • 将分散的安全专家知识编码为结构化强逻辑的知识库 │ │
│ │ • 降低对稀缺专家经验的依赖 │ │
│ │ • 通过知识复用提升分析效率 │ │
│ │ • 保证分析质量的一致性 │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ 【新的安全工作嵌入模式】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ 需求/意图 ◄───────────────────────────────► 代码生成 ──► 发布 │
│ │ 主循环 │ │
│ │ ┌─────────────────────────────────┐│ │
│ └────────►│ 需求/设计 ↔ 代码+测试 │◄┘ │
│ │ ▲ │ │ │
│ │ │ │ │ │
│ │ │ ▼ │ │
│ │ ┌────────────────────┐ │ │
│ │ │ skill-threat- │ │ │
│ │ │ modeling │ │ │
│ │ │ (实时/持续威胁分析) │ │ │
│ │ └────────────────────┘ │ │
│ └─────────────────────────────────┘ │
│ │
│ 安全工作嵌入点：与代码生成同步，融入主循环 │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
4.2 代码作为优先分析对象（Code-First 原则）
传统威胁建模的主要问题在于分析对象（设计文档）与实际系统（运行代码）的脱节。代码本身是系统状态的唯一真实来源（Single Source of Truth）。
由此推论：所有架构图、数据流图（DFD）和信任边界应是代码的实时映射——从代码推导的衍生信息，而非人工绘制的静态图像。代码变化时，衍生信息应自动更新。
skill-threat-modeling 不依赖用户提供的设计文档，而是直接扫描项目源码。通过代码阅读、依赖分析和语义理解，系统逆向生成反映当前代码状态的架构模型。威胁建模成为可随每次代码提交自动刷新的持续过程。
注意：Code-First ≠ Code-Only
此处需要明确：Code-First 是优先级声明，不是排他性约束。
skill-threat-modeling 将代码作为优先和核心分析对象，但并非唯一输入。该 Skill 同样支持以下输入形态：
输入类型 适用场景 分析方式 源代码 已有代码库的安全评估 直接代码分析（主要模式） 需求文档 设计阶段前置威胁建模 基于需求推导威胁场景 架构设计文档 概要设计安全审查 基于设计进行 STRIDE 分析 流程图/时序图 业务逻辑安全分析 基于流程进行数据流威胁分析 IaC 配置 云基础设施安全评估 基于配置进行安全配置审计 API 规范（OpenAPI） 接口安全设计审查 基于接口定义进行威胁枚举 面向软件定义一切 数据化和软件化形式化表达 面向可数据化表达的开放式未来 Code-First 的核心含义：当代码可用时，优先基于代码进行分析，因为代码是系统状态的真实来源；当代码不可用时（如设计阶段），Skill 同样能够基于其他形式的输入进行威胁分析。
这种灵活性使 skill-threat-modeling 可嵌入软件开发的任何阶段：
- 设计阶段：基于需求和架构文档进行前置威胁建模
- 开发阶段：基于代码进行实时威胁分析
- 部署阶段：基于 IaC 配置进行基础设施安全审计
- 运维阶段：基于现有系统实例的运行状态切片进行安全评估
4.3 上下文的核心作用
安全漏洞的本质往往是上下文错位和信任关系传递失效。例如将用户输入直接打印到日志文件，在本地调试模式下可能是功能特性，但在生产环境中构成信息泄露漏洞。相同代码在不同信任边界内有不同安全含义。
大语言模型（LLM）的核心优势在于上下文窗口和强大的归纳/推理能力。skill-threat-modeling 确立"上下文累积"和"阶段性披露"原则：安全分析须是多阶段（Multi-Phase）推理过程。
从项目全貌理解（"这是 Django Web 应用"），到组件交互分析（"用户认证模块使用 JWT"），再到具体代码行审查（"此处 verify=False 禁用了签名验证"）——上下文在各阶段间流动、继承和增强。完整上下文使 AI Agent 能准确判断特定行为是否构成实际威胁。
4.4 验证作为价值标准
安全领域存在误报（False Positives）问题。传统 SAST 工具可能报告数千个"潜在问题"，其中多数是误报或无法实际利用的理论风险。开发者产生"警报疲劳"。
skill-threat-modeling 引入"验证即价值"原理：无法被验证的威胁是噪音，只有能证明可利用性的风险才有实际意义。
系统不仅要求识别威胁，更要求为每个高风险项生成证据链——具体攻击路径（Attack Path）和概念验证（POC）。如果推断的威胁无法构建可行攻击链，其在最终报告中的优先级将被降级或排除。
这改变了安全工具的交付标准：从"报告问题"转变为"证明问题"。
持续增强验证模块也是skill-threat-modeling未来演进的主要优化方向。
4.5 模块化能力编排
面对复杂安全分析任务，单一通用模型难以适应所有场景。skill-threat-modeling 将安全专家能力解耦为原子的、可复用的技能模块。
"绘制 DFD"是一项技能，"查询 CWE 数据库"是一项技能，"构建 SQL 注入 Payload"也是一项技能。通过技能模块化和 Claude Code 动态编排，系统能够适应各种技术栈（Java/Python/Go）和业务场景（金融支付/医疗健康/工业控制）。
事实上，skill-threat-modeling的核心技术，是把软件安全工程相关的知识体系，通过LLM易于理解的结构和语言（包括内置的embeding），建立了一套独立的逻辑和知识体系，并且赋予LLM随时根据上下文灵活理解的能力，是LLM的安全专家外脑。
4.6 流程约束、知识库与 LLM 自主决策的关系
理解 skill-threat-modeling 的设计，需要厘清三个核心组件的关系：
┌─────────────────────────────────────────────────────────────────────────────────┐
│ 流程约束、知识库与 LLM 决策的协同模型 │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ 8 阶段工作流（流程约束） │ │
│ │ │ │
│ │ 功能：提供必要的路径规范，确保分析完整性和输出一致性 │ │
│ │ 性质：阶段边界和输出格式约束，非强制步骤指令 │ │
│ │ 类比：导航系统提供路线规划，驾驶决策由司机（LLM）自主完成 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 定义阶段目标 │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ LLM 自主决策引擎 │ │
│ │ │ │
│ │ • 代码语义理解：理解业务逻辑和数据流 │ │
│ │ • 威胁推理：基于上下文推导攻击向量 │ │
│ │ • 路径构建：设计攻击链和 POC │ │
│ │ • 优先级判断：评估风险严重性和可利用性 │ │
│ │ • 缓解建议：生成技术栈特定的修复方案 │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ 提供知识参考 │
│ │ │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ 双轨知识体系（知识库） │ │
│ │ │ │
│ │ 功能：提供分析和决策所需的安全知识，非标准操作程序（SOP） │ │
│ │ 内容：CWE/CAPEC/ATT&CK/CVE、安全控制集、验证集 │ │
│ │ 性质：参考资源，由 LLM 按需查询和应用 │ │
│ │ 类比：专家顾问提供知识咨询，决策由操作者（LLM）自主完成 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ═══════════════════════════════════════════════════════════════════════════ │
│ │
│ 设计原则总结： │
│ ───────────────────────────────────────────────────────────────────────── │
│ • 流程约束提供"应该做什么"（What），不强制"如何做"（How） │
│ • 知识库提供"可以参考什么"（Reference），一般不规定"必须遵循什么"（Mandate） │
│ • LLM 在约束和知识的支持下，自主完成理解、推理、决策和生成 │
│ • 这种设计使 Skill 能够适应 LLM 能力的持续提升 │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
设计理念核心：
流程约束不是 SOP：8 阶段工作流定义的是分析的逻辑边界和输出规范，而非逐步操作指令。LLM 在每个阶段内有充分的自主空间决定分析方法和深度。
知识库不是规则库：双轨知识体系提供的是结构化安全知识，而非强制匹配规则。LLM 根据上下文判断需要查询哪些知识、如何应用这些知识。
LLM 是决策主体：所有实质性的安全判断——代码是否存在漏洞、攻击路径是否可行、修复方案是否有效——都由 LLM 基于上下文和知识完成。
这种设计的优势在于：随着 LLM 能力的提升，Skill 的分析质量同步提升，无需频繁更新规则库或重构流程。
第五章 安全工程系统8阶段工作流：从宏观分析到微观验证
5.1 设计目标
skill-threat-modeling 的另一核心设计是针对传统方法的核心问题定义了一套简单易用的工程化方法：
- 全自动化深度风险分析：无需人工干预，完成从代码理解、架构还原、威胁识别到风险验证的全过程，可嵌入 CI/CD 流水线；
- 低误报率：通过多重验证逻辑和去重算法，报告中的每项风险都有证据支撑；
- 知识可追溯性与标准化：所有发现能追溯到权威安全标准（CWE, CAPEC, ATT&CK），并提供与具体技术栈匹配的修复建议；
- AI 编程环境集成：可集成到 Claude Code 等 AI 编程环境，实时审计 AI 生成代码；
5.2 skill-threat-modeling 八阶段工作流详述
skill-threat-modeling 采用从宏观到微观、层层递进的 8 阶段严格顺序执行工作流。
┌────────────────────────────────────────────────────────────────────────────────────┐
│ 8-Phase Workflow Pipeline │
├────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 ... │
│ Project ──► Call Flow ──► Trust ──► Security ──► STRIDE ──► Risk ──► │
│ Understanding DFD Boundaries Design Analysis Validation │
│ │
│ │ │ │
│ └──────────── Context Accumulation ────────────────────────────┘ │
│ │
│ ... Phase 7 Phase 8 │
│ ──► Mitigation ──► Report │
│ Planning Generation │
│ │
└────────────────────────────────────────────────────────────────────────────────────┘
Phase 1: Project Understanding (项目理解)
建立对目标系统的全局认知。
- 输入：项目源代码根目录（或需求文档、架构设计文档等替代输入）
- 核心动作：
- 扫描文件结构，识别编程语言和技术栈
- 分析框架特征（Django/Spring Boot/Express 等）
- 提取依赖声明（package.json/requirements.txt/pom.xml）
- 定位关键入口点（main 函数、路由注册、事件处理器）
- 产出：
P1-PROJECT-UNDERSTANDING.md，包含技术栈指纹、核心组件列表及初步安全观察 - 功能价值：为后续阶段建立基线上下文
Phase 2: DFD Analysis (数据流图逆向)
从代码中逆向生成数据流图。
- 输入：P1 产出 + 源代码
- 核心动作：
- 追踪数据在组件间的流动路径
- 识别外部实体（用户、第三方 API）、处理过程（业务逻辑模块）、数据存储（数据库、缓存、文件系统）
- 绘制数据流及其携带的信息类型
- 产出：
P2-DFD-ANALYSIS.md，包含 Mermaid 格式的 DFD 图及数据流风险标注 - 功能价值：将代码转化为可供 STRIDE 分析的架构视图
Phase 3: Trust Boundary Analysis (信任边界界定)
信任边界是安全分析的关键要素——跨越边界的数据流是攻击者的常见入口点。
- 输入：P2 产出 + 源代码
- 核心动作：
- 识别信任边界（互联网 ↔ DMZ、前端 ↔ 后端、用户空间 ↔ 内核空间）
- 分析数据穿越边界时的净化和验证机制
- 标记未受保护或保护不足的边界穿越点
- 产出：
P3-TRUST-BOUNDARY.md，含带边界标注的架构图和未保护穿越点清单 - 功能价值：为后续 STRIDE 分析提供攻击面地图
Phase 4: Security Design Review (安全设计审查)
在分析具体漏洞之前，评估系统的安全机制设计。
- 输入：P1-P3 产出
- 核心动作：
- 对照 11 项安全原则（纵深防御、最小权限、零信任等）审查架构设计
- 评估认证/授权/审计/加密等核心安全功能的实现状态
- 识别架构层面的系统性缺陷
- 产出：
P4-SECURITY-DESIGN-REVIEW.md，包含安全能力覆盖矩阵和架构级差距分析 - 功能价值：发现代码审查难以发现的系统性设计缺陷
Phase 5: STRIDE Threats (自动化威胁枚举)
STRIDE 方法论的自动化实现——将 DFD 中的每个元素和交互映射到六种威胁类别。
- 输入：P2（DFD）+ P3（信任边界）
- 核心动作：
- 对 DFD 中的每个元素（Process/DataStore/DataFlow）应用 STRIDE 矩阵
- 系统性生成威胁问题
- 为每个威胁分配唯一标识符（如
T-S-P01-001）
- 产出：
P5-STRIDE-THREATS.md，详尽威胁清单 - 功能价值：将传统需要数小时专家讨论的工作自动化
Phase 6: Risk Validation (风险验证) — 核心阶段
Phase 6 是工作流的关键枢纽，区别于传统工具的核心差异点。任务是：将前序阶段产生的"可能风险"过滤、合并、验证为"已证实风险"。
注：P6 是风险验证阶段，不是缓解措施阶段。攻击链分析和 POC 设计在此阶段完成。
- 输入：P1-P5 的所有发现文件
核心流程一：合并算法（Consolidation Algorithm）
由于前序各阶段可能从不同角度发现同一问题，合并算法消除重复和噪音：
- 标准化（Normalization）：将 P1-P5 中不同格式的发现统一转化为规范化的
normalized_finding对象，利用规则推断缺失的 CWE ID - 去重（Deduplication）：
- Exact Match → MERGE：CWE ID 和文件路径完全一致，视为同一风险，合并后取最高严重级
- Component Match → LINK：CWE 相同但文件不同，归类为同一组件的系统性问题
- Similarity Match：使用文本相似度算法（阈值 0.85）识别描述相似的重复项
- 数量守恒（Threat Disposition Tracking）：确保 P5 中每个 STRIDE 威胁在最终报告中有明确归宿——转化为已验证风险（VR-xxx）或被标记为已缓解/排除
核心流程二：验证逻辑（Validation via Parallel Sub-Agents）
- 启动并行子代理，针对合并后的高风险项：
- 查询知识库获取相关 CAPEC 攻击模式和 ATT&CK 技术
- 查询验证集（WSTG/MASTG）获取具体测试步骤
- 攻击路径设计：构建从入口点到最终影响的完整攻击链
- POC 设计：为 Critical/High 级别威胁构建具体攻击 Payload 或复现步骤
产出：P6-RISK-VALIDATION.md，包含：
- 验证覆盖统计（验证率、排除率）
- 攻击路径可行性矩阵
- 攻击链分析（含流程图）
- POC 详情（每个 Critical/High 威胁）
- 已验证风险清单（VR-xxx 格式）
功能价值：体现"验证即价值"原则——只有能证明可利用性的风险才进入最终报告。
Phase 7: Mitigation Planning (缓解措施规划)
P6 验证风险真实性后，进入缓解措施设计阶段。
- 输入：P6 验证后的风险清单（
validated_risks） - 核心动作：
- 针对每个已验证风险设计即时、短期、长期三层缓解策略
- 生成与具体技术栈匹配的代码级修复建议
- 优先级排序和工作量估算
- 知识引用：Security Control Sets + OWASP References + CWE Mitigations + ASVS Requirements
- 产出：缓解措施计划，包含实施优先级、预估工作量和具体代码修复指导
Phase 8: Final Reporting (报告生成与合规映射)
将全部分析成果整合为结构化报告套件。
- 输入：所有前序阶段产出
- 产出：完整威胁建模报告套件，输出到
Risk_Assessment_Report/目录：- 主报告：
{PROJECT}-RISK-ASSESSMENT-REPORT.md— 执行摘要、关键发现、建议优先级 - 风险清单：
{PROJECT}-RISK-INVENTORY.md— 所有已验证风险的详细技术信息 - 缓解措施：
{PROJECT}-MITIGATION-MEASURES.md— 修复指南与实施路线图 - 渗透测试方案：
{PROJECT}-PENETRATION-TEST-PLAN.md— 基于 POC 的测试用例 - 阶段过程文档：
P1-P6各阶段详细分析文档，作为详细问题深入分析和流程展开的技术参考
- 主报告：
5.3 系统架构图
┌───────────────────────────────────────────────────────────────────────────────────┐
│ Agent Skill Architecture │
├───────────────────────────────────────────────────────────────────────────────────┤
│ │
│ User Request │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ Claude Code (AI Agent Host) │ │
│ │ ┌────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ skill-threat-modeling (Claude Skill) │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Phase 1-3: Context Building │ │ │ │
│ │ │ │ P1 (Project) → P2 (DFD) → P3 (Boundaries) │ │ │ │
│ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Phase 4-5: Threat Identification │ │ │ │
│ │ │ │ P4 (Security Design) → P5 (STRIDE Enumeration) │ │ │ │
│ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Phase 6: Risk Validation (Core) │ │ │ │
│ │ │ │ Consolidation → KB Query → Attack Path → POC Design │ │ │ │
│ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Phase 7-8: Remediation & Reporting │ │ │ │
│ │ │ │ P7 (Mitigation Planning) → P8 (Report Generation) │ │ │ │
│ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ Tools: Read, Write, Edit, Bash, Glob, Grep, Task (Sub-Agent) │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
│ │ Knowledge Base (Local) │ │
│ │ ┌────────────────────┐ ┌────────────────────┐ ┌──────────────────┐ │ │
│ │ │ Security Control │ │ Threat Pattern │ │ Verification │ │ │
│ │ │ Set │ │ Set │ │ Set │ │ │
│ │ │ ─────────────── │ │ ─────────────── │ │ ─────────────── │ │ │
│ │ │ • 16 Domains │ │ • 974 CWEs │ │ • 121 WSTG │ │ │
│ │ │ • 107 Controls │ │ • 615 CAPECs │ │ • 206 MASTG │ │ │
│ │ │ • 74 OWASP Refs │ │ • 835 ATT&CK │ │ • 345 ASVS │ │ │
│ │ │ • 14 Compliance │ │ • 323K+ CVEs │ │ │ │ │
│ │ └────────────────────┘ └────────────────────┘ └──────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────────────────────────────────────────┘
架构说明：
- skill-threat-modeling 是 Agent Skill（技能模块），运行在 Claude Code 及其他支持Skill调用的兼容环境中
- 使用 Claude Code 或其他Agent支持的原生工具（Read, Write, Edit, Bash, Glob, Grep, Task 等）进行代码分析和文件操作
- 本地知识库包含三大知识集，并且自包含无需其他外部依赖，支持离线运行
- 支持通过 Task 工具启动并行子代理，实现多风险项高效的并发验证
第六章 skill-threat-modeling知识体系架构
skill-threat-modeling 的另一大核心，不仅是工作流程，更是将安全知识系统性的集合成"结构化"和"可执行化"的知识体系架构。skill-threat-modeling kb的核心理念是：将分散在各类标准文档中的安全知识转化为 LLM/AI Agent 可理解、可查询、可推理、可应用的结构化知识和方法论逻辑。
6.1 双轨知识体系架构
┌───────────────────────────────────────────────────────────────────────────────────┐
│ Security Knowledge Architecture │
├───────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ Security Principles (11) │ │
│ │ (Foundation - Guides All Phases) │ │
│ │ DID │ LP │ ZT │ FS │ SOD │ SBD │ CM │ │ │
│ │ EOM │ OD │ IV │ LA │ │
│ └───────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────┴─────────────────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────┐ ┌─────────────────────────────────┐│
│ │ Security Control Set │ │ Threat Pattern Set ││
│ │ (What to do & How to do) │ │ (What to know & Validate) ││
│ ├─────────────────────────────────────┤ ├─────────────────────────────────┤│
│ │ Security Domains (16)
…(truncated)