托管化漏洞扫描把“发现到验证”接上了，责任边界落在哪一环

结论先放在前面：这一类服务托管掉的是“发现”和“验证”，没有托管“决定”。AWS 在 2026 年 10 月 22 日的公告中宣布 AWS Continuum for code vulnerabilities 正式可用（AWS News Blog），它自动找出代码漏洞、确认哪些在当前环境中可利用、按业务影响排序，并把修复以补丁或拉取请求（PR）的形式交出来。但同一篇公告明确写着：每一条修复都从“服务提议、人工批准”的模式开始，由人审阅并合并；让服务在用户划定的护栏内自主执行，属于“未来”的能力。

所以对开发者来说，真正需要先想清楚的不是“它准不准”，而是责任落在哪一段。下面按数据边界、判定边界、变更边界三层拆开讲。这个三层分法是本文的组织方式，不是 AWS 的表述。

一、它把哪两个原本分离的环节接了起来#

按公告描述，Continuum 用前沿 AI 模型做四件事：发现、验证、按业务影响排序、产出修复。它要解决的是传统扫描器的老问题——通用严重度分数不告诉你攻击者实际能碰到什么。公告举的对比很直接：一个只用于开发的工具上的 critical，和一个离支付数据库只差一步的服务上的 medium，在分数上看起来一样；而确认一条发现是否可利用，过去要花数小时人工调查，把修复安全上线又要跨安全、基础设施、应用团队协调数天。

它的判断依据不只看代码。公告说 Continuum 从两个来源构建上下文图（context graph）：代码仓库，以及你的 AWS 环境。后者需要在代码运行的账号和区域里部署一个 collector，采集 AWS Config 资源、网络配置等信息，用来判断漏洞是否能经网络触达、从它能摸到什么。有了这张图，它才能识别客户数据存储、支付链路、认证服务这类高价值系统，并按每条问题的攻击路径与这些系统的距离排序。

这一步是托管化最实质的变化：扫描器输出的是“发现”，服务输出的是“带环境上下文的判定”。代价是它必须读你的环境。

二、数据边界：采集范围就是第一条责任线#

公告给出的接入顺序值得原样保留，因为每一步都对应一个权限决策：

1. 连接代码源。两种：GitHub 集成，或 Amazon S3 存储桶。
2. 创建 environment，按你选定的计划扫描。若用 S3 源，桶必须与服务开通的账号、区域一致，并通过一个由服务承担的 IAM 角色授权访问。
3. 可选：在代码运行的账号和区域部署 collector，并把 environment 授权给它使用，从而获得 AWS 基础设施上下文。

也就是说，上下文采集是可选的，但“可选”不等于“无关”。不接 collector，判定就只能基于代码本身，攻击路径和爆炸半径的推断会弱一些——这是推断，公告没有逐项列出关闭采集后哪些结论会退化，需要实测才能确认，本次材料未提供。接上 collector，你要接受的是：服务会读取资源配置与网络拓扑。这两者的敏感度不同，前者偏资产清单，后者接近攻击面地图。

建议在接入前把三件事写成文档：collector 装在哪些账号与区域、IAM 角色授予的具体动作清单、以及谁能修改这些配置。第三项容易被忽略——如果任何工程师都能新建 environment 并授权 collector，采集边界就形同虚设。

三、判定边界：证据分层，但不是质量承诺#

公告对“验证”的描述是有层次的，这一点比“AI 找漏洞”的说法更值得细读：

• 证据等级（evidence level）：例如由对脆弱代码路径的静态分析得出的结论。
• 可复现的发现：在隔离沙箱中运行 exploit，附上概念验证代码与复现步骤。
• 输出形态：攻击路径、支撑该判定的源码分析、爆炸半径评估，而不只是一个风险分数。
• 防御有效性：评估现有防护是否会发现并阻断这条已验证的路径。

这四层回答的是“你凭什么这么说”，而不是“你说对的概率是多少”。公告没有给出准确率、漏报率或误报率数字，本次材料也未提供，任何关于“误报降低多少”的预期都应标为待核实。

公告里有一段界面演示记录，某条问题被评为 High、可利用性为 Exploitable、证据等级 Static proven、可能性 High、影响 Moderate，修复以 PR 形式落到 GitHub，改动 4 个文件、新增 50 行、删除 24 行，涉及 cart service。这组数字是 AWS 作者在自建演示环境里的界面截图描述，不是可复现的基准，也不能当作性能数据引用。同理，公告提到的可用区域只有 US East (N. Virginia) 与 US West (Oregon)；定价页面被指向但未给数字，价格待核实。

四、变更边界：PR 打开不等于问题关闭#

修复有三种形态：代码补丁、依赖升级、配置变更，统一以 PR 形式开在你连接的仓库里，PR 描述携带与控制台相同的风险评估与证据。公告和控制台文案都强调了一句话的意思：生成了补丁，不代表问题已修复。最终决定权留在团队手里，因为合并动作、以及合并之后是否真的生效，仍然取决于你的评审和发布流程。

这张表里的第四行是责任边界最硬的一段。建议在仓库侧先设好必需评审人与分支保护，让“人工批准”不只是流程口头约定——具体配置方式需按你使用的代码托管平台核实，本文不展开。

五、为“未来自动应用”提前准备什么#

公告说未来会允许用户决定服务能自主执行哪些动作，并给出了置信度门的例子：测试覆盖率、范围边界、历史成功率。这三个都是可度量的，也都能提前积累：

• 测试覆盖率：没有测试的服务，自动应用的修复无法被自动验证，建议先不纳入。
• 范围边界：例如限制单次 PR 的改动文件数与行数上限，超出即转人工。
• 历史成功率：记录每一类修复（补丁 / 依赖升级 / 配置变更）的合并率与回滚率，作为日后放宽权限的依据。

这三条是基于公告所列门槛提出的准备建议，不是产品现有功能。当前版本的行为仍是每条都要人批准。

还需要核实的部分#

本次材料只包含公告页面的抓取片段，未做独立测试。以下事项在材料中没有依据，应视为待核实：服务的实际定价与计费口径、在其他区域的可用时间、对非 AWS 运行环境的支持程度、扫描频率上限、以及任何准确率或效率指标。如果你的团队正准备评估，务实的起点是选一个有测试覆盖、依赖清晰的中等规模仓库接入，跑完一轮完整流程，再决定是否扩大采集范围。