AWS Continuum GA：AI 补丁的验证链、人工闸门与回滚边界

AWS Continuum for code vulnerabilities 已正式可用。按 AWS 于 2026 年 10 月 22 日发布的公告，这个服务用 AI 找出并验证代码漏洞，再把修复以补丁或 pull request 的形式交付。但“AI 自动修漏洞”这句话需要拆开看：材料支持的是“提议修复、由人批准”，不支持“自动上线”；至于回滚，公告没有把它描述为一项独立能力。下面按验证链、交付闸门、回滚与退出边界三部分说明，并标出事实、推断与待核实项。

它先解决的是噪声，不是人力#

公告给出的背景是：前沿模型可以把一份漏洞披露在几分钟内变成可工作的 exploit；同时，大型应用资产上的扫描器每天产出数千条 finding，其中很多不需要处理——不可达、不可利用，或已被运行时控制缓解。通用严重性评分无法回答“攻击者实际能到达哪里”，于是一个只存在于开发工具的 critical 和一个离支付数据库一步之遥的 medium，在列表上看起来一样。

Continuum 的定位是补上这段判断：确认哪些 finding 在当前环境中可利用，按业务影响排序，再为每个确认的问题生成修复。排序依据是攻击路径与高价值系统的接近程度，而不是通用严重性分数。这是对问题的重新定义，不是对人工的完全替代：判断“哪些值得修”仍需人来做，服务只是把证据摆到前面。

验证链：证据等级与沙箱复现#

Continuum 从两个来源构建 context graph：代码仓库，以及代码运行所在的 AWS 环境。后者的接入方式是在相应 account 和 Region 部署 collector，采集 AWS Config 资源与网络配置等信息，用来判断漏洞是否可经网络到达、攻击者从该点能触达什么。基于这张图，服务识别客户数据存储、支付管道、认证服务等高价值系统，并据此排序。

对每条 finding，服务会给出 evidence level。公告举的例子是“Static proven”，即通过静态分析证明存在易受攻击的代码路径。对能够复现的 finding，Continuum 会在隔离沙箱中运行 exploit，并附上 PoC 代码与复现步骤。输出不止一个风险分，还包括攻击路径、支撑的源码分析和爆炸半径评估；服务还会评估现有防御能否检测并阻止这条已验证路径。

需要留意的是：evidence level 描述的是证据强度，不是修复状态。控制台在修复区域明确写着，生成补丁不代表问题已经修复。这句话是整个产品边界的关键。

材料没有说明 evidence level 的完整取值、沙箱的隔离实现、误报率与验证耗时。这些属于待核实项；如果团队要用它替代人工初筛，应先在 user guide 和实际环境中确认（材料也未给出 user guide 的直达链接）。

交付闸门：PR 是默认终点#

对每个确认的问题，Continuum 生成修复——代码补丁、依赖升级或配置变更——并在已连接的仓库中开一个 pull request。每个修复都需要人工批准：由人审查并合并，最终决定权留在团队。PR 描述中带有与控制台相同的风险评估、修复摘要和证据，审查者不必离开 GitHub 就能看到依据。

公告开头提到修复可以以“可自动化的补丁”交付，但正文又明确当前每个修复都始于“提议—批准”模式，自动执行被放在未来。这两处表述需要对照阅读：现阶段应按“人工合并”来规划流程。

公告中的界面示例显示：一个问题被评为 High，状态 Completed，修复已 Delivered to GitHub；Exploitability 为 Exploitable，evidence level 为 Static proven，Likelihood 为 High（可从攻击者到达、无需认证、无需用户交互），Impact 为 Moderate（可修改业务数据，爆炸半径达同租户其他用户）；对应的 PR 改了 4 个文件，新增 50 行、删除 24 行，位于 cart service，标题为“Continuum fix”。这些数字是 AWS 博客演示环境中的界面快照，不是性能基准，也不代表你的仓库会出现同样的规模。

控制台还有几个与边界有关的开关：Configuration 标签页管理代码与上下文来源、代码集成、环境设置（例如是否创建 remediation patches），以及使用的 AWS collector。Scans 标签页可以改扫描频率或按需排队扫描。也就是说，“是否生成补丁”在环境级别可配置，但材料没有给出该开关的默认值与权限要求。

回滚边界：材料写了什么，没写什么#

这是最需要克制的地方。公告描述的控制点有三个：补丁以 PR 形式存在，合并前不改变代码；合并动作由人完成；未来可以在用户定义的护栏内，让 Continuum 对特定修复类别自动执行——前提是通过信心门，比如测试覆盖率、范围边界和历史成功率。公告明确把这部分放在“未来”，截至本文写作时属于路线图描述，不是现有能力。

材料没有描述以下内容：合并后的自动回滚、运行时回滚、补丁版本保留策略、失败检测与回退触发条件。因此不能说 Continuum 提供回滚机制。可以说的推断是：一旦 PR 被合并，退出路径回到常规工程实践——Git 回退、重新部署、依赖版本回退——是否足够，取决于你自己的发布流程与测试覆盖，而不是这个服务的功能声明。

换句话说，当前版本的“回滚边界”等于“合并前的人工闸门 + 合并后的常规发布流程”。人工闸门是产品内建的；后半段需要你自备。这也是评估这类工具时容易忽略的成本：验证做得再细，合并之后的止损仍然由你的 CI/CD 与回滚演练决定。

接入时值得先核实的事项#

公告给出的可用区域是美国东部（弗吉尼亚北部）和美国西部（俄勒冈）。代码源可以是 GitHub 集成或 Amazon S3 桶；S3 的前置条件是桶与开启 Continuum 的 account、Region 相同，并通过 Continuum 承担的 IAM role 授权。AWS 基础设施上下文是可选项，需要在代码运行的 account 和 Region 部署 collector，并授权环境使用。定价公告只说“见 pricing 页面”，具体价格待核实。

如果目标是减少“哪些 finding 真的可利用”的判断成本，这个服务的证据链对准了问题；如果目标是让修复无人值守地上线，材料不支持这个结论，公告自己把自动执行放在未来。至于回滚，先假设它不存在，按“合并即生产变更”的常规标准准备退出路径，再根据后续文档核实是否有新增能力。