Back to Details

snyk-fix

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Snyk Fix (All-in-One)

Snyk 一站式修复

Complete security remediation workflow in a single command. Scans for vulnerabilities, fixes them, validates the fix, and optionally creates a PR.
Workflow: Parse → Scan → Analyze → Fix → Validate → Summary → (Optional) PR
Modes:
  • Single Mode (default): Fix one vulnerability type at a time
  • Batch Mode: Fix multiple vulnerabilities in priority order
仅需一条命令即可运行完整安全修复工作流：扫描漏洞、执行修复、验证修复效果，还可选择创建PR。
工作流: 解析 → 扫描 → 分析 → 修复 → 验证 → 总结 → （可选）PR
模式:
  • 单问题模式（默认）：一次修复一类漏洞
  • 批量模式：按优先级顺序修复多个漏洞

Example Triggers

触发示例

Single Mode (One Issue)

单问题模式（单个问题）

User RequestBehavior
"fix security issues"Auto-detect scan type, fix highest priority issue (all instances)
"fix code vulnerabilities"SAST scan only, fix highest priority code issue (all instances in file)
"fix dependency vulnerabilities"SCA scan only, fix highest priority dependency issue
"fix SNYK-JS-LODASH-1018905"Fix specific Snyk issue by ID
"fix CVE-2021-44228"Find and fix specific CVE
"fix vulnerabilities in lodash"Fix highest priority issue in lodash package
"fix security issues in server.ts"Code scan on file, fix highest priority issue (all instances)
"fix XSS vulnerabilities"Fix all XSS vulnerabilities in highest priority file
"fix path traversal"Fix all path traversal vulnerabilities
用户请求行为
"fix security issues"自动检测扫描类型，修复最高优先级问题（所有出现的位置）
"fix code vulnerabilities"仅执行SAST扫描，修复最高优先级代码问题（文件中所有出现的位置）
"fix dependency vulnerabilities"仅执行SCA扫描，修复最高优先级依赖问题
"fix SNYK-JS-LODASH-1018905"按ID修复指定Snyk问题
"fix CVE-2021-44228"查找并修复指定CVE
"fix vulnerabilities in lodash"修复lodash包中最高优先级的问题
"fix security issues in server.ts"对指定文件执行代码扫描，修复最高优先级问题（所有出现的位置）
"fix XSS vulnerabilities"修复最高优先级文件中的所有XSS漏洞
"fix path traversal"修复所有路径遍历漏洞

Batch Mode (Multiple Issues)

批量模式（多个问题）

User RequestBehavior
"fix all security issues"Fix ALL vulnerabilities by priority (Critical → Low)
"fix all critical vulnerabilities"Fix only Critical severity issues
"fix all high and critical"Fix Critical and High severity issues
"fix all code vulnerabilities"Fix all SAST issues in the project
"fix all dependency issues"Fix all SCA issues in the project
"fix top 5 vulnerabilities"Fix the 5 highest priority issues
"fix all issues in src/"Fix all vulnerabilities in specified directory
用户请求行为
"fix all security issues"按优先级（严重 → 低危）修复所有漏洞
"fix all critical vulnerabilities"仅修复严重级别问题
"fix all high and critical"修复严重和高危级别问题
"fix all code vulnerabilities"修复项目中所有SAST问题
"fix all dependency issues"修复项目中所有SCA问题
"fix top 5 vulnerabilities"修复优先级最高的5个问题
"fix all issues in src/"修复指定目录下的所有漏洞

Batch Mode Overview

批量模式说明

Batch mode fixes multiple vulnerabilities in a single session. Use when the user says "all", "batch", or specifies a severity filter.
批量模式可在单次会话中修复多个漏洞，当用户提及"all"、"batch"或指定 severity 过滤器时使用。

Batch Mode Workflow

批量模式工作流

1. Scan entire project (SAST + SCA)
2. Filter by severity/type if specified
3. Group vulnerabilities by type and priority
4. For each group (in priority order):
   a. Fix all instances of that vulnerability type
   b. Validate the fix
   c. Track results
5. Generate comprehensive summary
6. Prompt for single PR with all fixes
1. 扫描整个项目（SAST + SCA）
2. 若有指定则按 severity/类型过滤
3. 按类型和优先级对漏洞分组
4. 对每个分组（按优先级顺序）：
   a. 修复该类漏洞的所有出现位置
   b. 验证修复效果
   c. 记录结果
5. 生成完整总结
6. 询问是否创建包含所有修复的单个PR

Batch Mode Limits

批量模式限制

SettingValueNotes
Max vulnerabilities20To avoid overwhelming changes
Max files modified15To keep PRs reviewable
Timeout per fix3 attemptsSame as single mode
Stop on failureConfigurableCan continue or stop
设置值说明
最大漏洞数20避免改动过多
最大修改文件数15保证PR可审核
单次修复超时3次尝试和单问题模式一致
失败时停止可配置可选择继续或停止

Batch Priority Order

批量优先级顺序

  1. Critical with known exploit
  2. Critical without exploit
  3. High with known exploit
  4. High without exploit
  5. Medium severity
  6. Low severity
Within same priority: Code (SAST) issues before SCA issues (code fixes are typically more urgent).
  1. 有已知利用方式的严重漏洞
  2. 无已知利用方式的严重漏洞
  3. 有已知利用方式的高危漏洞
  4. 无已知利用方式的高危漏洞
  5. 中危漏洞
  6. 低危漏洞
同优先级下：代码（SAST）问题优先于SCA问题（代码修复通常更紧急）。

Phase 1: Input Parsing

阶段1：输入解析

Parse user input to extract:
  • mode: Single (default) or Batch (if user says "all", "batch", or specifies count/severity filter)
  • scan_type: Explicit (
    code
    , 
    sca
    , 
    both
    ) or infer from context
  • target_vulnerability: Specific issue ID, CVE, package name, file reference, or vulnerability type
  • target_path: File or directory to focus on (defaults to project root)
  • severity_filter: For batch mode - which severities to include
  • max_fixes: For batch mode - maximum vulnerabilities to fix (default: 20)
解析用户输入提取以下信息：
  • 模式: 单问题（默认）或批量（若用户提及"all"、"batch"或指定数量/severity过滤器）
  • 扫描类型: 显式指定（
    code
    、
    sca
    、
    both
    ）或根据上下文推断
  • 目标漏洞: 特定问题ID、CVE、包名、文件引用或漏洞类型
  • 目标路径: 聚焦的文件或目录（默认项目根目录）
  • severity过滤器: 批量模式下需要包含的漏洞级别
  • 最大修复数: 批量模式下最多修复的漏洞数（默认：20）

