AWS Continuum 代码漏洞服务 GA：自动发现、验证与修复排序的六组工程验收

如果只问一句：AWS Continuum for code vulnerabilities 的工程验收该拆成什么？答案是六组条件——接入上下文、finding 可追溯、可利用性有证据、排序贴近业务、修复以 PR 交付且由人合并、扫描与配置可运营。前四组必须在接入阶段就固定口径，否则后面看到的"已验证""已排序"都无从复核。本文依据 AWS 于 2026 年 10 月 22 日发布的 GA 公告整理（AWS News Blog），未在真实账户中执行验证；价格、配额以及公告两个区域之外的可用性均待核实。

先划清"自动"到底自动到哪一步#

公告里的措辞很明确：Continuum 找出并验证代码漏洞，再把修复以补丁或仓库 PR 的形式交付。也就是说，自动化覆盖的是"发现—验证—排序—生成修复—提交 PR"，不覆盖"合并"。公告同时说明，每个修复都从"Continuum 提议、人工批准后才上线"的模式开始；未来可以让用户自行决定哪些动作可交给它自主执行，并受用户定义的护栏约束。这条边界决定了验收的第一条原则：凡是涉及"改了什么进入主干"的结论，都必须落在 PR 与人工评审记录上，而不是落在服务端的"已完成"状态上。

验收一：接入与上下文是否覆盖真实运行面#

• 代码源：可以是 GitHub 集成，也可以是 Amazon S3 桶。S3 源有两个前提：桶要位于开启 Continuum 的同一账户和同一 Region，并通过一个 IAM 角色授权 Continuum 代入访问。
• AWS 上下文：在代码运行的账户和 Region 中部署 collector，它采集 AWS Config 资源与网络配置这类信息，供 Continuum 判断漏洞能否经网络到达、攻击者从该点还能触及什么；environment 还需被授权使用该 collector。
• 验收问题：collector 覆盖的账户与 Region，是否等于这段代码实际运行的范围？未覆盖部分，可达性判断的依据是什么？公告未说明降级或缺失上下文时的行为，待核实。
• 建议：把"未接入 AWS 上下文"的 environment 单独标记验收等级——它拿到的主要是代码侧证据，与同时具备网络与资源上下文的 environment 不应混在同一张报表里比较。

验收二：从 finding 到 issue 能否回溯#

公告区分了两层对象：Findings 是环境里原始扫描器输出，Issues 是经过验证与排序后的问题。每个 issue 带一个 Contributing findings 区块，列出构成它的具体扫描器 finding；Scans 页签则保留每次扫描的状态、来源、请求时间与完成时间。这组设计直接给出了验收动作：随机抽取若干 issue，看能否沿 Contributing findings 回到原始 finding，再回到产生它的那次扫描记录。误报争议、复测结论、责任归属，最终都要靠这条链路复盘。如果这条链路断在某一环，"已验证"就只是一个标签。

验收三：证据等级与可复现性分开统计#

Continuum 会针对每个 finding 结合代码与环境上下文给出一个证据等级（evidence level），公告举的例子是"由静态分析证明的脆弱代码路径"（Static proven）。对能复现的 finding，它会在隔离沙箱中运行 exploit，并附上 PoC 代码与复现步骤；此外还会评估现有防御是否会检测并阻止这条已验证路径。产出物是攻击路径、支撑性源码分析和爆炸半径（blast radius）评估，而不是一个风险分数。

据此，验收表里至少要把两类结果分开：附 PoC 与复现步骤的，和仅由静态分析证明的。前者的复核成本接近"照着步骤跑一遍"，后者仍需人工判断上下文是否成立。公告只给出了 Static proven 这一个等级示例，完整的等级枚举待核实，因此不建议在验收标准里预设等级清单。

验收四：排序是否贴近业务，而不是贴近通用分数#

公告的论证是：通用严重度分数不告诉你攻击者实际能到达哪些资源，dev-only 工具上的 critical 与紧邻支付数据库的服务上的 medium 看起来一样。Continuum 从代码仓库与 AWS 环境构建上下文图，学习哪些系统业务关键、归属谁、服务之间如何依赖、各自触及哪些数据，识别客户数据存储、支付流水线、认证服务这类高价值系统，再按攻击路径与这些系统的接近程度排序。

公告中用于演示的那条 issue 是：High 严重度、状态 Completed、修复已交付到 GitHub；可利用性判定为 Exploitable，证据等级 Static proven，验证运行状态 Completed；Likelihood 为 High（该服务可被攻击者到达、无需认证、无需用户交互）；Impact 为 Moderate（攻击者可修改业务数据，爆炸半径波及同一租户的其他用户）。这组数值来自公告作者的演示环境，不是我们的实测结果，不能当作基线。排序的算法与权重公告未公开，待核实；可行的验收方式是抽取排序靠前的一批 issue 做人工复核，并把"排序争议"作为固定反馈项记录下来。

验收五：修复以 PR 交付，合并权留在人手里#

每个确认的问题会生成一个修复——代码补丁、依赖升级或配置变更——并在已连接的仓库中开成 PR，等待评审。公告特意强调：控制台明确说明"生成了补丁不等于问题已修复"，仍需人工评审并合并。PR 描述会携带与控制台相同的风险评估、修复摘要与 proof，评审者在 GitHub 内即可看到证据，不必切换工作流。演示中的那个 PR 标题为 "Continuum fix"，改动 4 个文件、新增 50 行、删除 24 行，位于 cart service——同样是公告演示值。

因此修复侧的可验收项应落在 PR 本身：是否附带证据与爆炸半径、能否单独回滚、CI 是否在 PR 上跑通、reviewer 是否固定、合并后是否有对应的复测记录。至于"未来可在测试覆盖率、范围边界、历史成功率等信心闸门通过后自动应用某类修复"，公告明确属于未来能力，不应写进当前验收标准。

验收六：扫描节奏与配置是否可运营#

Scans 页签提供扫描历史，并支持 Configure scan frequency 调整频率、Queue scan 按需触发；Configuration 页签管理 environment 的代码与上下文来源、代码集成、环境设置（例如是否生成修复补丁）以及所用的 AWS collector。可验收的点是：扫描频率与代码合并节奏是否匹配、按需扫描是否受限、关闭补丁生成后 issue 与证据是否仍然产出（公告未逐项说明这些开关的连带影响，待核实）。

一张可直接用的验收表#

哪些结论现在还不能写进验收标准#

• 不要写降误报比例。公告没有给出任何 quantified 的误报率或验证准确率，写进验收表就是自造指标。
• 不要把未来能力当现能力。按修复类别自主应用属于公告描述的未来方向。
• 不要用通用严重度分数替代攻击路径证据。公告的整套论证正是针对这一点。
• 区域与价格待核实。公告称当前在 US East (N. Virginia) 与 US West (Oregon) 提供，价格指向 pricing 页面但未给出具体数值，其余区域的可用性也未说明。

把六组条件按上表落下来，验收的落点其实很朴素：每条 issue 都有一条能走通的证据链，每个修复都有一个带证据、可回滚、由人拍板的 PR。Continuum 把"确认可利用性"和"界定爆炸半径"从数小时的手工调查压缩成一次扫描的产出，这是公告的主张；而它是否在你的环境里成立，只能靠这套可复核的验收结构来回答，而不是靠一个总分。