mcpField
R
review-security

review-security

github.com/borkweb安全888 次安装2 天前更新
代码仓库

关于 review-security

review-security 是用于代码安全审查的参考库与工作流，面向独立审计或预合并审查中的安全敏感变更。它按变更类型选择基于真实漏洞与审查案例整理的模式，并要求以证据支持发现和结论。

主要功能

  1. 01按变更范围选择安全模式
  2. 02依据模式逐项检查差异及相关代码
  3. 03要求发现附具体证据
  4. 04提供严重性分级与审查结论标准

适用场景

  1. 01审查分支中的安全敏感改动
  2. 02针对认证、解析或依赖变更开展审计
  3. 03为发现记录证据并判断发布状态

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/borkweb/skills --skill review-security

安装后在 Claude Code 中输入/review-security确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

catalog/
caught-in-review.md
concurrency-and-crypto-bugs.md
missed-in-review.md
patterns/
01-bounds-and-allocation.md
02-injection-prevention.md
03-authentication-and-authorization.md
04-cryptographic-hygiene.md
05-race-conditions-and-concurrency.md
06-memory-and-resource-lifecycle.md
07-error-handling-and-failure-modes.md
08-supply-chain-and-build-integrity.md
09-type-safety-and-coercion.md
10-state-machines-and-protocol-correctness.md
11-integer-arithmetic-safety.md
12-configuration-and-defaults.md
13-trust-boundaries.md
14-regression-prevention.md
15-api-contracts-and-misuse.md
16-web-application-security.md
17-data-validation-and-canonicalization.md
18-sandbox-and-isolation.md
19-logging-and-observability-security.md
20-denial-of-service-resistance.md

详细介绍

安全审查

这项技能是一套参考库 + 工作流。patterns/ 下包含 20 个基于证据的安全模式文件。每个文件都以特定的 CVE、审计发现和审查流程为依据，涵盖 Linux kernel、OpenSSL、Chromium、Firefox、curl、Go、Rust、Kubernetes、Next.js 以及数十个其他项目。

这项技能可通过两种方式调用：

  • 独立使用：“对这个分支进行安全审查”——端到端执行以下工作流。
  • **作为 /review 的参考：**在提交前审查技能中，如果 diff 涉及安全敏感区域，就会读取相应的模式文件。

每个模式文件都包含：

  • 核心问题——需要牢记的一个问题
  • 检查内容——附带示例的具体代码模式
  • 危险信号——表明存在风险的模式
  • 目录参考——用于展示每种模式的真实 CVE

步骤 1：确定请求的范围

对于分支，验证其目标 ref，记录 base SHA、HEAD 和 merge-base，并审查 git diff <merge-base> <head>。可选的 ../../../scripts/review-scope.py --base <verified-ref> 辅助脚本会记录这些证据。只有在收到请求时才纳入本地更改，并单独对其拍摄快照；指定文件的请求会限制审查对象，但可能需要追踪其调用方。在任一运行时环境中，都要从已加载的软件包解析路径。如果范围内的文件发生变化，请停止审查并重新确定范围。

确定范围后，评估步骤 4 中的触发条件。如果符合任何条件，请立即在后台启动该独立审查，同时执行步骤 2–3；在步骤 6 前汇总其结果，确保每项修复都经过一次验证。

默认只报告问题；只有收到修复请求或已获得授权时，才应用修复。缺少证据会限制结论。

步骤 2：选择相关的模式文件

不要读取全部 20 个文件。根据下表将变更涉及的部分映射到 1–4 个模式，然后在指出任何问题之前，先读取每个匹配的 patterns/NN-*.md 文件。这些模式包含代码示例和危险信号，可帮助你结合真实 CVE 校准发现的问题。