Mode Detection Rules

模式检测规则

Batch Mode Indicators:
  • User says "all" (e.g., "fix all vulnerabilities")
  • User specifies severity filter (e.g., "fix all high and critical")
  • User specifies count (e.g., "fix top 5")
  • User says "batch" explicitly
Single Mode (default):
  • User specifies a single vulnerability ID
  • User mentions one vulnerability type
  • User references a specific file
  • No batch indicators present
批量模式触发标识:
  • 用户提及"all"（例如"fix all vulnerabilities"）
  • 用户指定severity过滤器（例如"fix all high and critical"）
  • 用户指定数量（例如"fix top 5"）
  • 用户明确提及"batch"
单问题模式（默认）:
  • 用户指定单个漏洞ID
  • 用户提及一类漏洞
  • 用户引用特定文件
  • 无批量触发标识

Scan Type Detection Rules (in priority order)

扫描类型检测规则（按优先级排序）

  1. Explicit code: User says "code", "sast", "static" → Code scan
  2. Explicit sca: User says "sca", "dependency", "package", "npm", "pip", "maven" → SCA scan
  3. Vulnerability ID provided:
    • Starts with 
      SNYK-
      → run both scans to locate it
    • Contains 
      CVE-
      → run both scans to find it
  4. Vulnerability type provided: User mentions type like "XSS", "SQL injection", "path traversal" → Code scan
  5. File reference: User mentions 
    .ts
    , 
    .js
    , 
    .py
    , etc. file → Code scan on that file
  6. Package reference: User mentions known package name (e.g., "lodash", "express") → SCA scan
  7. Default (no hints): Run BOTH scans, select highest priority issue
  1. 显式指定代码扫描: 用户提及"code"、"sast"、"static" → 代码扫描
  2. 显式指定SCA扫描: 用户提及"sca"、"dependency"、"package"、"npm"、"pip"、"maven" → SCA扫描
  3. 提供漏洞ID:
    • 以
      SNYK-
      开头 → 运行两种扫描定位漏洞
    • 包含
      CVE-
      → 运行两种扫描查找漏洞
  4. 提供漏洞类型: 用户提及"XSS"、"SQL injection"、"路径遍历"等类型 → 代码扫描
  5. 文件引用: 用户提及
    .ts
    、
    .js
    、
    .py
    等文件 → 对该文件执行代码扫描
  6. 包引用: 用户提及已知包名（例如"lodash"、"express"） → SCA扫描
  7. 默认（无提示）: 运行两种扫描，选择最高优先级问题

Phase 1B: Batch Mode Planning (Skip if Single Mode)

阶段1B：批量模式规划（单问题模式跳过）

Only execute this phase if Batch Mode was detected in Phase 1.
仅当阶段1检测到批量模式时执行该阶段。

Step 1B.1: Run Full Project Scan

步骤1B.1：执行全项目扫描

Run comprehensive scans to discover all vulnerabilities:
Run both scans:
- mcp_snyk_snyk_code_scan with path = project root
- mcp_snyk_snyk_sca_scan with path = project root
运行全面扫描发现所有漏洞：
运行两种扫描：
- mcp_snyk_snyk_code_scan 路径 = 项目根目录
- mcp_snyk_snyk_sca_scan 路径 = 项目根目录

Step 1B.2: Filter Results

步骤1B.2：过滤结果

Apply user-specified filters:
FilterExampleResult
Severity"critical only"Only Critical vulns
Severity"high and critical"Critical + High
Type"code vulnerabilities"Only SAST results
Type"dependency issues"Only SCA results
Path"in src/"Only vulns in src/
Count"top 5"First 5 by priority
应用用户指定的过滤器：
过滤器示例结果
Severity"critical only"仅严重漏洞
Severity"high and critical"严重+高危漏洞
类型"code vulnerabilities"仅SAST结果
类型"dependency issues"仅SCA结果
路径"in src/"仅src/目录下的漏洞
数量"top 5"按优先级取前5个

Step 1B.3: Group and Prioritize

步骤1B.3：分组与优先级排序

Group vulnerabilities for efficient fixing:
  1. Group by type: Same vulnerability ID in same file (code) or same package (SCA)
  2. Sort by priority: Critical > High > Medium > Low
  3. Within priority: Prefer issues with available fixes
对漏洞分组以提升修复效率：
  1. 按类型分组: 同一文件中相同漏洞ID（代码）或同一包（SCA）
  2. 按优先级排序: 严重 > 高危 > 中危 > 低危
  3. 同优先级下: 优先选择有可用修复的问题

Step 1B.4: Generate Fix Plan

步骤1B.4：生成修复计划

Display the batch fix plan to user:
undefined
向用户展示批量修复计划：
undefined

Batch Fix Plan

批量修复计划

Mode: Batch Remediation Filter: [severity/type/path filter if any] Total Vulnerabilities: [count]
模式: 批量修复 过滤器: [若有则展示severity/类型/路径过滤器] 总漏洞数: [数量]

Fix Order

修复顺序

#TypeSeverityTargetInstances
1CodeHighSQL Injection in db.ts3
2SCACriticallog4j-core@2.14.11
3CodeHighXSS in api/render.ts2
4SCAHighlodash@4.17.151
5CodeHighPath Traversal in files.ts4
Estimated Changes: [X files, Y packages]
#类型Severity目标出现次数
1代码高危db.ts中的SQL Injection3
2SCA严重log4j-core@2.14.11
3代码高危api/render.ts中的XSS2
4SCA高危lodash@4.17.151
5代码高危files.ts中的路径遍历4
预计改动: [X个文件，Y个包]

Proceed with batch fix? (yes/no/adjust)

是否继续执行批量修复？(是/否/调整)


**Wait for user confirmation before proceeding.**

If user says "adjust", allow them to modify the plan (exclude items, change order, etc.).

**继续前需等待用户确认。**

若用户回复"adjust"，允许其修改计划（排除项、调整顺序等）。

Step 1B.5: Execute Batch Fixes

步骤1B.5：执行批量修复

For each vulnerability group in the plan:
  1. Execute the appropriate fix phase (Phase 3 for Code, Phase 4 for SCA)
  2. Validate the fix (Phase 5)
  3. Track result (success/failure/partial)
  4. If failure and 
    stop_on_failure=true
    : Stop and report
  5. If failure and 
    stop_on_failure=false
    : Continue to next item
