威胁建模 (Pro)
注意：威胁建模是 DefectDojo Pro 专属功能，目前处于 BETA 测试阶段。
威胁建模将功能设计转化为经过审阅的威胁模型。您提供设计内容——可以是粘贴的文本、设计文档，也可以再加上一份架构图——DefectDojo 便会生成其中所描述的组件和数据流、针对它们的威胁，以及缓解这些威胁的安全需求。随后可以将这些需求推送到 DefectDojo 中作为发现项，使设计阶段的工作与其他一切内容一样，流经相同的分诊、SLA、Jira 和报告机制。
这是 Sensei 的代码编写前能力。扫描并修复针对的是已经存在的代码仓库，而威胁建模针对的是设计本身，在有代码可供扫描之前就已发挥作用。
**🔎 BETA：**威胁建模正在积极开发中，在界面中始终标记为 BETA。行为和界面可能会在不同版本之间发生变化。在 BETA 期间，该功能由 DefectDojo 按实例启用——请联系您的 DefectDojo 代表以开启此功能。
📍 位置：从左侧导航栏中打开威胁建模，位于 Sensei 正下方。
所需条件
- Sensei 许可功能。威胁建模与扫描并修复共用同一授权。
- 全局维护者或所有者角色。没有此角色的用户看不到此页面。
- 一个用于关联威胁模型的产品。使用 V3 命名的实例中，产品被称为资产；本页统一使用产品一词，界面则会遵循您实例所设置的命名方式。
不会安装任何内容，也不会连接任何代码仓库。威胁建模只会读取您提供的设计内容。
生成威胁模型
选择新建威胁模型，选取产品，为其命名，然后以您手头现有的形式提供设计内容：
- 直接粘贴描述内容，或
- 上传设计文档——
.md、.markdown、.txt、.text或.pdf。从 PDF 中提取文本是尽力而为的；如果 PDF 主要由图片构成，请改为粘贴文本。 - 可选择添加一份架构图——PNG、JPEG、WebP 或 GIF 格式。该图会与文本一同被读取，因此只出现在图片中的组件仍然会被识别到。
您可以将它们结合使用：一段简短的粘贴摘要加上一张图，通常比单独使用其中一种能生成更好的模型。
生成过程在后台运行，会经历四个阶段，并在运行过程中于该次运行上显示进度：
- 提取架构——组件、信任边界、数据资产和数据流。
- 枚举威胁——按 STRIDE 类别划分的威胁。
- 编写安全需求——可测试的需求，每条都关联其所缓解的威胁。
- 汇总结果——图表和最终的一致性检查。
一次运行通常需要几分钟。您可以离开该页面；进度和结果都会保留在该次运行记录上。
解读结果
架构
架构标签页会将提取出的内容渲染为一张数据流图：组件按信任边界分组，数据流按协议标注。跨越信任边界的数据流以不同方式绘制，因为这些正是需要关注的部分。选中某个组件即可查看针对该组件的威胁。
该模型还会记录它无法确定的内容——它不得不做出的假设，以及设计中不清晰的地方。请先阅读这些内容：它们会告诉您设计本身在哪些地方存在歧义，而这往往是本次练习中最有价值的产出。
威胁
每个威胁都包含：
- 其 STRIDE 类别（欺骗、篡改、否认、信息泄露、拒绝服务、权限提升）和严重程度。
- 攻击者画像——例如外部未经身份验证的攻击者、内部人员，或供应链遭到入侵——以及所需的技能水平。
- 一条有序的攻击路径：攻击者会采取的步骤，以及所需的前提条件。
- 一个 CWE（如适用），取自固定列表而非凭空编造。
- 其所针对的组件、数据流和数据资产。
安全需求
每条需求都以可测试的语句形式撰写，附有描述如何确认其成立的验证步骤、一个类别（身份验证、授权、输入校验、加密等）以及一个优先级。每条需求都会指明它所缓解的威胁。
覆盖情况会被明确核算：每个威胁要么至少被一条需求所缓解，要么被列为覆盖缺口。缺口会被展示出来而不是被隐藏，因此不会有威胁被悄无声息地遗漏。
证据，以及可信度
每个组件、威胁和需求都带有其来源的证据，证据会按来源标注：
- 来自设计文本——与您提供的文本逐字匹配到的引用。
- 来自图表——从图片中读取，因此没有可引用的文本。
- 推断得出——设计中完全没有提及。
无法与所提供文本匹配的引用会被保留，但会标记为未经验证，并显示所声称的引用内容，供您自行判断。此类条目会被标记而不是移除，因为一个被悄悄丢弃的威胁，是一个没有人会知晓的风险。结构上存在问题的条目——例如某个威胁引用了一个从未被提取出来的组件——则会被丢弃，被丢弃的数量会记录在该次运行上。
**请将输出结果视为待审阅的草稿，而非最终成品。**它是由语言模型根据设计文档生成的；证据标注的存在，是为了让您能够看清哪些部分基于您所写的内容，哪些部分是推断得出的。
将需求推送为发现项
需求通过推送到发现项变为可执行项。选中您想要的需求后，DefectDojo 会为每条需求创建一个发现项，放入该产品下名为 Sensei Threat Modeling 的专用测试活动中，每个威胁模型版本对应一个测试。
每个发现项都包含：
- 需求语句，以及它所缓解的每个威胁的叙述——STRIDE 类别、攻击者，以及带编号的攻击路径——使得接手该工单的人无需打开威胁模型即可掌握上下文。
- 作为缓解措施的验证步骤。
- 该需求的严重程度和 CWE。
- 标签
sensei-threat-model、一个tm-v<version>标签，以及一个 STRIDE 标签。
发现项创建时为活动但未验证状态：生成的需求是提交给人工确认的一项提议。
推送操作是幂等的。每条需求都拥有自己的发现项，因此再次推送同一模型会就地更新而不会产生重复项——如果您编辑某条需求后再次推送，对应的发现项也会随之更新。重新推送不会改写最初创建该发现项的人员信息。
版本与替代
威胁模型按产品分版本。根据更新后的设计重新生成会创建一个新版本，而不是覆盖旧版本，因此您可以保留做出决策时设计原本样貌的历史记录。
当您推送更新的版本时，上一版本中不再对应任何当前需求的发现项会被标记为已缓解，而不是保持打开状态，从而使该测试活动能够反映当前的设计。
导出
威胁模型可以下载为 Markdown 格式，用于设计评审或工单，也可以下载为 JSON 格式，用于任何程序化用途。这两种格式均可从威胁模型本身获取。
生成活动
活动标签页列出每一次生成、其状态以及所到达的阶段。进行中的运行可以取消。失败的运行会显示失败的原因——配置问题、输入过长，或临时性的服务错误——已完成的阶段会被设为检查点，因此重试会从断点继续，而不是从头开始。
费用
威胁建模会调用大语言模型，每次生成都会产生费用。一次生成大约会进行八次调用，用量会按运行记录，并与 Sensei 的其他 LLM 用量一并展示，因此您可以看到生成一个模型所花费的成本。取消运行会在下一个阶段边界处停止后续调用。