AWS控制台里，一条漏洞的修复状态已经显示“交付到GitHub”，代码库中也出现了一份改动四个文件的拉取请求。但这条漏洞还不能被当成已经修好。10月22日正式可用的AWS Continuum for code vulnerabilities，把查找、验证和生成补丁连起来，却把最后的审核与合并留给团队。这个停顿，是理解这款AI安全服务的入口。

官方演示中的补丁增加50行、删除24行，涉及购物车服务。审核者看到的不只是一段修改建议，还有攻击者能否接触服务、是否需要认证、能影响哪些数据，以及支持判断的源码分析。修复被送到开发者平时工作的地方，安全团队无需再把控制台里的结论重新翻译成一张开发工单。

产品面对的摩擦也由此清楚起来：告警很多，并不代表每条都值得立刻动用工程师。AWS举例，一项只在开发环境使用的工具，与接近支付数据库的服务，单靠通用严重性分数可能无法区分实际处理顺序。该服务试图增加的是业务位置和攻击路径，而非再提供一张更长的扫描列表。

同一段代码，放在不同环境里会得到不同优先级

接入从建立环境开始。团队可以连接GitHub，或用Amazon S3中的代码作为来源，再选择扫描频率。采用S3时，存储桶必须位于启用服务的同一账户和区域，并通过IAM角色授予访问权限。软件能读到什么，首先取决于组织愿意提供什么。

团队还可在代码运行的AWS账户和区域部署采集器，授权环境使用云资源信息。采集器收集资源及网络配置，帮助服务判断漏洞能否从网络触达，以及攻击者从该位置还能到达哪里。官方称，它据此构建关联代码与环境的上下文图，识别服务依赖、负责人和所接触的数据。

这里有一个会改变初步理解的细节：产品同时保留原始发现与经过验证、排序的问题。Findings标签展示扫描器提供的基础材料，Issues标签才是供团队按优先级处理的结果。减少工作量的路径，是把发现变成可解释的问题，而非让开发者逐条接受机器告警。

证据也有层次。演示中的一项问题标为静态分析证明，系统对能够复现的问题则在隔离沙箱运行利用过程，并附概念验证代码和复现步骤。不能把“每条都有证据”扩写为“每条都已在真实生产环境成功攻击”。证据层级本身，正是审核者决定信任程度所需的信息。

补丁完成，责任才进入开发流程

修复可以是代码补丁、依赖升级或配置调整。拉取请求携带风险分析、修复摘要与证明，代码审核者不用离开GitHub就能理解为什么改。系统还评估既有防护是否能阻止已验证路径，使补丁不再脱离运行环境独立存在。

但正式发布说明给出了明确的时间边界：当前每项修复都从人类批准开始；让系统在指定护栏内自动执行某些修复，属于未来能力。不能拿此前预览阶段更宽泛的自动化愿景，替代这次正式可用产品的权限说明。

对企业采购者，这会改变试用时的问题。与其只比较模型找到多少漏洞，更有用的是检查环境信息是否足够、证据能否复现、补丁影响范围是否清楚，以及审核人是否有条件承担合并决定。这些判断来自官方展示的流程；公告并未给出可独立验证的客户平均修复时长或误报下降幅度。

可用区域目前是美国东部北弗吉尼亚和美国西部俄勒冈。扫描记录、来源设置、采集器以及是否生成修复补丁，都可在环境中管理。组织可以调整频率和输入，不必把所有代码与基础设施一次性接入。

从控制台到拉取请求，Continuum增加了一段机器完成的证据整理与修复交付。开发团队拿到的起点变得具体：攻击路径、业务影响和候选修改一起到达。上线权仍由有责任审查代码的人行使，自动生成补丁的速度没有取消这道组织决定。