After all fixes attempted, proceed to Phase 6B (Batch Summary).
对计划中的每个漏洞分组：
  1. 执行对应修复阶段（代码问题执行阶段3，SCA问题执行阶段4）
  2. 验证修复效果（阶段5）
  3. 记录结果（成功/失败/部分成功）
  4. 若失败且
    stop_on_failure=true
    ：停止并上报
  5. 若失败且
    stop_on_failure=false
    ：继续处理下一项
所有修复尝试完成后，进入阶段6B（批量总结）。

Phase 2: Discovery

阶段2：漏洞发现

Goal: Run scan(s) and identify the vulnerability type to fix, including ALL instances of that type in the same file (for code vulnerabilities)
目标: 运行扫描确定要修复的漏洞类型，包含同类型漏洞在同一文件中的所有出现位置（代码漏洞适用）

Step 2.1: Run Security Scan(s)

步骤2.1：执行安全扫描

Based on scan type detection:
  • Code only: Run 
    mcp_snyk_snyk_code_scan
    with 
    path
    set to project root or specific file
  • SCA only: Run 
    mcp_snyk_snyk_sca_scan
    with 
    path
    set to project root
  • Both: Run both scans in parallel
基于扫描类型检测结果：
  • 仅代码扫描: 运行
    mcp_snyk_snyk_code_scan
    ，
    path
    设为项目根目录或指定文件
  • 仅SCA扫描: 运行
    mcp_snyk_snyk_sca_scan
    ，
    path
    设为项目根目录
  • 两种都执行: 并行运行两个扫描

Step 2.2: Select Target Vulnerability Type

步骤2.2：选择目标漏洞类型

If user specified a vulnerability:
  • Search scan results for matching issue (by ID, CVE, package name, vulnerability type, or description)
  • If NOT found: Report "Vulnerability not found in scan results" and STOP
  • If found: Note whether it's a Code or SCA issue
If user did NOT specify a vulnerability:
  • From ALL scan results, select the highest priority vulnerability TYPE using this priority:
    1. Critical severity with known exploit
    2. Critical severity
    3. High severity with known exploit
    4. High severity
    5. Medium severity
    6. Low severity
  • Within same priority: prefer issues with available fixes/upgrades
若用户指定了漏洞:
  • 在扫描结果中搜索匹配的问题（按ID、CVE、包名、漏洞类型或描述）
  • 未找到：上报"扫描结果中未找到该漏洞"并停止
  • 已找到：标记是代码问题还是SCA问题
若用户未指定漏洞:
  • 从所有扫描结果中，按以下优先级选择最高优先级的漏洞类型：
    1. 有已知利用方式的严重漏洞
    2. 严重漏洞
    3. 有已知利用方式的高危漏洞
    4. 高危漏洞
    5. 中危漏洞
    6. 低危漏洞
  • 同优先级下：优先选择有可用修复/升级的问题

Step 2.3: Group All Instances (Code Vulnerabilities Only)

步骤2.3：分组所有出现位置（仅代码漏洞适用）

IMPORTANT for Code vulnerabilities: After selecting the vulnerability type, find ALL instances of that same vulnerability type in the same file:
  • Same vulnerability ID (e.g., 
    javascript/PT
    , 
    javascript/XSS
    , 
    python/SQLi
    )
  • In the same file
Example: If scan finds:
High    Path Traversal    src/api/files.ts:45    javascript/PT
High    Path Traversal    src/api/files.ts:112   javascript/PT  
High    XSS               src/api/files.ts:78    javascript/XSS
And Path Traversal is selected as highest priority, target BOTH lines 45 and 112.
代码漏洞重要说明: 选定漏洞类型后，查找同一文件中该类漏洞的所有出现位置：
  • 相同漏洞ID（例如
    javascript/PT
    、
    javascript/XSS
    、
    python/SQLi
    ）
  • 位于同一文件
示例: 若扫描发现：
High    Path Traversal    src/api/files.ts:45    javascript/PT
High    Path Traversal    src/api/files.ts:112   javascript/PT  
High    XSS               src/api/files.ts:78    javascript/XSS
若路径遍历被选为最高优先级，则同时修复第45行和第112行。

Step 2.4: Document Target

步骤2.4：记录目标信息

For Code vulnerabilities:
undefined
代码漏洞:
undefined

Target Vulnerability

目标漏洞

  • Type: Code (SAST)
  • ID: [Snyk ID] (e.g., javascript/PT)
  • Severity: [Critical | High | Medium | Low]
  • Title: [vulnerability title]
  • CWE: [CWE-XXX if available]
  • Instances to Fix: [count]
#FileLineDescription
1[file][line][brief context]
2[file][line][brief context]

**For SCA vulnerabilities:**
  • 类型: 代码（SAST）
  • ID: [Snyk ID]（例如javascript/PT）
  • Severity: [Critical | High | Medium | Low]
  • 标题: [漏洞标题]
  • CWE: [若有则填CWE-XXX]
  • 待修复次数: [数量]
#文件行号描述
1[文件][行号][简要上下文]
2[文件][行号][简要上下文]

**SCA漏洞:**

Target Vulnerability

目标漏洞

  • Type: SCA (Dependency)
  • ID: [Snyk Issue ID]
  • Severity: [Critical | High | Medium | Low]
  • Package: [package@current_version]
  • Title: [vulnerability title]
  • Fix Version: [minimum version that fixes]
  • Dependency Path: [direct | transitive via X → Y → Z]

---
  • 类型: SCA（依赖）
  • ID: [Snyk 问题ID]
  • Severity: [Critical | High | Medium | Low]
  • 包: [package@当前版本]
  • 标题: [漏洞标题]
  • 修复版本: [修复该漏洞的最低版本]
  • 依赖路径: [直接依赖 | 间接依赖，路径为X → Y → Z]

---

Phase 3: Remediation (Code Vulnerabilities)

阶段3：修复（代码漏洞）

Skip to Phase 4 if this is an SCA vulnerability.
若为SCA漏洞请跳至阶段4。

Step 3.1: Understand the Vulnerability

步骤3.1：理解漏洞

  • Read the affected file and ALL vulnerable locations
  • Identify the vulnerability type:
    • Injection (SQL, Command, LDAP, etc.)
    • XSS (Cross-Site Scripting)
    • Path Traversal
    • Sensitive Data Exposure
    • Insecure Deserialization
    • Security Misconfiguration
    • Cryptographic Issues
    • Other (check Snyk description)
  • Review Snyk's remediation guidance if provided
  • Look for patterns across instances (often the same fix approach applies)
  • 读取受影响文件和所有漏洞位置
  • 确定漏洞类型：
    • 注入（SQL、命令、LDAP等）
    • XSS（跨站脚本）
    • 路径遍历
    • 敏感数据泄露
    • 不安全反序列化
    • 安全配置错误
    • 加密问题
    • 其他（参考Snyk描述）
  • 查看Snyk提供的修复指引（若有）
  • 查找不同出现位置的共同模式（通常相同修复方法适用）

