AWS Continuum GA：代码漏洞的误报证据链与修复排序

如果你的代码扫描每天产出上千条发现，真正的问题不是“有没有漏洞”，而是哪些能被攻击者实际利用，以及先修哪一条。根据AWS 2026 年 10 月 22 日的公告，AWS Continuum for code vulnerabilities 把这两个问题放在同一条工作流里：用代码和 AWS 环境上下文验证发现的可利用性，按业务影响和攻击路径排序，再把修复作为待审核的拉取请求（PR）交付。需要先说明限制：公告没有给出误报率、检测准确率或定价，本文不把这些未知数补成结论。

误报处理不是“删掉告警”，而是给出可审查的证据#

公告把传统扫描器的痛点说得很直接：大量发现可能不可达（unreachable）、不可利用（unexploitable），或者已经被运行时控制缓解。通用严重分无法说明攻击者实际能到达哪些资源，因此开发环境工具上的“严重”与服务支付数据库旁的“中危”看起来同样紧急。Continuum 的做法不是简单过滤，而是建立一张上下文图，再逐条判断。

上下文图有两个主要来源：代码仓库和 AWS 环境。开发者在代码运行的账户和区域设置 collector，采集 AWS Config 资源和网络配置等信息，用于判断漏洞是否能通过网络到达，以及攻击者从该点还能触达什么。Continuum 从图中识别业务关键系统、系统所有者、服务依赖和每个系统涉及的数据，再据此理解攻击路径。

在单条发现上，Continuum 会结合代码和环境上下文给出证据等级，例如通过静态分析脆弱代码路径得出的“Static proven”。对能够复现的发现，它在隔离沙箱中运行利用代码，并附上概念验证代码和复现步骤。输出包括攻击路径、支撑源码分析和爆炸半径评估，而不只是风险分。它还会评估现有防御能否检测并阻止已验证的路径。

对开发者的含义：审查时应先问“证据等级是什么、是否有复现、攻击路径经过哪些资源”，而不是先看严重度标签。公告没有说明 Continuum 会自动关闭或抑制不可利用的发现；如果团队流程依赖自动降噪，这一点需要另行核实。

修复排序：让“先修哪个”靠近业务上下文#

Continuum 从上下文图中识别高价值系统，例如客户数据存储、支付流水线和认证服务，再按攻击路径与这些系统的接近程度排序。公告给出的对比是：仅存在于开发工具上的严重分，与服务支付数据库一步之遥的中危，不应被同等对待。

这不是说严重分无用，而是它回答的问题不同。下面是操作建议，不是公告承诺：先看“可利用且有复现证据”的；再看“静态证明但尚无可复现”的；同一证据等级下，优先攻击路径更接近关键数据或认证链路的；最后把变更面大、爆炸半径广的修复拆开评审。

公告的控制台示例中，一条问题被标为 High；Exploitability 为 Exploitable，证据等级为 Static proven，验证已完成；Likelihood 为 High，因为服务可被攻击者到达、无需认证、无需用户交互；Impact 为 Moderate，表示攻击者可修改业务数据，爆炸半径波及同租户的其他用户。这些是公告演示环境中的字段，不是对任意环境的性能结论。

接入前要核对的边界#

公告给出的接入方式包括：连接 GitHub 集成或 Amazon S3 存储桶作为代码源，创建按计划扫描的环境。S3 源要求存储桶与 Continuum 在同一账户和区域，并通过 Continuum 代入的 IAM 角色授权。还可以选择设置 collector 补充 AWS 基础设施上下文。GA 时可用区域为美国东部（弗吉尼亚北部）和美国西部（俄勒冈）。

从这些条件看，区域与账户边界不是细节：collector 要放在代码运行的账户和区域；S3 源也不能跨账户、跨区域随意放置。材料只指向用户指南，没有展开全部权限和支持范围。私有仓库权限细节、支持的语言与框架、扫描频率上限等，均待核实；价格也没有在本次材料中给出。

收到 PR 后怎么审#

Continuum 的修复形式包括代码补丁、依赖升级或配置变更，并开成 PR。公告明确：当前每个修复都需要人工批准，合并决定仍在团队；控制台也说明，生成补丁不等于问题已修复。示例 PR 修改 4 个文件、增加 50 行、删除 24 行，PR 描述携带与控制台相同的风险评估、修复摘要和证据。

建议的评审顺序是：先看证据等级与复现步骤，确认问题真实且路径成立；再看攻击路径与爆炸半径，判断是否触及关键系统；然后看修复类型和变更范围，代码补丁、依赖升级、配置变更的风险并不相同；最后在团队既有测试和发布流程中验证，再合并。材料没有给出自动测试覆盖或回滚机制的具体规则，不能把“有 PR”当作验收完成。

把误报处理写进流程的检查清单#

• 区分 Findings 与 Issues：前者是原始扫描器发现，后者是经验证、排序的问题；不要把原始告警数量当作修复进度。
• 每条待修问题记录证据等级、是否沙箱复现、攻击路径、影响范围和现有防御结论。
• 对“不可达、不可利用、已缓解”的判定，要求可复核的依据；公告未说明是否自动关闭，需在流程中确认。
• 排序时使用业务关键系统和攻击路径，不要只按严重度标签排队。
• 修复 PR 必须人工评审；未来自动应用功能设有置信门，例如测试覆盖、范围边界和历史成功率，当前不要按自动合并设计。
• 接入前核对区域、账户、IAM 角色和代码源类型；价格与配额以官方定价页和用户指南为准，本文材料未提供。

结论#

Continuum 的 GA 把“AI 找漏洞”推进到“带证据的验证与待审修复”，但没有消除人工判断。对开发者而言，误报处理的关键是要求证据链：可达性、可利用性、复现、攻击路径和防御评估；修复排序的关键是把业务上下文放进队列。缺少这些上下文时，AI 只会更快地产生更多需要审查的 PR。误报率、漏报率、支持范围和定价仍待核实，不能从 GA 公告直接推导。