snyk-fix

Snyk 修复（全流程）

完整的安全修复工作流：解析 → 扫描 → 分析 → 修复 → 验证 → 汇总 →（可选）PR

模式：

• 单项模式（默认）：每次修复一种漏洞类型（同一文件中的所有实例）
• 批量模式：按优先级修复多个漏洞（由“all”、“batch”、严重性筛选条件或数量触发）

---

阶段 1：解析输入

解析用户输入，提取：

• mode：单项（默认）或批量
• scan_type：code、sca 或 both（根据上下文推断）
• target_vulnerability：特定问题 ID、CVE、包名称、文件或漏洞类型
• target_path：文件或目录（默认为项目根目录）
• severity_filter / max_fixes：用于批量模式（默认上限：20）

模式和扫描类型检测

信号	模式	扫描类型
“all”、严重性筛选条件、数量（“top 5”）或“batch”	批量	both
特定漏洞 ID、单一类型、文件引用，或没有批量指示	单项（默认）	—
明确指定“code”/“sast”/“static”	—	code
明确指定“sca”/“dependency”/“package”/包管理器名称	—	sca
提供 SNYK- 或 CVE- ID	—	both
漏洞类型（XSS、SQL 注入、路径遍历等）或文件引用	—	code
包名称引用	—	sca
没有提示	—	both（优先级最高的问题）

---

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

1. 在项目根目录运行 mcp_snyk_snyk_code_scan 和 mcp_snyk_snyk_sca_scan。
2. 按用户指定的严重性、类型、路径或数量筛选。
3. 按漏洞类型分组（代码：相同 ID + 文件；SCA：相同包）。按严重性从 Critical → High → Medium → Low 排序；同一优先级内，优先处理有可用修复方案的问题。
4. 以编号表格的形式显示修复计划（索引、类型、严重性、目标、实例数），并估算文件/包变更情况。继续操作前等待用户确认。
   • 如果用户说“adjust”：允许修改计划。
5. 按顺序执行修复（每项执行阶段 3 或 4 → 阶段 5 验证 → 记录结果）。失败时：如果 stop_on_failure=true 则停止，否则继续。
6. 所有尝试完成后，继续执行阶段 6B。

批量限制：最多 20 个漏洞，最多修改 15 个文件，每项最多尝试修复 3 次。

---

阶段 2：发现

步骤 2.1：运行扫描

使用目标路径运行扫描。示例：

# Code scan
mcp_snyk_snyk_code_scan:
  path: "/absolute/path/to/project"   # or subdirectory for targeted scans

# SCA scan
mcp_snyk_snyk_sca_scan:
  path: "/absolute/path/to/project"   # always project root (manifest location)

• 代码：在目标路径上运行 mcp_snyk_snyk_code_scan
• SCA：在项目根目录运行 mcp_snyk_snyk_sca_scan
• 两者：并行运行

步骤 2.2：选择目标

• 如果用户已指定：查找匹配的问题。若未找到：报告并停止。
• 如果未指定：按以下优先级选择最高优先级类型：Critical+可利用漏洞 > Critical > High+可利用漏洞 > High > Medium > Low。优先选择有可用修复方案的问题。

步骤 2.3：分组实例（仅代码）

选择漏洞类型后，收集同一文件中该 Snyk ID 的所有实例，并一并修复。

步骤 2.4：记录目标

显示简要摘要：类型（Code/SCA）、ID、严重性、标题；对于 Code，显示实例数以及文件/行号表；对于 SCA，显示包、修复版本和依赖路径。

步骤 2.5：检查修复路径（仅 SCA）

⚠️ 如果扫描结果未报告所选 SCA 漏洞的任何修复版本或升级路径，切勿继续执行阶段 4。 如果 Snyk 没有推荐的修复方案，Agent 不得自行尝试查找或编造修复方案。

应改为生成无可用修复方案报告并停止：

## No Fix Available

| Vulnerability | [Title] |
|---------------|---------|
| **ID** | [Snyk Issue ID] |
| **Severity** | [Critical / High / Medium / Low] |
| **Package** | [package@current_version] |
| **Dependency Path** | [direct / transitive via X → Y → Z] |

### Why No Fix Was Applied
Snyk does not report a fix version or upgrade path for this vulnerability.
The agent will not attempt to resolve issues where no known fix exists.