Step 3.2: Plan the Fix

步骤3.2：规划修复方案

Before implementing, document the approach:
undefined
实现前记录修复方案：
undefined

Fix Plan

修复计划

  • Vulnerability Type: [type]
  • Root Cause: [why the code is vulnerable]
  • Fix Approach: [what will be changed]
  • Security Mechanism: [what protection is being added]
  • Instances Affected: [count] locations in [file]

Common fix patterns:
| Vulnerability | Fix Pattern |
|---------------|-------------|
| SQL Injection | Parameterized queries / prepared statements |
| Command Injection | Input validation + shell escaping or avoid shell |
| Path Traversal | Canonicalize path + validate against allowed base |
| XSS | Output encoding / sanitization appropriate to context |
| Sensitive Data Exposure | Remove/mask data, use secure headers |
| Hardcoded Secrets | Move to environment variables / secrets manager |
  • 漏洞类型: [类型]
  • 根本原因: [代码存在漏洞的原因]
  • 修复方案: [将修改的内容]
  • 安全机制: [新增的防护措施]
  • 受影响位置: [文件]中的[数量]个位置

常见修复模式：
| 漏洞 | 修复模式 |
|---------------|-------------|
| SQL Injection | 参数化查询 / 预编译语句 |
| Command Injection | 输入校验 + shell转义或避免使用shell |
| 路径遍历 | 规范化路径 + 校验是否在允许的基础路径内 |
| XSS | 适配上下文的输出编码 /  sanitization |
| 敏感数据泄露 | 删除/掩码处理数据，使用安全头 |
| 硬编码密钥 | 迁移至环境变量 / 密钥管理服务 |

Step 3.3: Apply the Fix to ALL Instances

步骤3.3：对所有位置应用修复

  • Fix ALL identified instances of the vulnerability type in the file
  • Apply consistent fix pattern across all instances
  • Make the minimal code change needed at each location
  • Prefer standard library/framework security features over custom solutions
  • Consider creating a shared helper function if:
    • 3+ instances exist with identical fix pattern
    • The helper improves readability without over-engineering
  • Add comments explaining security-relevant changes if non-obvious
  • Do NOT refactor unrelated code
  • Do NOT change business logic
Order of fixes: Fix from bottom of file to top (highest line number first) to avoid line number shifts affecting subsequent fixes.
Continue to Phase 5 (Validation).
  • 修复文件中该类漏洞的所有已识别位置
  • 所有位置应用统一的修复模式
  • 每个位置仅做必要的最小代码改动
  • 优先使用标准库/框架的安全特性，而非自定义方案
  • 符合以下条件可考虑创建共享工具函数：
    • 存在3个以上相同修复模式的位置
    • 工具函数可提升可读性且不会过度设计
  • 若安全相关改动不直观，添加注释说明
  • 不要重构无关代码
  • 不要修改业务逻辑
修复顺序: 从文件底部到顶部修复（先处理行号大的），避免行号偏移影响后续修复。
进入阶段5（验证）。

Phase 4: Remediation (SCA Vulnerabilities)

阶段4：修复（SCA漏洞）

Skip to Phase 5 if this is a Code vulnerability (already handled in Phase 3).
若为代码漏洞请跳至阶段5（已在阶段3处理）。

Step 4.1: Analyze Dependency Path

步骤4.1：分析依赖路径

  • Document the full dependency path (direct → transitive → vulnerable)
  • Identify manifest files to modify (
    package.json
    , 
    requirements.txt
    , etc.)
  • Determine if vulnerable package is direct or transitive
For transitive dependencies:
  • Identify which direct dependency pulls in the vulnerable transitive
  • Check if upgrading the direct dependency will pull in the fixed transitive
  • If app directly imports the transitive: note this for breaking change analysis
  • 记录完整依赖路径（直接依赖 → 间接依赖 → 漏洞包）
  • 确定要修改的清单文件（
    package.json
    、
    requirements.txt
    等）
  • 确认漏洞包是直接依赖还是间接依赖
间接依赖处理:
  • 确定是哪个直接依赖引入了有漏洞的间接依赖
  • 检查升级直接依赖是否会引入修复后的间接依赖版本
  • 若应用直接导入了该间接依赖：记录该情况用于破坏性变更分析

Step 4.2: Check for Breaking Changes

步骤4.2：检查破坏性变更

Search codebase for potential impact:
bash
undefined
在代码库中搜索潜在影响：
bash
undefined

Search for imports of the package

搜索该包的导入语句

grep -r "from 'package'" --include=".ts" --include=".js" grep -r "require('package')" --include=".ts" --include=".js"

If complex breaking changes detected:
- Add TODO comments with migration notes
- Note in summary that manual review is needed
grep -r "from 'package'" --include=".ts" --include=".js" grep -r "require('package')" --include=".ts" --include=".js"

若检测到复杂破坏性变更：
- 添加TODO注释附带迁移说明
- 在总结中注明需要人工审核

Step 4.3: Apply Minimal Upgrade

步骤4.3：应用最小升级

  • Edit ONLY the necessary dependency in the manifest
  • Use the LOWEST version that fixes the vulnerability
  • Preserve file formatting and comments
Example (package.json):
json
// Before
"lodash": "^4.17.15"

// After - minimal fix
"lodash": "^4.17.21"
  • 仅修改清单文件中必要的依赖
  • 使用可修复漏洞的最低版本
  • 保留文件格式和注释
示例（package.json）:
json
// 修改前
"lodash": "^4.17.15"

// 修改后 - 最小修复
"lodash": "^4.17.21"

Step 4.4: Regenerate Lockfile

步骤4.4：重新生成锁文件

Run the appropriate install command:
Package ManagerCommand
npm (major upgrade)
npm install <pkg>@<version>
npm (minor/patch)
npm install
yarn
yarn install
or 
yarn upgrade <pkg>@<version>
pip
pip install -r requirements.txt
maven
mvn dependency:resolve
If installation fails:
  • If sandbox/permission issue: retry with elevated permissions
  • If dependency conflict: try a different version or note as unfixable
  • Revert manifest changes if resolution completely fails
  • Document the failure reason
