Back to Details

nemoclaw-maintainer-security-code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Code Review

安全代码审查

Perform a thorough security review of the changes in a GitHub PR or issue, producing a structured report with per-category verdicts.
对GitHub PR或issue中的变更内容进行全面安全审查，生成带有分类结论的结构化报告。

Prerequisites

前置条件

  • gh
    (GitHub CLI) must be installed and authenticated.
  • git
    must be available.
  • Network access to clone repositories and fetch PR metadata.
  • 必须安装并认证 
    gh
    （GitHub CLI）。
  • 需具备 
    git
    环境。
  • 拥有克隆仓库和获取PR元数据的网络权限。

When to Use

使用场景

  • Reviewing a pull request before merge for security vulnerabilities.
  • Triaging a GitHub issue that reports a potential security flaw.
  • Auditing code changes for hardcoded secrets, injection flaws, auth bypasses, or insecure configurations.
  • 合并前审查拉取请求中的安全漏洞。
  • 分类处理报告潜在安全缺陷的GitHub issue。
  • 审计代码变更中的硬编码密钥、注入缺陷、身份验证绕过或不安全配置。

Step 1: Parse the GitHub URL

步骤1：解析GitHub URL

If the user provided a PR or issue URL, extract the owner, repo, and number. If not, ask for one.
Supported URL formats:
  • https://github.com/OWNER/REPO/pull/NUMBER
  • https://github.com/OWNER/REPO/issues/NUMBER
如果用户提供了PR或issue URL，提取所有者、仓库和编号。若未提供，则向用户索要。
支持的URL格式：
  • https://github.com/OWNER/REPO/pull/NUMBER
  • https://github.com/OWNER/REPO/issues/NUMBER

Step 2: Check Out the Code

步骤2：检出代码

Determine whether you are already in the target repository (compare 
gh repo view --json nameWithOwner -q .nameWithOwner
against the URL). If you are:
bash
gh pr checkout <number>
If reviewing a different repo, clone it to a temporary directory first:
bash
TMPDIR=$(mktemp -d)
gh repo clone OWNER/REPO "$TMPDIR"
cd "$TMPDIR"
gh pr checkout <number>
判断当前是否已在目标仓库中（对比 
gh repo view --json nameWithOwner -q .nameWithOwner
与URL中的信息）。如果已在目标仓库：
bash
gh pr checkout <number>
如果审查的是其他仓库，先将其克隆到临时目录：
bash
TMPDIR=$(mktemp -d)
gh repo clone OWNER/REPO "$TMPDIR"
cd "$TMPDIR"
gh pr checkout <number>

Step 3: Identify Changed Files

步骤3：识别变更文件

List all files changed relative to the base branch:
bash
git diff main...HEAD --name-status
If the PR targets a branch other than 
main
, use the correct base. Check with:
bash
gh pr view <number> --json baseRefName -q .baseRefName
列出相对于基准分支的所有变更文件：
bash
git diff main...HEAD --name-status
如果PR的目标分支不是 
main
，使用正确的基准分支。可通过以下命令查看：
bash
gh pr view <number> --json baseRefName -q .baseRefName

Step 4: Read Every Changed File and Diff

步骤4：读取所有变更文件和差异内容

Read the full content of each changed file and the diff for that file:
bash
git diff main...HEAD -- <file>
For large PRs (more than 30 changed files), prioritize files in this order:
  1. Files that handle authentication, authorization, or credentials.
  2. Files that process user input (API handlers, CLI argument parsing, URL parsing).
  3. Configuration files (Dockerfiles, YAML policies, environment configs).
  4. New dependencies (package.json, requirements.txt, go.mod changes).
  5. Everything else.
读取每个变更文件的完整内容及其差异：
bash
git diff main...HEAD -- <file>
对于大型PR（变更文件超过30个），按以下优先级处理文件：
  1. 处理身份验证、授权或凭据的文件。
  2. 处理用户输入的文件（API处理器、CLI参数解析、URL解析）。
  3. 配置文件（Dockerfiles、YAML策略、环境配置）。
  4. 新增依赖（package.json、requirements.txt、go.mod变更）。
  5. 其他所有文件。