### Alternatives to Consider
- Monitor for a future fix release from the package maintainer
- Evaluate replacing the package with a maintained alternative
- Apply a manual workaround if the vulnerability context allows it
- Accept the risk and document in your security policy

生成此报告后：

• 发送 mcp_snyk_snyk_send_feedback，并设置 fixedExistingIssuesCount: 0
• 不得更改任何文件
• 停止

---

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

步骤 3.1：了解情况

阅读所有存在漏洞的位置。识别漏洞类型（SQL 注入、XSS、路径遍历、命令注入、敏感数据泄露、硬编码机密、加密问题等）。查看 Snyk 的修复指南。

第 3.2 步：规划

记录：漏洞类型、根本原因、修复方案、安全机制、实例数量。

常见模式：

• SQL 注入 → 使用参数化查询
• 命令注入 → 验证输入并转义，或避免使用 shell
• 路径遍历 → 规范化路径，并验证路径是否位于允许的基础路径下
• XSS → 针对具体上下文对输出进行编码或净化
• 硬编码密钥 → 移至环境变量或密钥管理器

第 3.3 步：修复所有实例

• 从文件底部向上修复（避免行号偏移）
• 尽量少改动；使用标准库或框架的安全功能
• 如果 3 个或更多实例采用相同的修复模式，则创建共享辅助函数
• 在不明显之处添加与安全相关的注释
• 不要重构无关代码，也不要更改业务逻辑

---

第 4 阶段：修复（SCA 漏洞）

如果这是代码漏洞（已在第 3 阶段处理），请跳至第 5 阶段。

第 4.1 步：确定修复策略

分析依赖路径，并确定适用的策略。继续之前，必须从以下三种策略中恰好选择一种：

策略 A — 直接升级 存在漏洞的包是项目清单文件中的直接依赖。将其升级到已修复该漏洞的版本。

策略 B — 升级父依赖 存在漏洞的包是传递依赖。某个较新版本的直接依赖（父依赖）会引入已修复该漏洞的传递依赖版本。升级父依赖。

策略 C — 修复传递依赖 存在漏洞的包是传递依赖，但父依赖没有可用版本能引入已修复该漏洞的传递依赖版本。使用该生态系统中影响最小的可用机制，将该传递依赖解析到已修复的版本。

如何选择：

1. 项目清单文件中是否直接声明了存在漏洞的包？

   • 是 → 策略 A
   • 否 → 继续执行第 2 步

2. 找出引入该存在漏洞的传递依赖的直接依赖（父依赖）。是否有任何可用的父依赖版本能将该传递依赖解析到已修复的版本？

   • 是 → 策略 B（升级父依赖）
   • 否 → 策略 C（修复传递依赖）

如果应用直接导入或使用了该传递依赖（而不只是通过父依赖使用），请注明这一点——这会影响策略 C 的重大变更分析。

记录所选策略：

## Remediation Strategy
- **Strategy**: [Direct Upgrade | Parent Upgrade | Transitive Fix]
- **Target package to change**: [package@current → package@target]
- **Parent dependency** (if Parent Upgrade or Transitive Fix): [parent@current]
- **Manifest file**: [path to manifest]

在第 6.2 步（或批处理模式下的第 6B.2 步）snyk_send_feedback 调用的 strategy 字段中，使用此确切字符串。

第 4.2 步：评估重大变更

⚠️ 在应用任何更改之前，务必先运行 mcp_snyk_snyk_breakability_check。 如果工具不可用、运行出错，或未返回 LOW/MEDIUM/HIGH 风险等级，请继续执行第 4.2a 步。

使用实际会在清单文件中变更的包调用 mcp_snyk_snyk_breakability_check：

策略	检查重大变更风险的对象
A（直接升级）	正在升级的直接依赖
B（升级父依赖）	正在升级的父依赖
C（修复传递依赖）	正在解析到新版本的传递依赖

可破坏性决策树

可破坏性结果（LOW / MEDIUM / HIGH）是对可能性的总体评估，并不代表已确认此特定项目确实会发生破坏。请根据结果决定下一步行动。