运行对应的安装命令：
包管理器命令
npm（大版本升级）
npm install <pkg>@<version>
npm（小版本/补丁升级）
npm install
yarn
yarn install
或 
yarn upgrade <pkg>@<version>
pip
pip install -r requirements.txt
maven
mvn dependency:resolve
若安装失败:
  • 若为沙箱/权限问题：使用更高权限重试
  • 若为依赖冲突：尝试其他版本或标记为无法修复
  • 若依赖解析完全失败，回滚清单文件改动
  • 记录失败原因

Phase 5: Validation

阶段5：验证

Step 5.1: Re-run Security Scan

步骤5.1：重新运行安全扫描

  • Run 
    mcp_snyk_snyk_code_scan
    or 
    mcp_snyk_snyk_sca_scan
    on the same target
  • Verify ALL targeted vulnerability instances are NO LONGER reported
For Code vulnerabilities - If any instances still present:
  • Review the fix attempt for that specific instance
  • Try alternative approach
  • Maximum 3 total attempts per instance, then report partial success/failure
For SCA vulnerabilities - If vulnerability still present:
  • Check if lockfile was properly updated
  • Try explicit version install: 
    npm install <pkg>@<exact_version>
  • Maximum 3 attempts, then STOP and report failure
If NEW vulnerabilities introduced:
For Code:
  • Code fixes must be clean — no new vulnerabilities allowed
  • Attempt to fix any new issues introduced by your fix
  • Iterate until clean (max 3 total attempts)
  • If unable to produce clean fix: Revert ALL changes and report failure
For SCA:
  • Check severity trade-off:
    • New severity LOWER than fixed: Accept (net security improvement)
    • New severity EQUAL OR HIGHER: Try higher version (up to 3 iterations)
    • If no clean version exists: Revert and report as unfixable
  • 对同一目标运行
    mcp_snyk_snyk_code_scan
    或
    mcp_snyk_snyk_sca_scan
  • 确认所有目标漏洞实例不再被报告
代码漏洞 - 若仍有实例存在:
  • 检查该位置的修复尝试
  • 尝试其他方案
  • 每个实例最多尝试3次，之后上报部分成功/失败
SCA漏洞 - 若漏洞仍存在:
  • 检查锁文件是否正确更新
  • 尝试显式指定版本安装：
    npm install <pkg>@<exact_version>
  • 最多尝试3次，之后停止并上报失败
若引入了新漏洞:
代码漏洞:
  • 代码修复必须干净 — 不允许引入新漏洞
  • 尝试修复本次改动引入的新问题
  • 迭代至无新漏洞（最多尝试3次）
  • 若无法生成干净的修复：回滚所有改动并上报失败
SCA漏洞:
  • 检查严重程度权衡：
    • 新漏洞严重程度低于修复的漏洞：接受（安全净提升）
    • 新漏洞严重程度等于或高于修复的漏洞：尝试更高版本（最多迭代3次）
    • 若无干净版本存在：回滚并上报为无法修复

Step 5.1a: Identify Additional Issues Fixed (SCA Only)

步骤5.1a：识别额外修复的问题（仅SCA适用）

A single upgrade often fixes multiple vulnerabilities:
  • Compare pre-fix and post-fix scan results
  • Identify ALL vulnerabilities resolved by this upgrade
  • Record each: ID, severity, title
单次升级通常会修复多个漏洞：
  • 对比修复前后的扫描结果
  • 识别本次升级解决的所有漏洞
  • 记录每个漏洞的ID、severity、标题

Step 5.2: Run Tests

步骤5.2：运行测试

  • Execute project tests (
    npm test
    , 
    pytest
    , etc.)
  • If tests fail due to the fix:
    • Prefer adjusting the fix over changing tests
    • Only modify tests if the fix legitimately changes expected behavior
    • Apply mechanical fixes only (renamed imports, etc.)
    • Maximum 2 attempts to resolve test failures
  • 执行项目测试（
    npm test
    、
    pytest
    等）
  • 若测试因修复失败：
    • 优先调整修复方案而非修改测试
    • 仅当修复确实改变了预期行为时才修改测试
    • 仅做机械性修复（重命名导入等）
    • 最多尝试2次解决测试失败问题

Step 5.3: Run Linting

步骤5.3：运行代码检查

  • Run project linter if configured
  • Fix any formatting issues introduced
  • 若项目配置了linter则运行
  • 修复本次改动引入的格式问题

Phase 6: Summary & PR Prompt

阶段6：总结与PR提示

Step 6.1: Display Remediation Summary

步骤6.1：展示修复总结

For Code vulnerabilities (single or multiple instances):
undefined
代码漏洞（单个或多个实例）:
undefined

Remediation Summary

修复总结

Remediated Vulnerability[Title] ([CWE-XXX])
Snyk ID[javascript/PT, python/XSS, etc.]
Severity[Critical/High/Medium/Low]
Instances Fixed[count]
#FileLineStatus
1[file][line]✅ Fixed
2[file][line]✅ Fixed
已修复漏洞[标题] ([CWE-XXX])
Snyk ID[javascript/PT、python/XSS等]
Severity[Critical/High/Medium/Low]
已修复实例数[数量]
#文件行号状态
1[文件][行号]✅ 已修复
2[文件][行号]✅ 已修复

What Was Fixed

修复内容

[2-3 sentence plain-English explanation of the vulnerability and how it was fixed. No code snippets.]
[用2-3句通俗易懂的话说明漏洞和修复方式，不要包含代码片段。]

Validation

验证结果

CheckResult
Snyk Re-scan✅ Resolved ([count] instances) / ❌ Still present
TypeScript/Build✅ Pass / ❌ Fail
Linting✅ Pass / ❌ Fail
Tests✅ Pass / ⚠️ Skipped (reason) / ❌ Fail
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
检查项结果
Snyk二次扫描✅ 已解决（[数量]个实例） / ❌ 仍存在
TypeScript/构建✅ 成功 / ❌ 失败
代码检查✅ 成功 / ❌ 失败
测试✅ 成功 / ⚠️ 跳过（原因） / ❌ 失败
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Should I create a PR for this fix? (yes / no)

是否为本次修复创建PR？(是 / 否)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**For SCA vulnerabilities:**
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**SCA漏洞:**

Remediation Summary

修复总结