Step 5: Analyze Against the Security Checklist

步骤5：对照安全清单分析

For each of the 9 categories below, assign a verdict:
  • PASS — no issues found (brief justification).
  • WARNING — potential concern (describe risk and suggested fix).
  • FAIL — confirmed vulnerability (describe impact, severity, and remediation).
针对以下9个分类，分别给出结论：
  • PASS — 未发现问题（简要说明理由）。
  • WARNING — 潜在风险（描述风险及建议修复方案）。
  • FAIL — 已确认漏洞（描述影响、严重程度及补救措施）。

Category 1: Secrets and Credentials

分类1：密钥与凭据

  • No hardcoded secrets, API keys, passwords, tokens, or connection strings in code, configs, or test fixtures.
  • No secrets committed to version control (check for 
    .env
    files, PEM/key files, credential JSON).
  • Tokens and credentials passed via environment variables or secret stores, not string literals.
  • 代码、配置或测试用例中无硬编码密钥、API密钥、密码、令牌或连接字符串。
  • 无密钥提交至版本控制系统（检查 
    .env
    文件、PEM/密钥文件、凭据JSON）。
  • 令牌和凭据通过环境变量或密钥存储传递，而非字符串字面量。

Category 2: Input Validation and Data Sanitization

分类2：输入验证与数据清理

  • All user-controlled inputs (APIs, forms, URLs, headers, query params, file uploads) are validated against an allowlist of expected types, lengths, and formats.
  • Proper encoding and escaping to prevent XSS, SQL injection, command injection, path traversal, and SSRF.
  • Deserialization of untrusted data uses safe parsers (no 
    pickle.loads
    , 
    yaml.unsafe_load
    , 
    eval
    , 
    new Function
    , or similar).
  • 所有用户可控输入（API、表单、URL、请求头、查询参数、文件上传）均对照预期类型、长度和格式的允许列表进行验证。
  • 采用适当的编码和转义，防止XSS、SQL注入、命令注入、路径遍历和SSRF。
  • 反序列化不可信数据时使用安全解析器（禁止使用 
    pickle.loads
    、
    yaml.unsafe_load
    、
    eval
    、
    new Function
    或类似方法）。

Category 3: Authentication and Authorization

分类3：身份验证与授权

  • All new or modified endpoints enforce authentication before processing requests.
  • Authorization logic ensures users can only access or modify resources they own or are permitted to use.
  • No privilege escalation paths (horizontal or vertical).
  • Token validation (expiry, signature, scope) is correctly implemented.
  • 所有新增或修改的端点在处理请求前均强制进行身份验证。
  • 授权逻辑确保用户仅能访问或修改其拥有或被允许使用的资源。
  • 无权限提升路径（横向或纵向）。
  • 令牌验证（过期时间、签名、权限范围）已正确实现。

Category 4: Dependencies and Third-Party Libraries

分类4：依赖与第三方库

  • Newly added dependencies checked for known CVEs (OSV, Snyk, GitHub Advisory DB).
  • Dependencies pinned to specific, secure versions (no floating ranges in production).
  • OSS license compatibility not violated.
  • Dependencies pulled from trusted registries only.
  • 新增依赖已检查已知CVE（OSV、Snyk、GitHub Advisory DB）。
  • 依赖固定到特定的安全版本（生产环境中无浮动版本范围）。
  • 未违反开源软件许可证兼容性。
  • 仅从可信注册表拉取依赖。

Category 5: Error Handling and Logging

分类5：错误处理与日志记录

  • Error responses do not leak stack traces, internal paths, or sensitive data.
  • Logging does not record secrets, tokens, passwords, or PII.
  • Exceptions caught at appropriate boundaries; no unhandled crashes that expose state.
  • 错误响应不会泄露堆栈跟踪、内部路径或敏感数据。
  • 日志不会记录密钥、令牌、密码或个人身份信息（PII）。
  • 在适当的边界捕获异常；无未处理崩溃暴露系统状态。