交互式执行与自主执行：有人参与时（交互式会话），请说明权衡因素，并在风险为 HIGH 时征求确认。自主运行时（后台 Agent，没有人可供联系），Agent 必须评估与人工相同的证据——漏洞严重程度、破坏性变更风险、破坏性变更详情——自行做出决定，并在输出中记录其推理过程。自主 Agent 绝不能因等待不会到来的输入而阻塞。

策略 A（直接升级）和策略 B（升级上游依赖）：

风险	操作
LOW	自动应用升级。继续执行步骤 4.4。
MEDIUM	自动应用升级。在修复摘要中记录破坏性变更摘要和推理过程。
HIGH	交互式：说明完整的权衡因素（漏洞详情、破坏性变更摘要、确切的拟议变更），并询问用户是否继续。自主：评估完整的权衡因素，决定是应用变更还是生成完整建议（阶段 4a），并记录推理过程。

**策略 B → 回退到 C：**如果策略 B 得出 HIGH 可破坏性结果，且用户或 Agent 决定不继续，则回退到策略 C。对传递依赖版本跳跃重新运行 mcp_snyk_snyk_breakability_check，并遵循下方的策略 C 决策树。发生此回退时，在到达步骤 6.2 之前，使用 Transitive Fix 重新记录步骤 4.1 中的“记录所选策略”模板。

策略 C（传递依赖修复）：

风险	操作
LOW	自动应用修复。继续执行步骤 4.4。
MEDIUM	自动应用升级。在修复摘要中记录破坏性变更摘要和推理过程。
HIGH	交互式：说明完整的权衡因素，并询问用户是否继续。如果漏洞为严重级别且存在已知利用方式，请强调紧迫性。自主：评估完整的权衡因素，决定是应用变更还是生成完整建议（阶段 4a），并记录推理过程。

步骤 4.2a：可破坏性回退方案——Semver + 用法分析

当 mcp_snyk_snyk_breakability_check 不可用（找不到工具、报错或超时），或返回的响应中没有 LOW/MEDIUM/HIGH 风险等级（例如“没有其他可用的可破坏性上下文”）时，启用此步骤。如果可破坏性检查返回了有效的风险等级，则完全跳过此步骤。

当可破坏性数据不可用时，结合语义化版本（Semver）差距和代码库用法推导替代风险等级：

1. 确定当前版本与目标版本之间的 Semver 差距：

   • 补丁版本升级（例如 1.2.3 → 1.2.5）：固有风险最低
   • 次要版本升级（例如 1.2.3 → 1.3.0）：固有风险中等
   • 主要版本升级（例如 1.2.3 → 2.0.0）：固有风险最高

2. 在代码库中搜索正在升级的程序包的直接用法。 根据项目的语言和生态系统，使用适当的模式查找导入、require、include 或其他依赖项引用。Agent 应根据生态系统确定正确的搜索模式，不要使用硬编码模式。

3. 结合两种信号，推导替代风险等级：

Semver 差距	无直接用法	少量用法	大量／复杂用法
补丁	LOW	LOW	LOW
次要	LOW	MEDIUM	MEDIUM
主要	HIGH	HIGH	HIGH

4. 将替代风险等级输入步骤 4.2 中相同的可破坏性决策树。 不要使用单独的代码路径——适用相同的阈值和操作。

重要提示：使用替代风险等级时，请在修复摘要（阶段 6）中注明这一点，让用户知道该风险评估是根据代码库分析得出的，而非来自可破坏性数据。

步骤 4.3：版本选择

当有多个版本可以修复漏洞时，不要盲目选择版本号最低的版本。选择时应优先考虑：

1. 能修复目标漏洞
2. 可破坏性风险最低（如有需要，对候选版本运行 mcp_snyk_snyk_breakability_check）
3. 版本号最低（仅用于打破平局）

步骤 4.4：应用修复

仅当可破坏性决策允许（自动应用或经用户／Agent 确认）时，才执行此步骤。

策略 A（直接升级）： 更新清单文件中的版本，并运行对应生态系统的安装命令（npm install pkg@version、yarn upgrade、go get、pip install、mvn dependency:resolve 等）。保留文件格式和注释。

策略 B（升级父依赖）： 更新清单文件中的父依赖版本，并运行对应生态系统的安装命令。安装后，验证解析出的传递依赖是否已是修复漏洞的版本。