Remediated Vulnerability[Title]
Snyk ID[SNYK-JS-XXX / CVE-XXX]
Severity[Critical/High/Medium/Low]
Package[package@old] → [package@new]
已修复漏洞[标题]
Snyk ID[SNYK-JS-XXX / CVE-XXX]
Severity[Critical/High/Medium/Low]
包[package@旧版本] → [package@新版本]

Additional Issues Fixed by This Upgrade

本次升级额外修复的问题

IDSeverityTitle
[Snyk ID][severity][title]
Total issues fixed: [count]
IDSeverity标题
[Snyk ID][severity][标题]
总修复问题数: [数量]

What Was Fixed

修复内容

[2-3 sentence plain-English explanation of the vulnerability and how it was fixed.]
[用2-3句通俗易懂的话说明漏洞和修复方式。]

Validation

验证结果

CheckResult
Snyk Re-scan✅ Resolved / ❌ Still present
TypeScript/Build✅ Pass / ❌ Fail
Linting✅ Pass / ❌ Fail
Tests✅ Pass / ⚠️ Skipped (reason) / ❌ Fail
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
检查项结果
Snyk二次扫描✅ 已解决 / ❌ 仍存在
TypeScript/构建✅ 成功 / ❌ 失败
代码检查✅ 成功 / ❌ 失败
测试✅ 成功 / ⚠️ 跳过（原因） / ❌ 失败
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Should I create a PR for this fix? (yes / no)

是否为本次修复创建PR？(是 / 否)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Rules for this summary:**
- Do NOT include code snippets (before/after)
- Do NOT list remaining issues in codebase
- Keep "What Was Fixed" to 2-3 sentences max
- Use visual separator (━) around PR prompt to make it stand out
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**总结规则:**
- 不要包含（修改前后的）代码片段
- 不要列出代码库中剩余的问题
- "修复内容"最多2-3句话
- 用分隔符（━）包裹PR提示使其更醒目

Step 6.2: Send Feedback to Snyk

步骤6.2：向Snyk发送反馈

After successful fix, report the remediation using 
mcp_snyk_snyk_send_feedback
:
  • fixedExistingIssuesCount: [total issues fixed]
  • preventedIssuesCount: 0
  • path: [absolute project path]
修复成功后，使用
mcp_snyk_snyk_send_feedback
上报修复结果：
  • fixedExistingIssuesCount: [总修复问题数]
  • preventedIssuesCount: 0
  • path: [项目绝对路径]

Step 6.3: Wait for User Response

步骤6.3：等待用户回复

IMPORTANT: Do NOT proceed until the user explicitly confirms.
重要提示: 用户明确确认前不要继续操作。

Phase 6B: Batch Summary (Batch Mode Only)

阶段6B：批量总结（仅批量模式适用）

Only execute this phase after completing all batch fixes.
仅在所有批量修复完成后执行该阶段。

Step 6B.1: Generate Comprehensive Summary

步骤6B.1：生成完整总结

undefined
undefined

Batch Remediation Summary

批量修复总结

Overall Results

整体结果

MetricCount
Vulnerabilities Attempted[total]
Successfully Fixed[count]
Partially Fixed[count]
Failed[count]
Skipped[count]
指标数量
尝试修复漏洞数[总数]
成功修复[数量]
部分修复[数量]
失败[数量]
跳过[数量]

Issues Fixed by Severity

按Severity统计修复情况

SeverityFixedRemaining
CriticalX/YZ
HighX/YZ
MediumX/YZ
LowX/YZ
Severity已修复剩余
CriticalX/YZ
HighX/YZ
MediumX/YZ
LowX/YZ

Detailed Results

详细结果

Code Vulnerabilities Fixed

已修复代码漏洞

#VulnerabilityFileInstancesStatus
1SQL Injectiondb.ts3/3✅ Fixed
2XSSapi/render.ts2/2✅ Fixed
3Path Traversalfiles.ts3/4⚠️ Partial
#漏洞文件实例数状态
1SQL Injectiondb.ts3/3✅ 已修复
2XSSapi/render.ts2/2✅ 已修复
3路径遍历files.ts3/4⚠️ 部分修复

Dependency Vulnerabilities Fixed

已修复依赖漏洞

#PackageOld → NewCVEs FixedStatus
1log4j-core2.14.1 → 2.17.13✅ Fixed
2lodash4.17.15 → 4.17.212✅ Fixed
#包旧版本 → 新版本修复CVE数状态
1log4j-core2.14.1 → 2.17.13✅ 已修复
2lodash4.17.15 → 4.17.212✅ 已修复

Files Modified

修改的文件

  • src/db.ts
  • src/api/render.ts
  • src/files.ts
  • package.json
  • package-lock.json
  • src/db.ts
  • src/api/render.ts
  • src/files.ts
  • package.json
  • package-lock.json

Validation Results

验证结果

CheckResult
Snyk Code Re-scan✅ [X] issues resolved
Snyk SCA Re-scan✅ [Y] issues resolved
Build✅ Pass
Tests✅ Pass
Lint✅ Pass
检查项结果
Snyk代码二次扫描✅ [X]个问题已解决
Snyk SCA二次扫描✅ [Y]个问题已解决
构建✅ 成功
测试✅ 成功
代码检查✅ 成功

Issues NOT Fixed

未修复的问题

VulnerabilityReason
SSRF in external.tsComplex refactoring required
minimist@1.2.5No fix version available
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
漏洞原因
external.ts中的SSRF需要复杂重构
minimist@1.2.5无可用修复版本
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Should I create a single PR for all these fixes? (yes / no)

是否为所有修复创建单个PR？(是 / 否)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
undefined
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
undefined

Step 6B.2: Send Batch Feedback

步骤6B.2：发送批量修复反馈

Report all fixes to Snyk:
Run mcp_snyk_snyk_send_feedback with:
- path: [project root]
- fixedExistingIssuesCount: [total issues fixed across all vulns]
- preventedIssuesCount: 0
向Snyk上报所有修复结果：
运行mcp_snyk_snyk_send_feedback，参数：
- path: [项目根目录]
- fixedExistingIssuesCount: [所有漏洞的总修复问题数]
- preventedIssuesCount: 0

Step 6B.3: Batch PR Handling

步骤6B.3：批量PR处理

If user confirms PR for batch fixes:
Branch naming for batch:
  • fix/security-batch-YYYYMMDD
  • fix/security-critical-high-batch
Commit strategy:
  • Option 1: Single commit with all changes
  • Option 2: One commit per vulnerability type (cleaner history)
Default to Option 1 unless user prefers separate commits.
PR Body for Batch:
markdown
undefined
若用户确认创建批量修复PR：
批量分支命名规则:
  • fix/security-batch-YYYYMMDD
  • fix/security-critical-high-batch
