Back to Details

review-security

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Review

安全审查

This skill is a reference library + workflow. Twenty evidence-based security pattern files live under 
patterns/
. Each one is grounded in specific CVEs, audit findings, and review processes from the Linux kernel, OpenSSL, Chromium, Firefox, curl, Go, Rust, Kubernetes, Next.js, and dozens of other projects.
The skill can be invoked two ways:
  • Standalone: "do a security review of this branch" — run the workflow below end-to-end.
  • As a reference from 
    /review
    :     the pre-landing review skill reads the matching pattern file(s) when a diff touches a security-sensitive area.
Each pattern file contains:
  • The Core Question — the one question to keep in mind
  • What To Check — specific code patterns with examples
  • Red Flags — patterns that signal danger
  • Catalog References — real CVEs demonstrating each pattern
本技能是一个参考库+工作流。20个循证安全模式文件存储在
patterns/
目录下。每个模式文件都基于Linux内核、OpenSSL、Chromium、Firefox、curl、Go、Rust、Kubernetes、Next.js等数十个项目的特定CVE、审计结果和审查流程。
本技能有两种调用方式：
  • 独立调用：“对这个分支进行安全审查”——完整执行以下工作流。
  • 作为
    /review
    的参考    ：预落地审查技能在diff涉及安全敏感区域时，会读取匹配的模式文件。
每个模式文件包含：
  • 核心问题——需要时刻关注的关键问题
  • 检查要点——带有示例的特定代码模式
  • 危险信号——预示风险的模式
  • 目录参考——体现各模式的真实CVE案例

Step 1: Scope the review

步骤1：确定审查范围

Determine what is being reviewed.
  1. If the user named specific files/paths — review those.
  2. Otherwise detect the base branch and take the diff: 
    • gh pr view --json baseRefName -q .baseRefName
      (falls back to 
      gh repo view --json defaultBranchRef -q .defaultBranchRef.name
      , then to 
      main
      ).
    • git fetch origin <base> --quiet && git diff origin/<base>
  3. If there is no diff and no named target, ask the user what they want audited.
