AI 自动发现并验证代码漏洞：自动化验证环节值得关注的原因与局限

简短回答：AI 自动化验证值得关注，不是因为它能替代扫描器或替代人做合并决定，而是因为它把“这条告警到底能不能被利用”从一次耗时数小时的人工排查，变成一份带证据的产出，并把修复直接落到可评审的 PR 上。它的局限同样明确：验证的输入仍然来自扫描器，结论强度取决于接入的上下文是否完整、沙箱复现的保真度有多高，而最终是否合并仍由人决定。下文依据 AWS 官方博客的发布说明与控制台演示，区分材料事实与推断。

为什么“验证”要单独作为一个环节#

AWS 在发布说明中给出的问题描述很直接：大型应用资产上，扫描器每天可能产出数千条 findings，其中很多不需要动作——不可达、不可利用，或已被运行时控制缓解。通用严重性分数不回答“攻击者实际能触达哪些资源”，因此一个仅用于开发的工具上的 critical，看起来和距离支付数据库一步之遥的服务上的 medium 没有区别。材料给出的代价是：确认一条 finding 是否可利用需要数小时人工调查，而有把握地交付修复需要安全、基础设施、应用团队跨团队协调数天，因为缺少业务上下文时很难判断变更的影响范围。AWS News Blog：AWS Continuum for code vulnerabilities is now generally available（来源日期 2026 年 10 月 22 日）

这就是验证环节的位置：它不生产告警，它消费告警，并回答“这一条在你的环境里是否成立”。

Continuum 的验证由哪些部分组成#

按材料描述，Continuum 的验证建立在两个来源之上：代码仓库，以及通过 collector 采集的 AWS 环境信息（例如 AWS Config 资源和网络配置）。它据此构建上下文图，学习哪些系统是业务关键、由谁负责、服务之间如何依赖、各自接触哪些数据，再按攻击路径与高价值系统（材料举例为客户数据存储、支付管道、认证服务）的接近程度排序。

对每条 finding，它给出的是证据而非单一分数：证据等级（材料举例为通过静态分析证明漏洞代码路径的 verdict）、攻击路径、支撑性源码分析、爆炸半径评估，并额外评估既有防御能否检测并阻断这条已被验证的路径。对可复现的问题，它在隔离沙箱中运行 exploit，并附上 PoC 代码与复现步骤。

控制台里“扫描器原始 finding”与“验证后的 issue”的区别，可以对照成两类信息：

需要说明：表格只是对材料中字段的归类，不是产品文档的完整字段清单；字段命名与取值以官方文档为准。

修复怎么交付，人机边界在哪#

对确认的问题，Continuum 生成修复——代码补丁、依赖升级或配置变更——并在已连接的仓库中开成 PR。材料明确：每个修复都从“Continuum 提议、人批准”的模式开始，由团队评审并合并，最终决定权在人。未来会允许在团队定义的护栏内，对特定修复类别在通过置信门（例如测试覆盖、范围界限、历史成功率）后自动应用。

博客作者的控制台演示里，一条 High 级 issue 的修复 PR 修改了 4 个文件、新增 50 行、删除 24 行，PR 描述里带着与控制台相同的风险评估、修复摘要与证据。这是官方博客的演示环境示例，不是性能或准确率基准，不能据此推断你自己的代码库会有类似规模或质量。

控制台明确提示：生成了补丁不等于问题已修复。这条提示是理解整个流程的关键——验证降低了判断成本，但没有取消评审责任。

接入与运行的实际步骤#

1. 连接代码源：GitHub 集成，或 Amazon S3 桶。S3 方式的前置条件是桶与开启 Continuum 的账号、Region 相同，并通过 Continuum 承担的 IAM 角色授权。
2. 创建 environment，并选择扫描计划。
3. 可选：在代码运行的账号与 Region 部署 collector，并授权 environment 使用它，以补充 AWS 基础设施上下文。
4. 在 Scans 标签页查看每次扫描的状态、来源、请求与完成时间；用 Configure scan frequency 改周期，或用 Queue scan 按需触发。
5. 在 Configuration 标签页管理代码源、上下文来源、环境设置（如是否生成修复补丁）与 collector。

可用区域：材料写明当时为美国东部（弗吉尼亚北部）与美国西部（俄勒冈）。其他区域、配额与价格本次材料未给出具体数值，待核实；博客只指向定价页与用户指南，未在正文中提供 URL。

局限：哪些结论不能从“已验证”推出来#

• 输入仍受扫描器约束。issue 由扫描器的 findings 构建（控制台有 Contributing findings 区块）。据此推断：扫描器没报出的问题不会进入验证队列，验证不构成覆盖率的补齐。
• 上下文有边界。上下文图来自已连接的代码源与已授权的 collector 账号与 Region。未接入的仓库、其他云或本地环境不在其中，跨边界的攻击路径判断会失真。
• 证据强度不等价。“静态证明”与“沙箱复现”是不同强度的证据；沙箱中触发成功说明在该隔离环境中可触发，不等于生产网络可达、不等于绕过所有运行时控制。材料中“评估既有防御能否检测并阻断”正是补这一层，但其判断质量同样依赖采集到的配置准确性。
• 修复质量缺少公开指标。材料未给出补丁的错误率、回滚率、测试通过率等数据，待核实。依赖升级类修复还可能引入版本兼容问题，需要常规 CI 与人工评审兜底。
• 语言、框架与包生态的支持范围材料未说明，待核实；在评估前不宜假定与你现有技术栈完全匹配。
• 成本与权限。定价、扫描与沙箱执行的计费口径待核实。collector 需要读取资源配置与网络信息，S3 方式需要 IAM 角色授权——权限最小化与数据边界应按自身合规要求单独评估，不能沿用默认配置了事。

一个可执行的评估顺序（建议）#

1. 选一个非生产账号、一个中等规模仓库接入，先不接 collector，观察仅有代码上下文时的证据质量。
2. 再接入 collector，对比同一批 findings 在有无环境上下文时的可利用性判定差异。
3. 把验证后的 issue 与现有 SAST/SCA 结果并列，统计“被证伪”和“被证实”的比例——这是最直接的价值指标，也是材料未提供、只能自测的部分。
4. 抽查若干修复 PR：是否可读、是否附带测试、改动范围是否与爆炸半径评估一致；把结论写进合并前检查清单。
5. 记录每次人工复核耗时，再决定是否扩大扫描范围。自动应用修复目前尚不可用，不要把未来的护栏能力当作当下的运维假设。

结论#

把“可利用性验证”和“修复交付”放在同一条链上，是这个服务真正值得关注的地方：它改变的是告警到决策之间的信息密度，而不是决策权归属。相应地，评估它时最该问的不是“AI 准不准”，而是“我的扫描器覆盖了什么、我的上下文接全了没有、我的评审流程能不能消化这些 PR”。这三件事的答案都在你的环境里，公开材料给不了。