提交策略:
  • 选项1: 单次提交包含所有改动
  • 选项2: 每类漏洞单独提交（提交历史更清晰）
默认使用选项1，除非用户偏好单独提交。
批量PR正文:
markdown
undefined

Security Fixes (Batch)

安全修复（批量）

This PR addresses multiple security vulnerabilities identified by Snyk.
本PR解决了Snyk识别的多个安全漏洞。

Summary

总结

  • Code vulnerabilities fixed: [count]
  • Dependency vulnerabilities fixed: [count]
  • Total CVEs resolved: [count]
  • 已修复代码漏洞: [数量]
  • 已修复依赖漏洞: [数量]
  • 总解决CVE数: [数量]

Code Fixes

代码修复

VulnerabilityFileCWESeverity
SQL Injectiondb.tsCWE-89Critical
XSSrender.tsCWE-79High
Path Traversalfiles.tsCWE-22High
漏洞文件CWESeverity
SQL Injectiondb.tsCWE-89Critical
XSSrender.tsCWE-79High
路径遍历files.tsCWE-22High

Dependency Upgrades

依赖升级

PackageOldNewCVEs Fixed
log4j-core2.14.12.17.13
lodash4.17.154.17.212
包旧版本新版本修复CVE数
log4j-core2.14.12.17.13
lodash4.17.154.17.212

Validation

验证

  • Snyk scans pass
  • Tests pass
  • No new vulnerabilities introduced
  • Snyk扫描通过
  • 测试通过
  • 未引入新漏洞

Review Notes

审核说明

Each fix was validated independently before inclusion in this batch.

---
每个修复在纳入批量前都经过了独立验证。

---

Phase 7: Create PR (If Confirmed)

阶段7：创建PR（经确认后）

Only execute if user says "yes" to PR prompt.
仅当用户对PR提示回复"是"时执行。

Step 7.1: Check Git Status

步骤7.1：检查Git状态

bash
git status
Verify:
  • There are uncommitted changes (staged or unstaged)
  • The changes are related to the security fix
If no changes found: Report "No uncommitted changes to commit" and STOP
bash
git status
验证:
  • 存在未提交的改动（暂存或未暂存）
  • 改动与安全修复相关
未找到改动: 上报"无未提交改动可提交"并停止

Step 7.2: Create Branch

步骤7.2：创建分支

Format: 
fix/security-<identifier>
Examples:
  • fix/security-SNYK-JS-LODASH-1018905
  • fix/security-cwe-79-xss
  • fix/security-path-traversal-server
  • fix/security-lodash-upgrade
bash
git checkout -b fix/security-<identifier>
格式: 
fix/security-<标识符>
示例:
  • fix/security-SNYK-JS-LODASH-1018905
  • fix/security-cwe-79-xss
  • fix/security-path-traversal-server
  • fix/security-lodash-upgrade
bash
git checkout -b fix/security-<标识符>

Step 7.3: Stage and Commit

步骤7.3：暂存并提交

Stage only files related to the security fix:
bash
git add <files>
Do NOT stage:
  • Unrelated changes
  • IDE/editor files
  • Build artifacts
Create commit:
bash
git commit -m "fix(security): <description>

Resolves: [Snyk ID or CVE]
Severity: [Critical/High/Medium/Low]"
仅暂存与安全修复相关的文件：
bash
git add <文件>
不要暂存:
  • 无关改动
  • IDE/编辑器文件
  • 构建产物
创建提交：
bash
git commit -m "fix(security): <描述>

解决: [Snyk ID 或 CVE]
Severity: [Critical/High/Medium/Low]"

Step 7.4: Push Branch

步骤7.4：推送分支

bash
git push -u origin fix/security-<identifier>
bash
git push -u origin fix/security-<标识符>

Step 7.5: Create Pull Request

步骤7.5：创建Pull Request

bash
gh pr create \
  --title "Security: <title>" \
  --body "<body>" \
  --base main
PR Body Template:
markdown
undefined
bash
gh pr create \
  --title "Security: <标题>" \
  --body "<正文>" \
  --base main
PR正文模板:
markdown
undefined

Security Fix

安全修复

Vulnerability Details

漏洞详情

  • ID: [Snyk ID or CVE]
  • Severity: [Critical | High | Medium | Low]
  • Type: [SCA | Code]
  • ID: [Snyk ID 或 CVE]
  • Severity: [Critical | High | Medium | Low]
  • 类型: [SCA | 代码]

Changes Made

改动内容

[Description of the fix]
[修复说明]

Files Changed

修改的文件

  • [list files]
  • [文件列表]

Validation

验证

  • Snyk scan passes
  • Tests pass
  • No new vulnerabilities introduced

**IMPORTANT**: 
- Do NOT use `--label` flags (labels may not exist in repo)
  • Snyk扫描通过
  • 测试通过
  • 未引入新漏洞

**重要提示**: 
- 不要使用`--label`参数（仓库可能不存在对应标签）

Step 7.6: Output Confirmation

步骤7.6：输出确认信息

undefined
undefined

PR Created Successfully

PR创建成功

  • PR URL: [URL]
  • Branch: fix/security-<identifier>
  • Title: [PR title]
  • Status: Ready for review
  • PR URL: [URL]
  • 分支: fix/security-<标识符>
  • 标题: [PR标题]
  • 状态: 待审核

Next Steps

后续步骤

  1. Review the PR at the URL above
  2. Request reviews from team members
  3. Merge when approved

---
  1. 访问上述URL查看PR
  2. 向团队成员发起审核请求
  3. 审核通过后合并

---

Error Handling

错误处理

Authentication Errors

认证错误

  • Run 
    mcp_snyk_snyk_auth
    and retry once
  • If still failing: STOP and ask user to authenticate manually
  • 运行
    mcp_snyk_snyk_auth
    并重试一次
  • 仍失败：停止并要求用户手动认证

Scan Timeout/Failure

扫描超时/失败

  • Retry once
  • If still failing: STOP and report the error
  • 重试一次
  • 仍失败：停止并上报错误

Vulnerability Not Found

