在分支上运行 /security-review

一条命令，范围限于当前分支

切换到你想审查的分支，在聊天面板中输入：

/security-review

智能体会对比基础分支（通常是 main）做 diff，读取每个变更文件及足够的上下文来理解改动，然后逐项检查安全清单。输出是一份结构化的问题列表，按严重程度排序。

与 /review 不同，这个命令专门忽略代码风格和大多数通用 bug——它只用一个视角审查你的改动，而不是从所有角度审查。

六大类别

审查（大致）覆盖以下类别：

• 输入处理 — 外部输入在哪里进入系统？使用前是否经过校验？SQL 查询是用参数化方式还是字符串拼接构建的？文件路径是否检查了路径穿越？
• 鉴权与授权 — 新端点、现有端点上的新操作。该要求鉴权的地方是否有鉴权？是否检查了角色和权限范围？
• 敏感凭据 — 硬编码的密钥、令牌、密码、内部 URL；日志中打印了凭据；提交了含有敏感信息的配置文件。
• 注入面 — SQL、Shell、模板引擎。任何用户输入被拼接到会被执行或解释的内容中的地方。
• 加密与随机性 — 使用了不安全算法（将 MD5 用于安全用途、ECB 模式等），在需要 CSPRNG 的地方使用了 Math.random()。
• 数据泄露 — 端点返回的用户数据超出调用方应有的权限；错误信息泄露了实现细节。

三个等级，只有前两个会阻止发布

问题按严重程度标记：

• 高 — 可被利用，且存在合理的攻击路径。修复前不得合并。示例：来自用户输入的 SQL 注入、返回用户数据的未鉴权端点、硬编码的生产环境凭据。
• 中 — 有隐患但影响范围有限。尽量在本 PR 内修复；无法修复则开 ticket 跟进。示例：密码强度要求过弱、敏感端点缺少限流、Cookie 属性不安全。
• 低 — 纵深防御类。值得最终修复，但不构成阻塞。示例：日志输出略微冗余、响应中缺少某个目前不会泄露信息的 header。

不要因为不是"高"就忽视"中"级问题。现实中大多数安全事故都是从若干"中"级问题叠加开始的。

请智能体给出修复方案

针对每个发现的问题，下一步的提示词通常是以下几种变体之一：

• "Show me the unsafe code." — 智能体会引用对应代码行并展示上下文。
• "Propose a fix." — 智能体建议修改方案。
• "Apply the fix." — 智能体直接进行修改（受你当前权限模式约束）。
• "Add a test that would catch this regression." — 智能体专门针对它标记的问题编写测试。

最后一条价值极高。修复了漏洞但没有配套测试，迟早会回归。将测试与修复绑定，能有效防止这种情况。

部分发现是误报，告诉智能体原因

静态安全审查总会有误报。智能体可能看到一个 SQL 查询，看起来像字符串拼接，但实际上是通过它不认识的封装使用了参数化 API；也可能把"缺少鉴权检查"标在一个已被上层中间件保护的端点上。

如果你不认同，直接说明："This is fine because queryWithBind is parameterized — see db/helpers.ts."智能体会修正判断。如果误报是结构性的（代码库中有一种模式让智能体反复误读），可以在 CLAUDE.md 中加一条说明："We use queryWithBind for safe parameterized queries — it's not concatenation."

这是一份清单，不是审计

/security-review 能发现一个有用的子集——那种出现在代码中、出现在这个 diff 里、具备安全背景的细心审查者同样会发现的问题。它做不到的是：

• 架构审查。"这套鉴权方案整体上是否合理？"——这是真正审计才能回答的问题，不是 diff 扫描。
• 密码学协议审查。来自数学层面的问题，而非代码层面。
• 威胁建模。你该关注哪类攻击者？哪些资产最重要？/security-review 假设的是通用威胁；高风险系统需要专门的威胁模型。
• 依赖分析。CVE 追踪、SBOM、许可证问题——这些需要专用工具（Dependabot、Snyk 等）。

对于安全失误代价高昂的系统（支付、身份、基础设施），将 /security-review 与定期的人工审计结合使用。智能体是下限，人工是上限。