变更类型 → 主要模式
变更涉及……主要模式次要模式
缓冲区／数组处理（C/C++）01, 1106, 05
新增 API 端点03, 02, 1612, 17
身份验证／登录流程03, 0407, 09
数据库查询02, 0320, 07
文件上传／下载17, 02, 0318, 20
加密操作0405, 11, 15
网络协议10, 0105, 17
配置变更12, 1418, 03
依赖项更新08, 1415
锁文件偏移（无 package.json Δ）0813, 14
Registry／安装配置08, 1312, 18
CI/CD 工作流变更0813, 18
GitHub Actions 缓存／OIDC 范围08, 1318, 19
AI Agent 配置（Claude/Cursor 等）08, 1312, 18
重构／清理14, 0706, 05
错误处理0706, 19, 03
日志变更1902, 12
容器／部署18, 1208, 13
序列化／解析02, 17, 0109, 10, 20
并发／多线程0506, 10
用户输入处理02, 1709, 20, 01
前端／UI 代码16, 0209, 03
Go 代码07, 05, 0906, 15
Rust unsafe 块06, 0105, 15
20 种模式（概览）

01 边界与分配 · 02 注入 · 03 身份验证 · 04 密码学规范 · 05 竞态条件 · 06 内存生命周期 · 07 错误处理 · 08 供应链 · 09 类型安全 · 10 状态机 · 11 整数运算 · 12 配置与默认值 · 13 信任边界 · 14 回归预防 · 15 API 契约 · 16 Web 应用安全 · 17 验证与规范化 · 18 沙箱与隔离 · 19 日志与可观测性 · 20 DoS 防护

打印选择结果："应用模式 03、02、16（新增 API 端点，并包含数据库查询）。"

步骤 3：将每种模式应用于差异

对于每种选定的模式：

  1. 阅读 patterns/NN-*.md。
  2. 根据差异以及差异所调用的相关代码，逐项检查其“检查内容”列表。请具体说明——引用 file:line，并将发现与模式的核心问题和危险信号关联起来。
  3. 追踪，不要略读。 如果某种模式要求“向前追踪每个长度字段”或“列出中间件链中的每条路由”，就实际跟踪调用图。如果模式涉及信任边界或修复完整性，请使用 Grep + Read 检查差异之外的代码。
  4. 核实说法。 如果你说“其他地方已处理”，请引用对应行。如果你说“测试涵盖了此情况”，请指出具体测试。绝不要说“可能安全”——请核实，或标记为未经验证。

第 4 步：对抗性审查（适用于非简单差异）

在触发时，从第 1 步后开始。出现以下任一情况时，使用运行时可用的原生委派工具进行独立只读审查；如果委派不可用，请报告无法覆盖的部分：

  • 更改超过 200 行
  • 涉及加密、身份验证、解析器、反序列化或 CI/CD 工作流
  • 引入新的外部服务／新依赖
  • 用户明确要求深入审查

如果已被指定为独立审查者，请完成该审查，并向父级提供证据，不要递归委派。

子 Agent 提示词： “审查指定绝对检出目录中提供的固定 base/head 或本地快照，不要更改文件。你是一名安全审计员。查找可触达的攻击路径，并验证利用所需的假设。没有发现问题也是有效结果；请明确标记未完成的覆盖范围。请考虑：身份验证绕过、通过非显而易见渠道（日志、文件名、标头、模板引擎）注入、大小运算中的整数溢出、检查与使用之间的竞态条件、会以开放方式失败的错误路径、用户输入进入特权上下文的信任边界违规，以及引入回归的重构。对每项发现，说明本地触发条件、可触达性和影响；相关 CVE 只能作为佐证，而非证明，并将其分类为 FIXABLE 或 INVESTIGATE。”

将 FIXABLE 发现纳入第 6 步的 Fix-First 流程。INVESTIGATE 发现仅作信息说明。

第 5 步：目录交叉引用（大型审计时可选）