策略 C（传递依赖修复）： 使用影响最小的机制，让解析器选择传递依赖的修复版本。具体机制取决于生态系统——不要假设存在通用的固定顺序。

1. 先仅更新解析结果：刷新锁文件，或运行生态系统针对易受攻击程序包的更新／解析命令。当现有约束已允许使用修复版本时，适合采用此方法。
2. 如果失败，检查生态系统和仓库布局，然后选择适当的原生解析器控制机制：顶层约束／声明、集中式依赖管理条目、强制／覆盖／解析规则、排除或替换。
3. 优先选择范围最窄且有效的方案。 仅当常规声明或范围更窄的排除无法让解析器选择修复版本时，才使用更强的覆盖／强制／替换机制。
4. 最后才使用硬性固定版本。

参考：常见安装／解析命令

包管理器	命令
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

此表并未涵盖所有情况 — 请根据项目的生态系统使用适当的命令。

如果安装失败：

• 如果是沙箱／权限问题：使用提升后的权限重试
• 如果是依赖冲突：尝试其他版本，或注明无法修复
• 如果解析彻底失败，则还原清单文件的更改
• 记录失败原因

---

阶段 4a：完整建议 — SCA 不应用路径

当决定不应用 SCA 修复时，进入此阶段 — 无论是因为用户拒绝，还是因为 Agent（在自主模式下）判定风险大于收益。

提供建议，而不是进行更改。

建议输出格式

## Security Advisory — Manual Action Required

### Vulnerability
- **ID**: [Snyk Issue ID]
- **Severity**: [Critical | High | Medium | Low]
- **Package**: [vulnerable_package@current_version]
- **Title**: [vulnerability title]