Print the target (e.g. "Reviewing branch 
feature/x
against 
main
— 347 lines across 8 files").
明确审查对象。
  1. 如果用户指定了具体文件/路径——审查这些内容。
  2. 否则检测基准分支并获取diff： 
    • gh pr view --json baseRefName -q .baseRefName
      （若失败则回退到
      gh repo view --json defaultBranchRef -q .defaultBranchRef.name
      ，再回退到
      main
      ）。
    • git fetch origin <base> --quiet && git diff origin/<base>
  3. 如果没有diff且未指定目标，请询问用户要审计的内容。
打印审查目标（例如：“正在针对
main
审查分支
feature/x
——涉及8个文件，共347行变更”）。

Step 2: Pick the relevant pattern files

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

Do not read all 20. Map the changed surface area to 1–4 patterns using the table below, then Read each matching 
patterns/NN-*.md
file BEFORE flagging anything. The patterns include code examples and red flags that will calibrate your findings against real CVEs.
无需读取全部20个模式文件。根据变更覆盖范围映射到1-4个模式，然后在标记任何问题之前，先读取每个匹配的
patterns/NN-*.md
文件。这些模式包含代码示例和危险信号，可帮助你对照真实CVE校准审查结果。

Change Type → Primary Patterns

变更类型 → 主要模式

Change touches…Primary patternsSecondary patterns
Buffer/array handling (C/C++)01, 1106, 05
New API endpoint03, 02, 1612, 17
Authentication/login flow03, 0407, 09
Database queries02, 0320, 07
File upload/download17, 02, 0318, 20
Cryptographic operations0405, 11, 15
Network protocol10, 0105, 17
Configuration changes12, 1418, 03
Dependency updates08, 1415
Lockfile drift (no package.json Δ)0813, 14
Registry / install config08, 1312, 18
CI/CD workflow changes0813, 18
GitHub Actions cache / OIDC scope08, 1318, 19
AI agent config (Claude/Cursor/etc)08, 1312, 18
Refactoring/cleanup14, 0706, 05
Error handling0706, 19, 03
Logging changes1902, 12
Container/deployment18, 1208, 13
Serialization/parsing02, 17, 0109, 10, 20
Concurrency/threading0506, 10
User input handling02, 1709, 20, 01
Frontend/UI code16, 0209, 03
Go code07, 05, 0906, 15
Rust 
unsafe
blocks		06, 0105, 15
变更涉及…主要模式次要模式
缓冲区/数组处理（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
注册表/安装配置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

The 20 patterns (at a glance)

20个模式概览

01 Bounds & Allocation · 02 Injection · 03 Auth · 04 Crypto Hygiene · 05 Race Conditions · 06 Memory Lifecycle · 07 Error Handling · 08 Supply Chain · 09 Type Safety · 10 State Machines · 11 Integer Arithmetic · 12 Config & Defaults · 13 Trust Boundaries · 14 Regression Prevention · 15 API Contracts · 16 Web App Security · 17 Validation & Canonicalization · 18 Sandbox & Isolation · 19 Logging & Observability · 20 DoS Resistance
Print the selection: "Applying patterns 03, 02, 16 (new API endpoint with DB query)."
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端点）。”

Step 3: Apply each pattern to the diff

步骤3：将每个模式应用到diff

For each selected pattern:
  1. Read 
    patterns/NN-*.md
    .
  2. Walk its "What To Check" list against the diff and against referenced code the diff calls into. Be specific — cite 
    file:line
    and tie the finding to the pattern's Core Question and a Red Flag.
  3. Trace, don't skim. When a pattern says "trace every length field backward" or "list every route through the middleware chain," actually follow the call graph. Use Grep + Read to inspect code outside the diff when the pattern is about trust boundaries or fix completeness.
  4. Verify claims. If you say "this is handled elsewhere," cite the line. If you say "tests cover this," name the test. Never say "likely safe" — verify or flag as unverified.
对于每个选中的模式：
  1. 读取
    patterns/NN-*.md
    文件。
  2. 对照diff及diff调用的关联代码，逐一检查“检查要点”列表。要具体——引用
    文件:行号
    ，并将发现的问题与模式的核心问题和危险信号关联起来。
  3. 追踪而非浏览。当模式要求“追踪每个长度字段的来源”或“列出中间件链的所有路由”时，务必实际跟进调用图。当模式涉及信任边界或修复完整性时，使用Grep + Read检查diff之外的代码。
  4. 验证断言。如果说“此问题在其他地方已处理”，请引用具体行号。如果说“测试已覆盖此内容”，请指明测试名称。绝不说“可能安全”——要么验证，要么标记为未验证。

Step 4: Adversarial pass (for non-trivial diffs)

步骤4：对抗性检查（针对非微小diff）

Dispatch an adversarial subagent via Agent when any of:
  • More than 200 lines changed
  • Touches crypto, auth, parsers, deserialization, or CI/CD workflows
  • Introduces a new external service / new dependency
  • User explicitly requested deep review
Subagent prompt: "Read the diff for this branch with 
git diff origin/<base>
. You are a security auditor. Assume the author wrote the happy path and missed at least one attack vector. Find it. Consider: authentication bypasses, injection via non-obvious channels (logs, filenames, headers, template engines), integer overflow in size arithmetic, race conditions between check and use, error paths that fail open, trust-boundary violations where user input reaches a privileged context, and regression-introducing refactors. For each finding, cite the CVE or public incident it pattern-matches to, and classify as FIXABLE or INVESTIGATE."
Fold FIXABLE findings into the Fix-First pipeline in Step 6. INVESTIGATE findings are informational.
当出现以下任一情况时，通过Agent调度对抗性子代理：
  • 变更行数超过200行
  • 涉及加密、身份验证、解析器、反序列化或CI/CD工作流
  • 引入新的外部服务/新依赖项
  • 用户明确要求深度审查
子代理提示： “使用
git diff origin/<base>
读取此分支的diff。你是一名安全审计员。假设作者只考虑了正常流程，至少遗漏了一个攻击向量。找出这个向量。考虑：身份验证绕过、非明显渠道（日志、文件名、标头、模板引擎）注入、大小运算中的整数溢出、检查与使用之间的竞争条件、错误路径导致的权限开放、用户输入进入特权上下文的信任边界违规，以及引入回归的重构。对于每个发现，引用与其匹配的CVE或公开事件，并分类为FIXABLE（可修复）或INVESTIGATE（需调查）。”
将FIXABLE发现纳入步骤6的优先修复流程。INVESTIGATE发现为信息性内容。

Step 5: Catalog cross-reference (optional, for big audits)

步骤5：目录交叉参考（可选，针对大型审计）

For high-stakes reviews (release audits, new auth systems, new crypto code), cross-reference findings against the catalog files:
  • catalog/missed-in-review.md
    — 200 bugs that slipped through code review
  • catalog/caught-in-review.md
    — 106 bugs caught by audits / fuzzing / static analysis / peer review
  • catalog/concurrency-and-crypto-bugs.md
    — deep dive on 30 concurrency + crypto failures
If a finding matches a cataloged pattern, cite it: "IDOR on 
/orders/:id
— same shape as I30 in catalog."
对于高风险审查（发布审计、新身份验证系统、新加密代码），将发现的问题与目录文件交叉参考：
  • catalog/missed-in-review.md
    ——200个通过代码审查但未被发现的漏洞
  • catalog/caught-in-review.md
    ——106个通过审计/模糊测试/静态分析/同行审查发现的漏洞
  • catalog/concurrency-and-crypto-bugs.md
    ——30个并发+加密故障的深度分析
如果发现的问题与目录中的模式匹配，请引用：“
/orders/:id
上的IDOR漏洞——与目录中的I30模式一致。”

Step 6: Fix-First output

步骤6：优先修复输出

Every finding gets action.
Output header: 
Security Review: N findings (X critical, Y high, Z informational)
Severity rubric:
  • CRITICAL — remotely exploitable, authentication bypass, RCE, data exfiltration, privilege escalation
  • HIGH — exploitable with authenticated access, information disclosure, DoS on shared infra
  • INFORMATIONAL — defense-in-depth gaps, hygiene issues, risky patterns that are not currently reachable
For each finding:
[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>
Classify AUTO-FIX vs ASK with the same Fix-First heuristic as 
/review
: mechanical fixes (missing 
Secure
/
HttpOnly
flags, missing timeout, algorithm allowlist, constant-time compare, parameterized query) are AUTO-FIX. Anything requiring a design decision (change auth model, rework error path, add rate limiter) is ASK.
Auto-fix AUTO-FIX items directly. Batch ASK items into one 
AskUserQuestion
:
  • Each item: severity label, pattern reference, problem, recommended fix
  • Options A) Fix B) Skip
  • Include overall RECOMMENDATION
