GA 之后，自动验证怎么划边界：AWS Continuum 的误报判定与人工复核

简短回答：在 GA 版本中，AWS Continuum 把“自动验证”限定在“证明哪些发现可利用，并给出证据”这一侧，把“批准与合并”留在人这一侧。误报由三层证据共同判断，这三层分别是可达性、可利用性和现有防御，并非只由一个分数决定；人工复核的边界，也就取决于“现有证据是否支撑这次改动”，而不取决于“工具说它是不是误报”。

一、GA 版本里的“自动验证”具体验证什么#

AWS 在 2026 年 10 月 22 日宣布 AWS Continuum for code vulnerabilities 正式可用（GA）。按 AWS News Blog 的描述，该服务自动发现、验证并排序代码漏洞，然后把修复以补丁或 pull request 的形式交付。来源：AWS News Blog，2026-10-22

要理解它怎么界定误报，先要看它的上下文来源。Continuum 从两类数据构建上下文图：代码仓库，以及你的 AWS 环境。后者需要你在代码运行的账户和 Region 里部署一个 collector，由它收集 AWS Config 资源、网络配置等信息。目的很具体：判断一个漏洞是否能通过网络到达，以及攻击者从那里还能到达什么。

在此基础上，它识别业务关键系统。材料举的例子是客户数据存储、支付管道和认证服务；然后按每条攻击路径与这些系统的距离排序。这一步解释了为什么“可利用”和“高优先级”不是一回事：博客的控制台演示里，一个问题的可利用性是 Exploitable、证据等级为 Static proven、可能性为 High，但影响只有 Moderate，爆炸半径限于同一租户内的其他用户。两个维度分开看，排序才有意义。

验证的产物也不是一个布尔值。对能复现的发现，Continuum 会在隔离沙箱里运行 exploit，附上带复现步骤的 PoC；它给出攻击路径、支撑的源码分析、爆炸半径评估，还会评估你现有的防御是否会检测并阻止这条已验证的路径。这些都属于证据，不直接构成结论。

二、“误报”在材料里至少有三种形态#

博客里有一句关键表述：扫描器每天产出成千上万的发现，其中很多不需要动作，一个发现可能 unreachable、unexploitable，或者已经被某个运行时控制缓解。这三种情况经常被笼统叫作“误报”，但它们的复核方式完全不同。

还要区分 finding 和 issue。控制台的 Findings 标签列出原始扫描器输出；Issues 标签列出经验证、排序后的问题，每个问题带严重度、状态和创建时间，并有一节 Contributing findings 指明它由哪条扫描器发现构建而来。这意味着“误报率”的分母应该是 finding，而非 issue；把两者混在一起谈，数字没有意义。

材料没有说明 Continuum 是否使用“误报”这个正式分类，也没有给出完整的证据等级列表和判定阈值。从描述看，它更像是在回答“这条发现能不能被利用、证据有多强”，而不太像是在回答“这是不是误报”。这是根据材料做的推断，不是官方口径。

三、人工复核的边界画在哪#

当前边界很清楚：每一个修复都以 pull request 交付，需要人审查并合并。博客里的控制台演示也明确写着，生成补丁不等于问题已修复。换句话说，自动化只走到“提出”这一步，落地仍由人决定。

未来的边界则是可配置的。材料说，之后你可以决定 Continuum 在你自己定义的护栏内能自主执行哪些动作；前提是它对特定修复类别建立了信心，并通过测试覆盖率、范围边界、历史成功率这类“信心门”。

对团队来说，这意味着边界是可以按修复类别逐类放宽的，并非一次性划定的全局开关。合理的顺序是先积累数据再放权：依赖升级这类改动面小、测试覆盖高的类别，可以先观察人工推翻率；跨服务的代码补丁则应该保留人工批准。这是建议，不是材料里的规定。

四、一份可操作的复核清单#

1. 先看证据等级，再看严重度。Static proven 加上沙箱复现和 PoC，与只有静态分析结论，分量不同。
2. 核对攻击路径是否经过你真实的入口。上下文图依赖 collector 的配置，网络配置变了，可达性判断也会变。
3. 核对 PR 改动面与爆炸半径是否一致。改动跨出了评估范围，就应该退回。
4. 单独验证“现有防御会拦截”这一结论。它依赖运行时控制的实际配置，而配置会变化。
5. 看测试是否覆盖改动路径。这也是未来信心门的输入之一。
6. 记录每一次人工推翻，注明理由。这些记录是团队自己评估历史成功率的原始数据。

如果要把复核过程记录下来，可以用一个简单的模板。下面的字段是演示用的建议格式，不是 Continuum 的实际输出格式，也没有经过任何端点调用：

{
  "issue_id": "DEMO-001",
  "decision": "approve | reject | defer",
  "evidence_level_seen": "按控制台实际显示填写",
  "reproduced": true,
  "blast_radius_matches_patch": true,
  "defense_assumption": "记录“现有防御会拦截”所依赖的配置",
  "reviewer_role": "填写角色，不记录个人敏感信息"
}

五、还需要核实的地方#

• 证据等级的完整列表与各等级的判定阈值。材料只举了 Static proven 一例。
• “不可利用”判定的准确性，以及沙箱复现失败时如何处理，材料未说明。
• 支持的代码源、扫描器与语言生态的完整范围。
• 定价、配额，以及自动应用修复能力的开放时间表。GA 时可用区域为 US East (N. Virginia) 和 US West (Oregon)，其他区域待核实。

归结起来，GA 之后的边界可以这样记：验证可以自动，证据必须可读，落地必须人批。把复核精力放在证据强度和改动范围上，就可以避开“这是不是误报”这种容易导致复核失焦的争论。