对于高风险审查（发布审计、新身份验证系统、新加密代码），请将发现与目录文件交叉核对：

  • catalog/missed-in-review.md — 200 个逃过代码审查的漏洞
  • catalog/caught-in-review.md — 通过审计／模糊测试／静态分析／同行审查发现的 106 个漏洞
  • catalog/concurrency-and-crypto-bugs.md — 深入分析 30 个并发与加密故障

这些文件很大：使用 Grep／rg 搜索发现对应的模式、CWE、API 或漏洞特征，只阅读匹配的条目，不要通读整个文件。如果发现与目录中的模式相符，请引用它：“/orders/:id 上的 IDOR —— 与目录中的 I30 特征相同。”

第 6 步：发现与授权修复

每项发现都必须给出处理结论。在仅报告模式下，提出修正建议，但不要更改文件。以下修复分类仅适用于已授权的修复。

输出标题：Security Review: N findings (X critical, Y high, Z informational)

严重性标准：

  • CRITICAL — 可远程利用、身份验证绕过、RCE、数据外泄、权限提升
  • HIGH — 通过已验证身份的访问即可利用、信息泄露、对共享基础设施造成 DoS
  • INFORMATIONAL — 深度防御缺口、卫生问题、当前不可触达的风险模式

每项发现：

[SEVERITY] [pattern NN] file:line
  Problem: <1-2 lines>
  Evidence: <cite the red flag from the pattern file, or the CVE it matches>
  Fix: <concrete patch>

使用与 /review 相同的 Fix-First 启发式，将修复分类为 AUTO-FIX 或 ASK：机械性修复（缺少 Secure／HttpOnly 标志、缺少超时、算法白名单、恒定时间比较、参数化查询）属于 AUTO-FIX。任何需要设计决策的内容（更改身份验证模型、重做错误路径、添加速率限制器）都属于 ASK。

在授权修复模式下，应用范围明确的 AUTO-FIX 项并验证更改后的行为。将 ASK 项汇总到一个 AskUserQuestion 中：

  • 每项包括：严重性标签、模式参考、问题、建议修复方案
  • 选项 A）修复 B）跳过
  • 包含总体建议

应用用户批准的修复。

第 7 步：结论

分别记录发现项、验证覆盖情况和用户对风险的接受情况。跳过的阻塞项仍未解决。请给出以下结论之一：

  • PASS — 必需的覆盖检查已完成，且没有未解决的 CRITICAL 或 HIGH 级发现项。请注明信息性发现项。
  • PASS WITH REMEDIATIONS — 必需的覆盖检查已完成，且曾存在 CRITICAL/HIGH 级发现项，但均已修复并验证（自动修复或经用户批准）。请总结修复内容。
  • INCOMPLETE — 无法获取必需证据或独立审查；不得声称已满足发布条件。
  • FAIL — 存在未解决的 CRITICAL 或 HIGH 级发现项。逐项列出：模式参考、问题内容、修复所需措施。不得合并。

重要规则

  • 标记问题前先阅读模式文件。 红旗和核心问题有助于根据真实 CVE 校准判断。凭记忆标记问题会产生噪声。
  • 引用具体信息。 提供 file:line、匹配的红旗，并尽可能注明 CVE / 目录条目。不要给出含糊的发现项。
  • 模式要求时追踪差异之外的代码。 身份验证、信任边界和回归预防都需要阅读差异涉及的代码，而不仅仅是差异本身。
  • 不要提交、推送或创建 PR。 只在工作树中应用修复。
  • 不要写引言，也不要说“整体看起来不错”。 只给出发现项或结论。

与 /review 的关系

  • /review 是每次发布前检查所用的工作流，涵盖范围偏移、结构性问题、设计、对抗性审查和发布结论。当差异涉及安全敏感区域时，它会调用此技能中的模式文件。
  • /review-security（此技能）是参考库 + 深度审计工作流。可单独用于安全审计，也可让 /review 直接调用相关模式文件。

这两项技能互为补充，并非彼此替代。

评论

支持 Markdown