用途
security-review 是一个代码安全审查技能（Skill），用于审计代码变更中的安全漏洞，重点关注 OWASP Top 10 以及项目技术栈特有的问题。当用户说出 "security review"、"security audit"、"check for vulnerabilities"、"pentest the code"、"OWASP" 等指令时使用。
运行方式
该技能可以本地作为 forked subagent 运行，此时主会话看不到你读取的文件或你的推理过程，只能看到你返回的最终报告。也可以在 CI 中运行（例如通过 claude-code-action），此时工作流会获取报告并将其转化为 GitHub PR 审查评论。无论哪种方式，报告的使用者都把它当作待办工作清单，因此报告必须完整且自包含。
审查范围
确定要审查的 diff：
- 运行
git diff main...HEAD --name-only获取本分支相对 main 变更的文件。 - 如果失败（没有 main、分离工作树等），回退到
git diff HEAD --name-only查看未提交变更，然后git diff --cached --name-only查看已暂存文件。 - 如果没有可用 diff，询问用户要审查哪些文件。
开始审查前完整读取每个变更文件。先阅读 CLAUDE.md 以理解项目技术栈，以及任何具有安全敏感面的子系统（认证、实时通信、支付、文件上传）。
审查方向
注入与输入处理
- SQL 注入：使用字符串插值构建原始 SQL 而非参数化查询。检查任何构建 SQL 的模板字符串，验证数据库库是否以参数化形式使用。
- 命令注入：用户输入未经净化就传入 shell 命令（Bun.$、child_process、subprocess、os.system）。
- XSS：用户可控数据被渲染为 dangerouslySetInnerHTML，或未经转义反射进 HTML/JS。检查接受粘贴 HTML 的 contentEditable 字段。
- 路径遍历：用户输入未经验证用于文件路径。检查
..遍历。 - 原型污染：对用户可控对象使用 Object.assign 或展开而未对键做允许列表。
认证与授权
- 缺失认证检查：读写数据的端点未验证调用者身份或组织成员资格。
- IDOR（不安全的直接对象引用）：端点接受 ID 参数并在未验证调用者访问权限的情况下返回/修改资源。当 URL 参数（如 slug）未与实际资源所有权校验时尤其危险。
- 权限提升：应受限制的操作（删除、移动、管理操作）未基于角色/权限进行门控。
数据暴露
- 过度获取：API 响应包含超出客户端需要的数据（如内部 ID、密钥、只需标题时返回完整文档状态）。
- 错误泄漏：错误响应中暴露堆栈跟踪、SQL 错误或内部路径。
- 日志中的敏感数据：密码、令牌或 PII 被记录到控制台。
实时 / WebSocket 安全
（仅当项目存在 WebSocket 层时相关——见 CLAUDE.md。）
- 频道授权：客户端能否通过猜测名称订阅任意频道？频道订阅是否针对用户权限进行验证？
- 消息伪造：客户端能否向本无写权限的频道广播消息？
- 载荷校验：传入的 WebSocket 消息在處理前是否经过验证？
拒绝服务
- 无界查询：端点无分页或限制地返回所有记录。
- 正则 DoS：用户输入未经净化用于正则模式。
- 资源耗尽：文件上传、大请求体或昂贵操作缺少限流或大小限制。
密码学与密钥
- 硬编码密钥：源代码中的 API 密钥、密码或令牌。
- 弱随机数：安全敏感操作使用 Math.random() / random.random() 而非 crypto.randomUUID() / secrets.token_*()。
- 缺失 TLS：生产环境中 WebSocket 连接使用 ws://。
依赖项
- 已知漏洞：如果 bun audit / npm audit / pip-audit 可用，检查已知 CVE。
- 依赖导致的原型污染：深度合并用户输入的库。
报告格式
将完整的格式化报告作为最终消息返回——不是摘要或 TL;DR。无论消费报告的是本地主 Claude 会话，还是发布内联 GitHub PR 评论的 CI 工作流，都将其当作待办清单使用，因此它必须自包含。
按严重级别组织发现：
Critical：当前即可利用且无需认证。数据丢失、未授权访问或远程代码执行。
High：需要一些前提条件即可利用（如需要已认证用户、特定时机）。权限提升、重大数据泄漏。
Medium：纵深防御问题。当前由另一层保护但不应依赖它的缺失验证。
Low：加固建议。当前不可利用但可减少攻击面。
每条发现包含足够细节，使消费者无需重读整个文件即可应用修复：
- 文件与行号 — 精确的 path:line（范围用 path:start-end）；跨文件发现列出每一处位置
- 严重级别 — Critical / High / Medium / Low
- 漏洞类型 — OWASP 类别或 CWE
- 当前代码 — 有漏洞代码的简短片段（不只是描述）
- 利用场景 — 展示攻击者如何利用的具体步骤
- 修复 — 具体代码改动，最好是 before/after 片段
- 周边上下文 — 调用方、需同步修改的相关文件、修复依赖的验证层、应添加的测试
不应做的事
- 不要标记风格问题——那是代码审查的职责。
- 除非代码级修复不足，不要建议添加 WAF、限流器或基础设施改动。
- 不要报告需要物理访问或已失陷基础设施的理论问题。
- 不要堆砌——优先处理最重要的发现。
报告之后
修复阶段（或发布 PR 评论阶段）在消费此报告的一方进行——不在这里。你的工作在你返回报告时结束。确保报告有足够信息让消费者无需重读代码库即可对发现采取行动。本地场景下，主会话将按严重级别顺序以最小化、有针对性的修复逐条处理发现，并在每次之后运行 {{check_command}} + {{test_command}}。CI 场景下，工作流将每条发现转化为 GitHub PR 审查评论。