AI 提了补丁不等于漏洞已修复：把“已修复”拆成可验证的工程验收项

AI 能自动找漏洞、自动提补丁之后，团队最容易犯的一个流程错误，是把“PR 已生成”当成“问题已关闭”。这两件事在工程上不是一回事。“已修复”至少要拆成四层可验证的含义：补丁确实对应被验证的那个问题；漏洞路径在目标环境里不再可达；改动没有破坏既有行为；一旦出问题能退回。任何一层缺少证据，“已修复”就只是“已提交”。

先说清楚：这类服务交付的是什么#

据 AWS 于 2026 年 10 月 22 日发布的公告，AWS Continuum for code vulnerabilities 正式可用（GA）。按该公告描述，这个服务从代码仓库和 AWS 环境两侧构建上下文图，判断漏洞在具体环境中是否可利用、给出证据等级，对能够复现的问题在隔离沙箱中运行并附上概念验证代码与复现步骤，输出攻击路径、源码分析和爆炸半径评估，再为每个确认问题生成修复——形式可以是代码补丁、依赖升级或配置变更——并以 pull request 的形式提交到已连接的仓库（来源：AWS News Blog 公告）。

公告中有两点对验收设计特别关键。第一，每个修复都需要人工审批后才合并，最终决定留在团队；公告提到未来会允许团队在自定义护栏内决定服务可自主执行哪些动作，并以测试覆盖率、改动范围边界、历史成功率等作为置信门——这是未来能力，不是当前状态。第二，公告原文明确：生成的补丁不等于问题已修复，仍需人工审阅与合并。

可用性方面，公告称该服务在美國东部（弗吉尼亚北部）与美國西部（俄勒冈）两个区域提供，定价指向定价页；具体价格本文未核实。

把“已修复”拆成可核对的验收维度和证据#

下面的表格把验收拆成七个维度。左列是问题，中列是可留档的证据类型，右列是证据不足时的处理建议——建议部分属于工程实践推断，不是来源事实。

为什么“证据等级”必须单独列一项

公告描述的证据等级，举例是“通过对漏洞代码路径做静态分析得出的结论”，公告示例中该字段显示为 Static proven、验证状态 Completed。这类分级的意义在于：同样是“已确认”，静态证明与沙箱复现能支撑的结论强度不同。如果团队把所有确认问题一视同仁地处理，验收就会退化成核对状态字段。更稳妥的做法是把证据等级写进合并前置条件——达到某一级才允许合并，低于该级的留在待验证队列。

为什么“环境边界”容易被忽略

可达性判断依赖上下文图，而上下文图的覆盖面由你接入的代码源与部署的 collector 决定。一个只在部分账号部署了 collector 的组织，对未覆盖账号得出的“不可达”只是“未观测到”，不是“不存在”。同理，扫描按配置的频率执行或按需触发，验收结论本身带时间戳：网络入口变化、依赖新增、部署范围扩大之后，旧结论需要重跑而不是沿用。

一份最小验收记录（示例，未执行）#

下面是一段占位的记录骨架，字段可自行替换，仅为示例、未实际运行或对接任何端点。它的作用是把上面七个维度的证据落到可检索的字段上，而不是依赖 PR 评论区的口头确认。

{
  "finding_id": "FINDING-EXAMPLE-0001",
  "pr_url": "https://example.com/owner/repo/pull/0",
  "fix_type": "code_patch",            // code_patch | dependency_upgrade | config_change
  "evidence_level": "static_proven",   // 按实际分级填写
  "reproduced_in_sandbox": false,
  "context_scope": {
    "accounts": ["EXAMPLE-ACCOUNT"],
    "regions": ["EXAMPLE-REGION"],
    "collector_deployed": true
  },
  "regression": { "ci_passed": false, "suite": "PROJECT-SUITE" },
  "rollback": { "method": "revert_pr", "tested": false },
  "approval": { "reviewer": "PLACEHOLDER", "merged_at": null },
  "verdict": "pending"                 // pending | verified | rejected
}

注意 verdict 只在回归与回滚两项都有记录后才允许写成 verified；这个规则是建议，不是工具内置行为。

三个常见的误判#

• 把状态字段当成结论。公告示例中，一个问题的状态显示为 Completed、修复已 Delivered 到 GitHub，但流程仍然要求人工审阅并合并。状态反映的是流水线位置，不是验证结果。
• 把爆炸半径评估当成回归测试。爆炸半径是对影响范围的推断，回答的是“可能波及谁”；回归测试回答的是“行为是否改变”。两者不能互相替代。
• 把一次验收当成永久关闭。可达性、依赖关系和部署形态都会变，尤其在有自动合并或定时扫描的环境中，关闭状态应绑定到具体的扫描时点。

建议的落地顺序#

1. 先统一关联字段：让每个修复 PR 都能追溯到具体的 finding 标识，并保留控制台侧的证据摘要。
2. 把证据等级写进合并策略：低等级不进入关闭状态，只进入待验证队列。
3. 按三种修复形态分别定义回滚手段，配置变更单独走变更记录，不混在代码 PR 里。
4. 记录 collector 与代码源的覆盖范围，把它作为所有“不可达”结论的适用边界写进验收模板。
5. 如果计划将来启用自动应用修复，先积累人工审批与合并的历史记录——公告把历史成功率列为未来的置信门之一，这类数据只能靠前置流程攒出来。

尚待核实的部分#

以下几点在本次材料中未提供，需要查官方文档或实测确认：具体定价与计费口径；支持的代码源类型是否仅限公告提到的 GitHub 集成与 Amazon S3 桶；扫描频率的上限与并发限制；配置变更类修复是否也有对应的回退机制；以及自动应用能力的开放时间表。在这些信息明确之前，把“已修复”限定在可提供证据的范围内，比追求流程自动化更可靠。