代码漏洞扫描走向 GA：自动发现、验证与修复排序的工程验收

2026 年 10 月 22 日，AWS 宣布 Continuum for code vulnerabilities 正式可用（GA）。对开发者来说，这次 GA 值得核对的不是“AI 能否修漏洞”，而是它把一条原本靠人工串起来的链路拆成了可单独检查的中间产物：可达性判断、可利用性证据、影响范围评估，以及一个等待合并的拉取请求。下面按工程验收的顺序，逐环说明它给出什么、缺什么，以及哪一步缺失时结论必须降级。

它补的不是“发现”，是“值不值得修”#

公告给出的前提很具体：组织运行较大的应用组合时，扫描器每天可能产生数千条 findings，其中许多并不需要处理——不可达、不可利用，或已被运行时控制缓解。通用严重性分数的问题在于不带环境信息，一个只影响开发工具的高危项，和离支付数据库一步之遥的中危项，在评分表上看起来差不多。

公告称，此前确认一条 finding 是否可利用要花数小时人工调查；带信心上线修复则要跨安全、基础设施、应用团队协调数天，因为缺少业务上下文时很难评估一次改动的波及范围。这个背景决定了服务的定位：它工作在扫描结果之上，做验证、排序与修复提议，而不是再叠一层扫描器。

第一环：上下文图决定“可达”#

collector 采集什么

Continuum 的上下文图来自两个源：代码仓库，以及你的 AWS 环境。在代码运行的账号与区域中部署 collector 后，它采集 AWS Config 资源与网络配置等信息，用来判断漏洞能否经网络到达、攻击者从那个位置还能抵达什么。在此基础上，服务推断哪些系统属于业务关键、由谁负责、服务之间如何依赖、各自触及哪些数据。

这一步的验收含义很直接：没有 collector，判断只剩代码侧，网络可达性与攻击者视角缺失。公告把 collector 列为可选步骤，但排序依据依赖它，因此部署与否应作为结论可信度的前提记录在案，而不是当成可选装饰。

排序口径是攻击路径，不是通用评分

公告描述的排序方式，是看每条问题的攻击路径与客户数据存储、支付流水线、认证服务这类高价值系统的接近程度。这意味着优先级同时受两边影响：漏洞本身的位置，以及该服务在业务拓扑里的位置。前者可读代码，后者只能靠环境上下文，两者任一过期，排序就会偏移。工程上应对应的动作是定期校准业务关键系统清单，而不是照单接受排序结果。

第二环：证据分档，别把不同强度混为一谈#

每条 finding 会对照代码与环境上下文分析，并给出证据等级（evidence level），例如通过对易受攻击代码路径做静态分析得出的结论。对可复现的问题，服务会在隔离沙箱中运行利用代码，并附上概念验证代码与复现步骤。输出不止一个分数，而是攻击路径、支撑性源码分析和影响范围（blast radius，指一次利用或一次改动可能波及的人员与数据边界）评估，另外还会评估既有防御能否检测并阻断这条已确认的路径。

这里至少存在三类强度不同的证据：静态分析结论、沙箱复现结果、对现有防御的评估。验收时应分开看。有复现步骤说明服务成功构造了利用；只有静态结论时，应记为“疑似可利用”而非“已确认可利用”；防御评估缺失时，不能默认 WAF 或运行时控制已经覆盖该路径。公告里的证据等级名称（如 Static proven）本身也值得对齐到内部的风险分级表，否则跨团队沟通时仍会各说各话。

第三环：修复以拉取请求交付，人工闸门保留#

对每个确认的问题，服务会生成修复，形式可能是代码补丁、依赖升级或配置变更，并在已连接的仓库中开成拉取请求，标题形如 “Continuum fix”。拉取请求描述里带着与控制台一致的风险评估、修复摘要和证据，评审者在 GitHub 内即可看到依据，不必在两个界面之间来回切换。

公告明确写出：每个修复都从“Continuum 提议、人工批准”的模式开始，由你的团队评审并合并，最终决定权保留在团队手里。控制台也会提示，生成了补丁不等于问题已经修复。这句话应当被当作流程约束，而不是免责声明——它意味着“已修复”仍需要一条独立的收尾动作：合并后重跑扫描，确认原 finding 关闭。

未来的自动应用，先看门槛再谈

公告描述了一个尚未提供的能力：在对特定修复类别积累足够信心后，可以允许 Continuum 在通过信心门槛时自动应用修复，门槛包括测试覆盖率、范围边界和历史成功率。这三项恰好也是人工评审时最常问的三个问题。在能力开放之前，它们更适合作为评审清单的固定项：改动是否在测试覆盖范围内、范围是否越出预期、同类修复过去是否真的成功过。

接入条件与当前边界#

• 代码源：GitHub 集成或 Amazon S3 桶，二者选一接入后创建环境，按自选计划扫描。
• S3 前置条件：桶必须与开启服务的账号和区域相同；访问通过服务承担的 IAM 角色授权。
• AWS 上下文：在代码运行的账号与区域部署 collector，并授权环境使用它。
• 可用区域：公告称当前在 US East (N. Virginia) 与 US West (Oregon) 提供。
• 价格：公告指向定价页，未给出计费口径，待核实。
• 自主修复：尚未提供，属于公告描述的未来能力。

运营侧：扫描节奏本身就是验收项#

控制台的 Scans 页保存每次扫描的状态、来源、请求时间与完成时间，可以修改扫描频率，也可以按需排队执行一次。Configuration 页管理环境读取的代码源与上下文源、代码集成、是否生成修复补丁等设置。对工程团队来说，这些记录的价值在于回答一个朴素问题：本周的结论是基于哪次扫描、哪份上下文得出的。扫描没跑成功却仍在讨论优先级，是最容易被忽略的失效路径。

一份可核对的验收清单#

需要说明的是，公告中演示的那条问题（High 严重性、可利用性为 Exploitable、证据等级 Static proven、改动 cart service 的 4 个文件、新增 50 行删除 24 行）是 AWS 自己的界面示例，不是本文的测试结果。本文未运行该服务，也未核验其定价、配额与扫描器兼容范围；这些均待核实。

与既有 SAST/SCA 流水线怎么摆#

公告描述 Continuum 的 Findings 页列出环境内的原始扫描结果，每条问题另有一栏 Contributing findings 指明它由哪条扫描结果构成。这说明它站在扫描器下游，而不取代扫描器。至于支持哪些工具、findings 以何种方式进入，材料没有展开。较稳妥的定位是：它是 findings 之上的一层验证与排序，原有 SAST 与 SCA 是否保留、如何并行，取决于团队对覆盖面的要求，而不是这条公告的结论。

结论#

GA 的实际价值在于把“要不要修”变成一个可审查的过程，而不是把修复变成无人值守。可验收的最小闭环有四步：collector 覆盖到位，证据等级与影响范围可读，拉取请求的范围可解释，合并后重跑能关闭原 finding。四步里缺任何一步，都只能算“已提议”，不能算“已修复”。区域与定价这类外部条件会变，采购与排期前应以官方定价页与用户指南为准。