tm-security-review

用途

tm-security-review 是针对整个代码仓库的深度安全审查技能，属于综合（comprehensive）层级。它适用于智能体（agentic）、LLM、MCP 及连接器类代码库，支持全仓库审查或合并前的漏洞利用审查，目标是产出每个漏洞发现对应的可运行 PoC 与完整证据链，而非仅仅给出安全态势概述。

当只需要对分支或工作树上的改动做快速检查时，应改用 tm-quick-security-assessment；也可以把后者的发现面交给本技能做深度跟进。

核心理念：先建模，再狩猎

单纯扫描源码到汇点（source→sink）的数据流，从不会追问“这个源（source）的可信级别是否真的低于它到达的汇点（sink）”，因此会：

把操作者自己控制的输入（命令行参数、配置、环境变量、classpath 上的 JAR 包）误判为 HIGH；
漏掉真正的设计风险，例如间接提示注入（indirect-prompt-injection）到自动执行链。

威胁模型恰好提供了这种缺失的“信任方向”检查。本技能先建立模型，再据此运行复杂的零日漏洞利用狩猎。

组成

本技能组合两个同级技能：

阶段 0 → threat-modeling（../threat-modeling/SKILL.md）：STRIDE/DREAD、数据流图（DFD）、信任边界。
阶段 1-3 → 0day-scanner（../0day-scanner/SKILL.md）：LLM 漏洞利用引擎，以深度模式运行，由威胁模型中的关键威胁（KEY threats）引导。当 MCP 工具不可达时，启用其磁盘回退方案（security-reviewer/languages/* + 8 项检查）。

使用方式

触发场景

“threat model security review”“hunt for exploitable vulns with a threat model”“/security-review”等。

输入（需询问用户；若用户不在，使用默认值并标注 [ASSUMPTION]）

目标：仓库路径 / 服务 / 功能 / 差异 + commit 或 branch。
是否已有威胁模型？若已提供（例如 *-threat-model.md），则作为阶段 0 引入，不要重新生成。
部署/信任上下文（决定严重性）：自托管库 vs 托管的多租户服务；谁是攻击者、谁是操作者；是否存在网络暴露面（stdio 还是 HTTP）。

阶段 0 —— 威胁建模

运行 threat-modeling 技能，产出或引入“每个信任边界的 STRIDE”模型。除该技能默认输出外，还要求：

DFD 中每个信任边界穿越标记为 TBn，并提供 | ID | Boundary | Crosses | Primary risk | 表格。
每个威胁标注置信度：[CONFIRMED] / [REFUTED] / [ASSUMPTION] / [QUESTION]。
AI 暴露面映射到 OWASP Top 10 for LLM Apps 2025（LLM01 提示注入、LLM02 敏感信息泄露、LLM05 输出处理不当、LLM06 过度代理、LLM08、LLM10）。这些设计风险是任何模式扫描器无法测试的。
严重性依据输入中的部署上下文进行校准。
标出会改变严重性的 [QUESTION]/[ASSUMPTION] 项并向用户提问；若用户不在，采取保守默认值并标注。

信任方向门（不可跳过）

在任一威胁保持 HIGH 之前，必须确认：该源是否真的比它到达的汇点可信级别更低？

操作者提供的 CLI 参数 / 配置 / 环境变量 / classpath 上的 JAR = 操作者在自己系统上的操作 → 非攻击者可控。需要你已能运行代码的“RCE”并不跨越任何边界。应降级或反驳，并记录理由。
只有更低可信方控制的源才危险（外部 HTTP 内容、引入的第三方元数据、匿名请求、另一个租户）。
反驳（Refutations）同样是发现——它们能阻止错误 HIGH 被提交，并维护审查者的可信度。

阶段 1 —— HUNT（攻击面映射，由模型驱动）

取通过信任方向门的关键/高危威胁，驱动 0day-scanner（深度模式），并在每个威胁处结合代码阅读 / grep / 图追踪，逐条枚举具体的源→汇点路径。过程中叙述推理。

阶段 2 —— JUDGE（分类）

输出一张表，列固定为：

ID 从 V-01… 编号；严重性为 CRITICAL / HIGH / MEDIUM / LOW。对每一行应用信任方向门——源可信级别 ≥ 汇点的流应降级或反驳并记录理由，绝不列为 HIGH。

阶段 3 —— VERIFY（证明）

对每个确认的漏洞利用：

根因：为何汇点能在真正攻击者可控输入下被触达。
证据链：源→汇点路径，每一步引用 [[path:line]]。
PoC：具体可运行的证明（curl / payload / 单元片段），放在代码块中。
补偿控制残余：建议控制措施之后的残余风险。

汇总报告

发现 V-01…V-N：严重性标签、[[path:line]] 引用、残余评级、PoC。
对模型的确认评分（例如“模型声称的 15 项中有 12 项在代码中得到确认”），并附注：这是吻合度评分，不是独立检查——按模型评分不能证明模型的严重性判定正确。
横向正面项（[CONFIRMED]）：参数化查询、安全反序列化、正确的密钥处理——予以点名。
优先级修复：| Action | Owner/ETA | Trade-off |。以真正的严重问题（通常是设计链）开头，而非被降级的 CLI 缺陷。
纯文本标题 + markdown 表格；审查正文不使用 emoji，不使用 Mermaid。

交付物

保存到 ~/security-reviews/<target>-security-review.md（模型与审查结果存放在被审查仓库之外；绝不修改源代码），并说明路径。如果未运行 Semgrep/OpenGrep，建议将其作为经典注入/密钥/子进程缺陷的模式级后备手段——但不适用于 LLM 架构设计风险。

限制

资料未提供关于收费、价格、支持平台、性能指标或具体修复效果的信息。本技能依赖 MCP 工具，不可达时使用磁盘回退方案；其审查结论的准确性依赖威胁模型质量，且对模型的确认评分为吻合度评分而非独立验证。