Category 6: Cryptography and Data Protection

分类6：加密与数据保护

  • Standard, up-to-date algorithms (AES-256-GCM, RSA-2048+, SHA-256+).
  • No MD5 or SHA-1 for security purposes. No custom cryptography.
  • Sensitive data encrypted at rest and in transit where applicable.
  • 使用标准、最新的算法（AES-256-GCM、RSA-2048+、SHA-256+）。
  • 安全场景下禁止使用MD5或SHA-1。禁止自定义加密实现。
  • 敏感数据在静止和传输状态下均已加密（如适用）。

Category 7: Configuration and Security Headers

分类7：配置与安全头部

  • Secure defaults (debug mode off, restrictive permissions, minimal port exposure).
  • If HTTP endpoints are present: CSP and CORS configured correctly. No wildcard origins in authenticated contexts.
  • Container images use non-root users, minimal base images, and pinned digests.
  • 安全默认设置（调试模式关闭、权限限制、最小端口暴露）。
  • 若存在HTTP端点：正确配置CSP和CORS。认证场景下无通配符源。
  • 容器镜像使用非root用户、最小化基础镜像，并固定摘要值。

Category 8: Security Testing

分类8：安全测试

  • Tests cover security edge cases: malicious input, boundary values, unauthorized access attempts.
  • Existing security test coverage not degraded by the change.
  • Negative test cases verify that forbidden actions are denied.
  • 测试覆盖安全边缘场景：恶意输入、边界值、未授权访问尝试。
  • 变更未降低现有安全测试覆盖率。
  • 负面测试用例验证禁止操作是否被拦截。

Category 9: Holistic Security Posture

分类9：整体安全态势

  • Changes do not degrade overall security posture.
  • No false sense of security (client-only validation, incomplete checks).
  • Least privilege followed for code, services, and users.
  • No TOCTOU race conditions in security-critical paths.
  • No unsafe concurrency that bypasses security checks.
  • 变更未降低整体安全态势。
  • 无虚假安全感（仅客户端验证、不完整检查）。
  • 代码、服务和用户遵循最小权限原则。
  • 安全关键路径中无TOCTOU竞争条件。
  • 无绕过安全检查的不安全并发操作。

Step 6: Produce the Report

步骤6：生成报告

Structure the output as follows:
输出结构如下：

Verdict

结论

One paragraph summarizing the overall risk assessment and whether the PR is safe to merge.
用一段文字总结整体风险评估结果，以及该PR是否可安全合并。

Findings Table

发现项表格

One row per finding:
#CategorySeverityFile:LineDescriptionRecommendation
If no findings, state explicitly that the review is clean.
每个发现项占一行：
#分类严重程度文件:行号描述建议
若无发现项，明确说明审查无问题。

Detailed Analysis

详细分析

Per-category breakdown (categories 1 through 9), each with its PASS, WARNING, or FAIL verdict and justification.
按分类（1至9）逐一拆解，每个分类包含其PASS/WARNING/FAIL结论及理由。

Files Reviewed

已审查文件

List every file analyzed.
列出所有已分析的文件。

Important Notes

重要说明

  • If the PR has no changed files or is a draft with no code, state that and skip the analysis.
  • For NemoClaw PRs, pay special attention to sandbox escape vectors: SSRF bypasses, Dockerfile injection, network policy circumvention, credential leakage, and blueprint tampering.
  • Do not skip categories. If a category is not applicable to the changes (e.g., no cryptography involved), mark it PASS with "Not applicable — no cryptographic operations in this change."
  • When in doubt about severity, err on the side of WARNING rather than PASS.
  • 如果PR无变更文件或为无代码的草稿，说明情况并跳过分析。
  • 对于NemoClaw PR，需特别关注沙箱逃逸向量：SSRF绕过、Dockerfile注入、网络策略规避、凭据泄露和蓝图篡改。
  • 请勿跳过分类。若某分类不适用于变更内容（例如，无加密操作），标记为PASS并说明“不适用 — 本次变更无加密操作”。
  • 若对严重程度存疑，优先标记为WARNING而非PASS。