Apply user-approved fixes.
每个发现的问题都要处理。
输出标题：
安全审查：共N个发现（X个严重，Y个高风险，Z个信息性）
严重程度标准：
  • CRITICAL（严重）——可远程利用、身份验证绕过、远程代码执行（RCE）、数据泄露、权限提升
  • HIGH（高风险）——需认证访问才可利用、信息泄露、共享基础设施上的DoS
  • INFORMATIONAL（信息性）——纵深防御缺口、卫生问题、当前不可利用的风险模式
每个发现的格式：
[严重程度] [模式NN] 文件:行号
  问题：<1-2行描述>
  证据：<引用模式文件中的危险信号，或匹配的CVE>
  修复方案：<具体补丁>
按照与
/review
相同的优先修复规则，将问题分类为AUTO-FIX（自动修复）或ASK（需询问）：机械性修复（缺失
Secure
/
HttpOnly
标志、缺失超时、算法白名单、常量时间比较、参数化查询）属于AUTO-FIX。任何需要设计决策的内容（更改身份验证模型、重构错误路径、添加速率限制器）属于ASK。
直接自动修复AUTO-FIX项。将ASK项批量整理为一个
AskUserQuestion
：
  • 每个项：严重程度标签、模式参考、问题描述、推荐修复方案
  • 选项A) 修复 B) 跳过
  • 包含总体建议
应用用户批准的修复方案。

Step 7: Verdict

步骤7：结论

Issue one of:
  • PASS — no CRITICAL or HIGH findings unresolved. Informational findings noted.
  • PASS WITH REMEDIATIONS — CRITICAL/HIGH findings existed but were all fixed (auto-fixed or user-approved). Summarize what was fixed.
  • FAIL — unresolved CRITICAL or HIGH findings. List each: pattern reference, what's broken, what's needed to fix it. Do NOT merge.
给出以下结论之一：
  • PASS（通过）——无未解决的CRITICAL或HIGH级发现。已记录信息性发现。
  • PASS WITH REMEDIATIONS（修复后通过）——存在CRITICAL/HIGH级发现，但已全部修复（自动修复或用户批准修复）。总结修复内容。
  • FAIL（不通过）——存在未解决的CRITICAL或HIGH级发现。列出每个发现：模式参考、问题点、修复所需操作。禁止合并。

Important rules

重要规则

  • Read the pattern file before flagging. The red flags and Core Question calibrate your judgment against real CVEs. Flagging from memory produces noise.
  • Cite specifics. 
    file:line
    , the red flag you matched, and when possible the CVE / catalog entry. No vague findings.
  • Trace outside the diff when the pattern demands it. Auth, trust boundaries, and regression prevention all require reading code the diff touches — not just the diff itself.
  • Do not commit, push, or create PRs. Apply fixes in the working tree only.
  • No preamble, no "looks good overall." Findings or verdict — that's it.
  • 标记问题前务必读取模式文件。危险信号和核心问题可帮助你对照真实CVE校准判断。凭记忆标记会产生无效结果。
  • 引用具体内容。包括
    文件:行号
    、匹配的危险信号，尽可能引用CVE/目录条目。禁止模糊的发现。
  • 当模式要求时，追踪diff之外的代码。身份验证、信任边界和回归预防都需要读取diff涉及的代码——而不仅仅是diff本身。
  • 请勿提交、推送或创建PR。仅在工作树中应用修复。
  • 无需开场白，无需“整体看起来不错”。只输出发现的问题或结论。

Relationship to 
/review

与
/review
的关系

  • /review
    is the workflow for every pre-landing check — scope drift, structural issues, design, adversarial, landing verdict. It calls into this skill's pattern files when a diff touches a security-sensitive surface area.
  • /review-security
    (this skill) is the reference library + deep audit workflow. Use it standalone for security audits, or let 
    /review
    pull the relevant pattern files inline.
The two skills are complements, not replacements.
  • /review
    是所有预落地检查的工作流——包括范围漂移、结构问题、设计、对抗性检查、落地结论。当diff涉及安全敏感区域时，它会调用本技能的模式文件。
  • /review-security
    （本技能）是参考库+深度审计工作流。可独立用于安全审计，也可让
    /review
    内联调用相关模式文件。
这两个技能互为补充，而非替代。