security-threat-model 用于明确提出的应用安全建模。它从实际仓库提取系统结构，关注攻击者能从哪里进入、能接触什么资产、需要跨越哪些边界，再把风险与已有控制和建议措施对应起来。部署范围与权限模型会直接影响排序，因此需要你补充代码里看不到的背景。
安装与准备
本文介绍 openai/skills 保留的独立 Skill 版本。该仓库已弃用，当前官方示例转至 openai/plugins；这里的步骤对应本页链接的旧仓库版本，不代表最新插件。
在 Codex 对话框输入下面这一行；它不是终端命令。安装后若找不到该 Skill，重启 Codex 再试。
$skill-installer security-threat-model
- 可读取的仓库或明确的目录范围
- 系统用途、部署方式、互联网暴露与权限背景
- 愿意确认关键假设的项目负责人
第一次怎么用
下面以文件上传服务为例，部署背景应替换为实际情况：
$security-threat-model
对当前仓库的文件上传与处理流程做威胁建模。部署为面向企业客户的多租户服务，公网入口是上传 API。先根据代码画出组件、数据流和信任边界，标明证据路径；向我确认会影响风险排序的未知条件后，输出 Markdown 报告，区别已有控制与建议措施。
接下来怎样推进
-
建立有证据的系统模型。 识别运行时组件、入口、数据存储和外部服务；把测试、CI 与生产路径分开，不把示例代码当作线上架构。
-
确认威胁成立条件。 列出资产和现实攻击者能力，说明哪些能力并不具备。回答 Skill 提出的少量关键问题，以校准影响和可能性。
-
排序并落到改进位置。 为少量重要滥用路径写出条件、影响、已有控制和具体缓解位置，再生成约定的威胁模型文件。
用一个流程检验模型是否具体
以文件上传为例，先画出浏览器、上传 API、对象存储、处理 Worker 与结果下载之间的数据流，标注认证、租户 ID 和文件格式检查分别在哪个边界发生。然后问：攻击者能否上传任意内容、读取别人的结果、消耗大量处理资源？这些是待分析的路径，不代表代码里已经存在漏洞。让 Agent 给每个路径附上代码位置和成立条件。
输出不应只有“SQL 注入、XSS、权限绕过”这样的类别。好的条目会写清攻击者起点、跨过的边界、目标资产、现有控制、缺口、可能影响和建议修改位置。如果仓库里没有部署配置或对象存储权限策略，请提供真实背景；不能提供时，把相关严重性保留为条件性判断。
把报告用于下一轮工作
检查每个重要入口都有对应数据流，风险按现实暴露程度排序，并区分“代码中已看到的控制”与“建议新增的控制”。可以把最高优先级路径转成待验证的安全测试或配置审查任务。威胁模型帮助团队决定先查哪里，并不会实际尝试攻击，也不能替代对线上权限的验证。
另一个场景：多租户数据导出
若应用允许客户下载 CSV，任务可写成：“只分析导出 API、后台任务和对象存储。租户管理员可以申请导出本租户数据；请从代码确认租户 ID 在请求、队列消息、存储路径和下载链接之间如何传递。先问我部署权限与链接有效期，再列出最重要的跨租户访问或泄露路径。” 这里关心的是边界是否被实际验证，并不预先断定存在越权。验收报告应能指出每条路径需要的攻击者能力、受影响资产、已有控制和建议修改位置；如果存储权限不在仓库里，明确写成待确认假设。
交付后先检查什么
默认文件名是仓库或目标目录名称加 -threat-model.md。检查每个重要入口和信任边界是否被覆盖，风险排序是否使用你确认过的部署信息。已有控制要有代码依据，建议措施则明确写成后续工作。
从一条真实数据流开始
可以先选一个范围清晰的仓库做初版威胁模型。例如从登录到读取敏感数据的路径，让 Agent 根据代码画组件和数据流，再逐条核对信任边界与威胁。有人用 OWASP Juice Shop 做过这种练习，桌面和 CLI 都生成了架构、数据流与 STRIDE 草案；这类输出适合开启审查讨论，具体漏洞和缓解措施仍要回到代码与实际部署验证。
常见卡点
缺少部署信息。 先补充公网暴露、租户隔离、认证和数据敏感度；不能回答时保留条件性排序。
列了太多泛化威胁。 要求每条连接到具体入口、资产和攻击者目标，优先少而清楚的路径。
只读了 README。 要求回到代码验证关键架构事实，文档可以提供线索，但不能替代实际实现。