让 AI 给一个仓库做威胁建模，大多数模型会还给你什么？一份看起来非常专业的报告，结构大概是这样：
一份组件清单，覆盖常见的网关、缓存、数据库 一段攻击面描述，套用 OWASP 的分类法 几条 OWASP 引用，证明自己懂行 一堆”建议验证输入”式的缓解措施
每条都对，但没有一条能对到你的代码上。你拿着它去评审，说不出哪里错，也说不清该改哪里。
OpenAI 显然被这个问题折磨过。他们在 openai/skills 仓库里放了 security-threat-model 这个 Skill，核心主张只有一句：威胁模型必须锚定在仓库证据上。每一条架构论断都要能指到具体文件路径和符号，找不到证据的组件不许出现在报告里，这是它的硬门槛。
但真正让我停下来多看了两遍的，是它的工作流里藏着一个暂停点。报告生成到一半，模型必须把影响风险排序的假设列给你，问你 1 到 3 个问题，然后等你的回答。这听起来简单，却是大多数 AI 安全工具不敢做的设计，因为它把交付速度让位给了交付正确。
这篇文章带你走一遍它的完整流程：怎么装、八个步骤各自干什么、输出契约为什么写得像法律条文，以及那个”先提问再交付”的设计到底解决了什么问题。
环境准备
这个 Skill 的依赖门槛低到可以忽略。它就是一个 SKILL.md 加两个 references 文档：prompt-template.md 是输出契约，security-controls-and-assets.md 是资产与控制的词表。没有脚本、没有二进制、没有要配的 Token，整个工作发生在模型的推理过程里。
安装入口有两条。Smithery 走 skills CLI，Codex 生态走内置安装器：
npx skills add https://github.com/openai/skills --skill security-threat-model
# 或者用 Codex 的 $skill-installer，curated 技能按名安装
$skill-installer security-threat-model
装完别急着扔仓库。先打开 references/prompt-template.md，这是整个 Skill 的咽喉：仓库摘要怎么生成、用户提示词怎么填、最终报告必须按什么章节顺序和表格结构输出，全在这一个文件里。格式错了，后面每一步都会跟着歪。
初次使用最常见的卡点，是输入信息给得太少。prompt-template 里有一串上下文字段，不知道就标成假设，但留空不填，模型只能靠猜，猜出来的威胁排序大概率偏离你的真实场景：
- intended_usage # 预期用途
- deployment_model # 部署模型
- data_sensitivity # 数据敏感度
- internet_exposure # 公网暴露面
- authn_authz_expectations # 认证授权预期
- out_of_scope # 明确排除项
操作流程
整个流程有八个步骤，前五步是分析，后三步是收敛。第一步和第二步界定范围：识别主要组件 / 数据存储 / 外部集成，弄清系统以什么形态运行（服务 / CLI / 库 / worker），然后把 runtime 行为和 CI 构建 / 测试示例严格分开。这一步最严的规矩是没有证据不许声称，你不知道某个组件干什么，宁可写进假设也不能编。
第三步和第四步开始制造威胁。信任边界被定义成组件之间的具体边，每一条都要注明协议 / 认证 / 加密 / 校验 / 限流。攻击者能力清单旁边必须并列一份非能力清单，明确写清攻击者做不到什么，这是防止风险虚高最有效的手段。威胁不按组件枚举，而是按滥用路径走：攻击者目标 → 到达资产的多步路径 → 最终影响。
第五步做排序，用显式的可能性和影响推断，不用神秘的风险评分。每个威胁给出 low/medium/high 的可能性和影响理由，再合成 critical/high/medium/low 的优先级，最后说明哪些假设对排序影响最大。
第六步是分水岭。模型必须停下来，把影响范围或排序的关键假设总结成 3 到 6 条，问你 1 到 3 个定向问题，覆盖服务负责人 / 部署模型 / 认证授权 / 公网暴露 / 数据敏感度 / 多租户这几项。然后暂停，等你回答。你拒绝回答它也继续，但会把遗留假设的影响写清楚。
第七步和第八步收尾。缓解措施被锚定到具体位置，区分已有缓解（带证据）和建议缓解，控制类型覆盖：
- 权限检查 - 输入校验
- schema 强制 - 沙箱
- 限流 - 密钥隔离
- 审计日志
最后跑一遍质量检查，按这几条逐项打勾：
-
所有入口点是否覆盖 -
每条信任边界是否在威胁中出现 -
runtime 与 CI 是否分离 -
用户澄清是否反映
然后按 <repo>-threat-model.md 的规则落盘。
关键设计
我最想拆的是证据锚定这条规则。prompt-template 里的系统提示词要求：每条架构论断至少一个 Evidence anchor，引用仓库路径，能给出符号名、配置键或简短引文更好。这直接封死了大模型安全分析最大的毛病：幻觉。编一个不存在的缓存服务再煞有介事地分析它的风险，是通用 AI 审计的常态，这个 Skill 用格式强制把这条路堵死了。
输出契约的细密程度也超出我的预期。报告必须按固定顺序出十个章节，威胁表有 13 列，威胁 ID 必须是 TM-001 起的稳定编号，优先级只有四个合法值。连 Mermaid 图都规定了保守子集：只用 flowchart TD/LR / 只用 –> / 不用 title 和 style / 节点标签不许带路径。这套约束不是官僚主义，是让输出能被人工审阅和自动化追踪的前提。
非能力清单是个容易被忽略但很关键的设计。大多数威胁模型只写攻击者”能”做什么，结果每个系统都被描述得千疮百孔。强制列出攻击者做不到的事，比如”该仓库无公网入口，预认证远程攻击不适用”，等于给严重度排序加了一根锚，避免把低风险场景包装成安全事故。
保留意见也要说。整个流程的质量高度依赖仓库本身的可读性，注释和目录结构糟糕的代码库，证据锚定会退化成路径罗列。另外第六步的提问环节在纯自动化流水线里容易被跳过，Skill 做了降级处理但会留下条件性结论，在 CI 里跑时要想清楚谁负责回答。
## Executive summary
## Scope and assumptions
## System model（Primary components / Data flows and trust boundaries / Mermaid 图）
## Assets and security objectives（Asset | Why it matters | C/I/A）
## Attacker model（Capabilities / Non-capabilities）
## Entry points and attack surfaces（表格）
## Top abuse paths（5-10 条编号路径）
## Threat model table（TM-001 起，13 列）
## Criticality calibration（分级定义 + 每级 2-3 个例子）
## Focus paths for security review（Path | Why | Threat IDs）
使用场景
第一个场景是新仓库接手。刚克隆一个不熟悉的代码库，别急着读源码，让它先把系统模型、信任边界和入口点画出来。Focus paths 这张表是给人工审阅者的导航：2 到 30 条仓库相对路径，每条配一句关联理由和 Threat ID。你不用通读全部代码，顺着这张表看就够启动一轮人工安全审查。
第二个场景是发布前的 AppSec review。把报告直接扔进评审流程，威胁表可以按 ID 追踪到关闭：TM-003 对应的修复在哪个文件、对应哪条缓解建议，评审结论能回填。相比评审一份没有编号的安全文档，这种可追踪性让”安全问题已处理”第一次有了可核验的载体。
第三个场景是 CI 集成或发布周期重跑。配合仓库变更，威胁模型随代码演进更新，而不是一年做一次的文档仪式。但要记住触发边界：Skill 明确写着不适用于一般架构总结、常规代码评审和非安全的设计工作，硬套只会增加流程噪音。
需要提醒的是，它不回答”这个代码库有多少漏洞”这种问题。它不是扫描器，不产出 CVE 清单，产出的是威胁模型：哪些组件最值得人工深挖、为什么、按什么顺序。想要自动化的漏洞实证，得上另一类工具，这不是它的定位。
洞察与反思
看完整套设计，我的判断是：它把资深安全工程师的提问习惯工程化了。经验丰富的 AppSec 顾问接手一个系统，不会先写报告，会先问部署在哪、谁在用、数据多敏感。这个 Skill 把这种习惯固化成第六步的强制暂停，让不具备该经验的模型也能走一遍专家的思考路线。
拿它跟 STRIDE 和 OWASP ASVS 对比很有意思。STRIDE 给你分类法，威胁按欺骗、篡改、否认等类别归位；ASVS 给你检查清单。它们解决的是该看哪些维度的问题，而这个 Skill 解决的是凭什么说你看到了的问题。证据纪律和分类框架不是替代关系，它补的是前者缺失的那一半。
局限同样明显。证据锚定对大型 monorepo 不友好，组件散布在几十个目录时，模型的上下文窗口会被证据搜索吃掉一大块，报告篇幅也会膨胀。缓解建议的质量上限取决于模型对控制类型的理解，措辞再具体，落到代码上仍需工程师判断。它是决策支持，不是决策本身。
我的结论是，这类给 Agent 立规矩的 Skill 会是 AI 安全工具的主流形态。能力早就够了，缺的是纪律：不幻觉、可追踪、先确认再交付。OpenAI 这个 Skill 的意义不在于威胁建模本身，而在于示范了怎么用格式和流程，把纪律写进 Agent 的行为里。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery 页面 | https://smithery.ai/skills/openai/security-threat-model |
| GitHub 仓库 | https://github.com/openai/skills/tree/main/skills/.curated/security-threat-model |
| OpenAI Skills 总览 | https://github.com/openai/skills |
总结
Security Threat Model 做的事情说穿了不复杂：威胁建模，每一条论断都要有仓库证据，交付前先停下来和你确认假设。但不复杂和能做到之间，隔着的正是大多数 AI 安全输出缺失的那层纪律。
如果你手头有一个准备发布的高风险服务，或者刚接手一个说不清组件边界的代码库，值得让它跑一次。记得把 prompt-template.md 读完再开工，上下文字段能填多少填多少，回答第六步的问题时别敷衍，那两个问题的答案直接决定报告排序的准确性。
更深一层看，这个 Skill 示范的东西比威胁建模本身更值得学：怎么用输出契约和流程门禁，把不幻觉从一个口号变成 Agent 的强制行为。这条思路，放到任何需要可信 AI 输出的场景都成立。