未找到漏洞

  • If user specified a vulnerability that doesn't appear in scan results
  • Report clearly and STOP (don't guess or fix something else)
  • 若用户指定的漏洞未出现在扫描结果中
  • 明确上报并停止（不要猜测或修复其他内容）

Unfixable Code Vulnerability

代码漏洞无法修复

If the vulnerability cannot be fixed automatically:
  1. Document why it cannot be fixed (complex refactoring needed, unclear fix, etc.)
  2. Add TODO comment in the affected file with context
  3. Report to user with manual remediation suggestions
  4. Do NOT leave partial/broken fixes
若漏洞无法自动修复：
  1. 记录无法修复的原因（需要复杂重构、修复方案不明确等）
  2. 在受影响文件中添加TODO注释附带上下文
  3. 向用户上报并提供手动修复建议
  4. 不要留下部分/损坏的修复

SCA - No Fix Available

SCA - 无可用修复

If no upgrade path exists:
  1. Document this clearly
  2. Suggest alternatives (replace package, patch, accept risk)
  3. Do NOT make changes
若无升级路径：
  1. 明确记录该情况
  2. 建议替代方案（替换包、打补丁、接受风险）
  3. 不要做任何改动

Partial Success (Code)

部分成功（代码）

If some instances are fixed but others fail:
  1. Keep the successful fixes
  2. Document which instances remain unfixed and why
  3. Add TODO comments for unfixed instances
  4. Report partial success in summary with clear breakdown
若部分实例修复成功但其他失败：
  1. 保留成功的修复
  2. 记录哪些实例未修复及原因
  3. 为未修复的实例添加TODO注释
  4. 在总结中上报部分成功并明确拆分情况

Rollback Triggers

回滚触发条件

Revert ALL changes if:
  • Unable to produce clean fix after 3 attempts (new vulnerabilities introduced)
  • Tests fail and cannot be reasonably fixed
  • Fix would require changing business logic
  • Dependency resolution completely fails
出现以下情况时回滚所有改动：
  • 3次尝试后仍无法生成干净的修复（引入新漏洞）
  • 测试失败且无法合理修复
  • 修复需要修改业务逻辑
  • 依赖解析完全失败

Git/PR Errors

Git/PR错误

ErrorResolution
Not a git repositorySTOP - cannot create PR
Branch already existsGenerate unique branch name with timestamp
SSH key errorRetry command
Not authenticated (gh)Suggest 
gh auth login
错误解决方案
非Git仓库停止 - 无法创建PR
分支已存在生成带时间戳的唯一分支名
SSH密钥错误重试命令
gh未认证建议运行
gh auth login

Constraints

约束条件

Single Mode

单问题模式

  1. One vulnerability TYPE per run - Fix all instances of ONE vulnerability type (Code) or ONE dependency issue (SCA)
  2. Minimal changes - Only modify what's necessary
  3. No new vulnerabilities - Fixes must be clean (or net improvement for SCA)
  4. Preserve functionality - Tests must pass
  5. No scope creep - Don't refactor or "improve" other code
  6. Consistent fixes - Apply the same fix pattern across all instances (Code)
  7. User confirmation for PR - Never auto-create PRs
  8. Always prompt for PR - Every successful fix MUST end with the PR prompt question
  1. 每次运行仅修复一类漏洞 - 修复一类漏洞的所有实例（代码）或一个依赖问题（SCA）
  2. 最小改动 - 仅修改必要内容
  3. 无新漏洞 - 修复必须干净（SCA允许安全净提升）
  4. 保留功能 - 测试必须通过
  5. 无范围蔓延 - 不要重构或"优化"其他代码
  6. 修复一致 - 所有实例应用相同的修复模式（代码）
  7. PR需用户确认 - 禁止自动创建PR
  8. 始终提示PR - 每次成功修复后必须弹出PR提示问题

Batch Mode Additional Constraints

批量模式额外约束

  1. User approval required - Must confirm batch plan before starting
  2. Max 20 vulnerabilities - Keep batch fixes manageable
  3. Max 15 files - Keep PRs reviewable
  4. Validate each fix - Each vulnerability fix is validated before proceeding to next
  5. Partial success allowed - Can complete batch even if some fixes fail
  6. Single PR for batch - All batch fixes go into one PR (unless user requests otherwise)
  7. Detailed tracking - Track success/failure for each item in batch
  1. 需用户审批 - 开始前必须确认批量计划
  2. 最多20个漏洞 - 保持批量修复可管理
  3. 最多15个文件 - 保持PR可审核
  4. 每个修复都验证 - 处理下一个漏洞前验证当前修复
  5. 允许部分成功 - 即使部分修复失败也可完成批量
  6. 批量修复合并为单个PR - 所有批量修复进入同一个PR（用户要求分开除外）
  7. 详细跟踪 - 跟踪批量中每个项的成功/失败状态

Completion Checklist

完成检查清单

Single Mode Checklist

单问题模式检查清单

Before ending the conversation, verify ALL are complete:
  • Vulnerability type identified and documented (including all instances for code vulns)
  • Fix applied successfully
  • Re-scan shows ALL instances resolved (or net improvement for SCA)
  • Tests pass (or failures documented)
  • Summary displayed to user (with instance count if multiple)
  • Snyk feedback sent with correct count
  • PR prompt asked ← Do NOT skip this step
  • PR created (if user confirmed)
结束对话前，确认所有项已完成：
  • 漏洞类型已识别并记录（代码漏洞包含所有出现位置）
  • 修复成功应用
  • 二次扫描显示所有实例已解决（SCA允许安全净提升）
  • 测试通过（或已记录失败原因）
  • 已向用户展示总结（多实例包含实例数）
  • 已向Snyk发送正确计数的反馈
  • 已弹出PR提示 ← 不要跳过该步骤
  • PR已创建（若用户确认）

Batch Mode Checklist

批量模式检查清单

Before ending the conversation, verify ALL are complete:
  • Full project scan completed (SAST + SCA)
  • Batch plan generated and shown to user
  • User approved the batch plan
  • Each vulnerability in plan was attempted
  • Each fix was validated before proceeding to next
  • Results tracked for all items (success/partial/failed)
  • Comprehensive batch summary displayed
  • Total fix count sent to Snyk feedback
  • PR prompt asked with all batch changes
  • Single PR created with all fixes (if user confirmed)
结束对话前，确认所有项已完成：
  • 全项目扫描已完成（SAST + SCA）
  • 批量计划已生成并展示给用户
  • 用户已批准批量计划
  • 计划中的每个漏洞都已尝试修复
  • 处理下一个漏洞前已验证当前修复
  • 所有项的结果都已跟踪（成功/部分/失败）
  • 已展示完整的批量总结
  • 总修复计数已发送至Snyk反馈
  • 已弹出包含所有批量改动的PR提示
  • 单个PR已创建包含所有修复（若用户确认）