### Why This Was Not Auto-Applied
[1-2 sentences: e.g., "The required transitive fix from [email protected] to [email protected] has a HIGH
breaking change risk. The changelog indicates removed APIs and changed default behavior
that may affect consumers."]

### Breaking Change Details
[Summary from mcp_snyk_snyk_breakability_check — what changed between versions, which APIs were
removed/renamed/modified, migration notes if available]

### Exact Changes Required
To apply this fix manually, make the following changes:

**1. Manifest change** ([path/to/manifest]):
[Exact content to add or modify — the override/resolution entry or version bump]

**2. Regenerate lockfile**:
[Exact command to run]

**3. Validate**:
[Command to re-run SCA scan and tests]

### Alternatives
- Wait for [parent_package] to release a version that includes the fixed transitive
- Evaluate replacing [vulnerable_package] with an alternative
- Accept the risk and document in your security policy

生成建议后：

• 不要更改任何文件
• 不要继续进入阶段 5
• 发送 mcp_snyk_snyk_send_feedback，并设置 fixedExistingIssuesCount: 0
• 停止

---

阶段 5：验证

步骤 5.1：重新运行扫描

运行与阶段 2 相同的扫描（使用完全相同的 path 参数）。验证所有目标实例均已解决。

对于代码漏洞 — 如果仍存在任何实例：

• 针对该特定实例检查修复尝试
• 尝试其他方法
• 每个实例最多总共尝试 3 次，然后报告部分成功／失败
• 如果引入了新漏洞：修复它们（迭代，总计最多 3 次）。如果无法生成干净的修复，则还原所有更改并报告失败

对于 SCA 漏洞 — 如果漏洞仍然存在：

• 检查锁文件是否已正确更新
• 使用包管理器的精确版本语法尝试显式安装版本
• 最多尝试 3 次，然后停止并报告失败

如果 SCA 升级引入了新漏洞：

• 新漏洞严重性低于已修复漏洞：接受（总体安全性有所提升）
• 新漏洞严重性等于或高于已修复漏洞：尝试其他版本。尝试前，对每个候选版本运行 mcp_snyk_snyk_breakability_check — 不要在未评估风险的情况下盲目尝试更高版本。最多迭代 3 次。
• 如果不存在无漏洞版本：还原并报告无法修复

步骤 5.1a：修复的其他问题（仅限 SCA）

比较扫描前后的结果。记录此次升级额外解决的所有漏洞（ID、严重性、标题）。

步骤 5.2：运行测试

运行项目测试（npm test、pytest 等）。

对于代码漏洞：

• 如果失败：优先调整修复方案，而不是更改测试；仅在行为发生合理变化时修改测试。最多尝试 2 次。

对于 SCA 漏洞：

• 如果失败：优先调整代码以适配新 API，而不是降级。仅进行机械性修复（导入名称变更、签名变更）。最多尝试 2 次。

步骤 5.3：运行代码检查

如果项目配置了代码检查工具，则运行该工具；修复由此引入的格式问题。

---

阶段 6：摘要与 PR 提示

步骤 6.1：显示摘要

显示简明的修复摘要，包括：

• 漏洞 ID、严重性、标题、CWE（代码漏洞）或包升级（SCA）
• 实例／修复数量及每个实例的状态（✅ 已修复 / ⚠️ 部分修复 / ❌ 失败）
• “修复内容”：用 2–3 句通俗易懂的英语描述，不包含代码片段
• 验证表：Snyk 重新扫描、构建、代码检查、测试（✅/⚠️/❌）
• 对于 SCA：策略（直接／父级／传递）、破坏性变更风险（LOW/MEDIUM/HIGH）、风险来源（可破坏性检查／代码库用法分析）、破坏性变更摘要，以及升级额外修复的问题列表

最后以视觉上分隔开的 PR 提示结束：

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

步骤 6.2：发送反馈

使用步骤 6.1 摘要中已收集的数据：

mcp_snyk_snyk_send_feedback:
  fixedExistingIssuesCount: [total issues fixed]
  fixedIssueIds: [array of prefixed IDs fixed — "sast:<ID>" once per Code instance fixed,
    or "sca:<ID>" for the SCA vulnerability plus each additional issue fixed by the same
    upgrade (Step 5.1a)]
  fixedIssuesBySeverity: {critical: [count], high: [count], medium: [count], low: [count]}
  fixedIssuesByScanType: {sast: [count], sca: [count]} (Code fixes report sast only; SCA
    fixes report sca only)
  outcome: "applied"
  breakabilityRisk: [LOW | MEDIUM | HIGH | unknown] (SCA only, from Step 4.2/4.2a — omit for Code)
  breakabilityRiskSource: [api | heuristic] (SCA only — omit for Code)
  strategy: [Direct Upgrade | Parent Upgrade | Transitive Fix] (SCA only, from Step 4.1 — omit for Code)
  testsPassed: [true | false] (from Step 5.2)
  preventedIssuesCount: 0
  path: [absolute project path]

步骤 6.3：等待用户响应

重要：在用户明确确认之前，不要继续。

---

阶段 6B：批处理摘要（仅批处理模式）

第 6B.1 步：摘要

显示总体结果（已尝试／已修复／部分修复／失败／已跳过）、按严重程度划分的明细（已修复与剩余）、代码和 SCA 漏洞的逐项详细结果、修改的文件、验证结果，以及一张列出未修复问题及原因的表格。

以以下内容结尾：

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

第 6B.2 步：发送批量反馈

mcp_snyk_snyk_send_feedback:
  path: [project root]
  fixedExistingIssuesCount: [total across all vulns]
  fixedIssueIds: [prefixed ID of every fixed item — "sast:<ID>" for each fixed Code item,
    "sca:<ID>" for each fixed SCA item; array length matches fixedExistingIssuesCount]
  fixedIssuesBySeverity: {critical: [count], high: [count], medium: [count], low: [count]}
  fixedIssuesByScanType: {sast: [count], sca: [count]}
  outcome: "applied"
  testsPassed: [true | false] (overall batch test result)
  breakabilityRisk / breakabilityRiskSource / strategy: include only if exactly one SCA
    item was fixed in this batch (so a single value applies); omit if zero or multiple SCA
    items were fixed, since these are single-value fields and a mixed batch can span
    different risks/strategies per item
  preventedIssuesCount: 0

第 6B.3 步：批量 PR

分支：fix/security-batch-YYYYMMDD 或 fix/security-critical-high-batch。 默认：将所有更改合并为一个提交（如果用户愿意，可提供按漏洞分别提交的选项）。 PR 正文：代码修复汇总表（漏洞、文件、CWE、严重程度）、依赖项升级（软件包、旧版本→新版本、已修复的 CVE）、验证清单，并注明每项修复均已单独验证。

---

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

第 7.1 步：检查 Git 状态

git status

确认存在未提交的更改，且这些更改与安全修复有关。如果没有：报告并停止。

第 7.2 步：创建分支

格式：fix/security-<identifier>（例如：fix/security-SNYK-JS-LODASH-1018905、fix/security-cwe-79-xss、fix/security-path-traversal-server）。

git checkout -b fix/security-<identifier>

第 7.3 步：暂存并提交

仅暂存与安全修复有关的文件。不要暂存无关更改、IDE 文件或构建产物。

git add <files>
git commit -m "fix(security): <description>

Resolves: [Snyk ID or CVE]
Severity: [Critical/High/Medium/Low]"

第 7.4 步：推送并创建 PR

git push -u origin fix/security-<identifier>
gh pr create --title "Security: <title>" --body "<body>" --base main

不要使用 --label 标志。

PR 正文应包含：漏洞详情（ID、严重程度、类型）、所做的更改、变更文件，以及验证清单（Snyk 扫描通过、测试通过、未引入新漏洞）。

第 7.5 步：输出确认信息

显示 PR URL、分支、标题和后续步骤（审核、请求审核、获批后合并）。

---

错误处理

情况	操作
身份验证错误	运行 mcp_snyk_snyk_auth，重试一次；若仍然失败则停止
扫描超时／失败	重试一次；若仍然失败则停止并报告
未找到漏洞	明确报告并停止——不要猜测或修复其他问题
无法修复的代码漏洞	添加包含上下文的 TODO 注释；报告并提供手动修复建议；不要进行部分修复或留下损坏的修复
SCA — 无可用修复	按照第 2.5 步操作。生成《无可用修复报告》并停止
SCA — 修复被拒绝或跳过	正常退出——如果尚未显示，则生成完整公告（第 4a 阶段）；发送反馈时设置 fixedExistingIssuesCount: 0，然后停止
部分成功（代码）	保留成功的修复；为未修复的实例添加 TODO；报告部分成功及明细
不是 Git 仓库	停止——无法创建 PR
分支已存在	使用时间戳生成唯一分支名称
gh 未通过身份验证	建议运行 gh auth login

回滚触发条件（如果出现以下情况，则还原所有更改）：

• 尝试 3 次后仍无法生成干净的代码修复（或引入了新漏洞）
• 经过 2 次机械式修复尝试后，测试仍失败且无法合理解决
• 修复需要更改业务逻辑
• 依赖项解析完全失败

---

约束

单项模式：每次运行只修复一种漏洞类型（包括所有实例）。只做最小更改。不得引入新漏洞。测试必须通过。不得扩大范围或重构。始终询问是否创建 PR。

SCA 专属（单项和批量）：

• SCA 修复均须先通过可破坏性检查——应用任何 SCA 升级前，必须先运行 mcp_snyk_snyk_breakability_check，并遵循基于风险的决策树
• 高风险修复需确认——在交互会话中，高风险修复必须获得用户明确确认。中风险修复会自动应用，并记录理由。参见第 4.2 步。
• 版本选择需考虑可破坏性——多个版本均可修复漏洞时，优先选择可破坏性风险最低的版本，而不只是版本号最低的版本
• 无修复路径则不尝试修复——参见第 2.5 步

批量模式额外要求：开始前必须获得用户批准计划。最多处理 20 个漏洞、15 个文件。继续处理前须验证每项修复。允许部分成功。所有批量修复使用单个 PR（除非用户另有要求）。

---

完成清单

单项模式：已记录漏洞 → 已验证 SCA 的修复路径（或生成无可用修复报告）→ 已确定 SCA 的修复策略（A/B/C）→ 已评估 SCA 的破坏性变更 → 已应用修复（或生成完整公告）→ 重新扫描结果干净 → 测试通过 → 已显示摘要 → 已发送 Snyk 反馈 → 已询问是否创建 PR（如果已应用修复）→ 确认后创建 PR。

批量模式：已完成完整扫描 → 已显示并批准计划 → 已尝试处理所有项目 → 已验证每项修复 → 已跟踪结果 → 已显示批量摘要 → 已发送 Snyk 反馈 → 已询问是否创建 PR → 确认后创建单个 PR。