从“发现”到“确认可利用”：代码漏洞自动验证要补的六个环节

扫描器回答的是“这里可能存在一个问题”，而验证环节必须回答“在当前环境里，攻击者能否真的走到这里，走过去能拿到什么”。两者之间缺的不是更多扫描器，而是环境上下文、证据分档、可复现性、可解释的排序，以及一个可审的修复出口。AWS 在 2026 年 10 月 22 日宣布 AWS Continuum for code vulnerabilities 正式可用（GA），公告把这条链路拆成了几个可以借鉴的环节。AWS News Blog

先说材料边界：本文依据的是上述一篇 AWS 官方博客，属厂商自述；文中出现的控制台界面与数值是公告里的演示，不是独立复现结果；本文未执行任何代码，也未调用任何端点。公告提到的 User Guide 与定价页未给出可核验地址，相关细节标注为待核实。

一、把“扫描结果”和“已验证问题”拆成两层数据#

材料中，Continuum 控制台有两个并列的列表：Findings 列出环境中原始扫描器的发现，Issues 列出经过验证、按优先级排序的问题，每个 Issue 带严重性、状态、创建时间，并用一个 Contributing findings 区域列出它是从哪些原始发现构建出来的。

这是一个值得直接借用的建模建议（推断，非公告结论）：把 scanner finding 视为不可变的上游事件，把 issue 视为验证过程的产物，两者是多对一关系。这样做的收益是，换一套验证策略时不必改写原始数据；判定为误报时可以带证据回写结论，而不是删记录——删掉之后，再没人能复盘当初为什么判错。

二、可达性判断依赖环境数据，通用评分给不了#

公告称 Continuum 从代码仓库和 AWS 环境两类来源构建一张上下文图：在代码运行的账户和区域部署 collector，采集 AWS Config 资源与网络配置，用来判断漏洞能否经网络到达，以及从该位置还能到达什么。它从这张图中学习哪些系统属于业务关键、归属谁、服务之间如何依赖、各自触及哪些数据。

材料给出的理由是：通用严重性分数不告诉你攻击者实际能到达哪些资源，一个只用于开发的工具上的 critical，和一个离支付数据库只差一步的服务上的 medium，在分数上看起来一样。

边界要写清楚：公告只描述了 AWS 资源侧的采集方式。混合云、自建机房、其他云上的资产如何进入这张图，材料未说明，待核实。如果你的生产环境有一半不在 AWS，不能假定这套上下文覆盖完整。

三、给结论标证据等级，别只标“高危”#

按公告，Continuum 对每个 finding 结合代码与环境上下文分析后赋予一个证据等级，例如“由对漏洞代码路径的静态分析所证明”的判定；对其中可复现的发现，它在隔离沙箱中运行利用，并附上 PoC 代码与复现步骤。输出物包括攻击路径、支撑性源码分析和爆炸半径评估，此外还评估现有防御是否会检测并阻止这条已验证的路径。

给自建流水线的建议：至少分三档——静态路径可证、动态沙箱可复现、仅匹配到已知漏洞模式。三档对应不同的处置时限和不同的审批人。把它们统一标成“已确认”，等于把最弱的证据借用了最强的可信度。

下面是一个 issue 记录的结构示意，字段为本文设计，不对应 Continuum 的真实接口或数据格式，也未执行：

{
  "finding_ids": ["scanner-a:1234", "scanner-b:8871"],
  "evidence_level": "static_proven",
  "evidence_notes": "call path reachable without auth",
  "exploitability": "exploitable",
  "attack_path": ["internet", "cart-service", "tenant-data"],
  "blast_radius": "same_tenant_users",
  "defense_check": "no runtime control observed",
  "remediation": { "kind": "pull_request", "human_approval_required": true }
}

四、排序要排“离什么近”，不只是排分数#

公告称 Continuum 识别客户数据存储、支付流水线、认证服务这类高价值系统，再按每条攻击路径与这些系统的接近程度排序。控制台演示里的一个例子是：严重性 High，可利用性判定为 Exploitable，证据等级 Static proven，Likelihood 为 High（可被攻击者到达、无需认证、无需用户交互），Impact 为 Moderate（攻击者可修改业务数据，爆炸半径波及同一租户内的其他用户）。这段是厂商演示，用于说明字段含义，不应被当作性能或准确率数据引用。

可以借鉴的是把 Likelihood 与 Impact 分开写。合并成一个综合分之后，评审时很难质疑其中任何一半；分开写，安全团队可以说“我不同意这个可达性判断”，而不必推翻整个结论。

五、修复以可审的补丁落地，而不是自动合并#

对每个确认的问题，Continuum 生成修复（代码补丁、依赖升级或配置变更），并在已连接的仓库中开成 pull request，等待评审。公告明确：每个修复都需要人工批准，由人评审并合并；控制台也直接写明，生成了补丁不代表问题已经修复。PR 描述中携带与平台内相同的风险评估、修复摘要与证据，使评审者在 GitHub 界面内就能看到依据，不必切回安全平台。

关于自动化，公告的表述是“未来”：团队可以为特定修复类别积累信心，在通过测试覆盖率、范围边界、历史成功率等置信度门之后，让系统自动应用这些类别的修复。注意这层顺序——先有可度量的人类审批记录，才有资格谈自动放行。反过来做，等于用一个没有历史数据的阈值去决定什么可以自动上线。

六、接入前能确认的与不能确认的#

材料支持的事实：

• GA 时在 US East (N. Virginia) 与 US West (Oregon) 两个区域提供，其他区域未提及。
• 代码源支持 GitHub 集成或 Amazon S3 桶；S3 源要求桶与 Continuum 处于同一账户和同一区域，并通过 Continuum 承担的 IAM 角色授权访问。
• collector 部署在代码运行的账户与区域，环境需被授权使用它；该上下文为可选项。
• 扫描频率可配置，也可手动排队执行一次扫描。

材料未覆盖、需要另行核实的：具体定价与计费口径；支持的语言与仓库规模上限；扫描时延；沙箱隔离的实现方式与逃逸防护；GitHub 之外的代码托管支持。这些都不做推测。

七、按顺序补齐这条链路的清单#

1. 先定数据模型：原始发现与验证结论分表，保留多对一溯源关系。
2. 再定上下文授权：采集器和只读角色能读哪些账户、哪些资源类型，跨账户怎么授权，这些要在写规则之前定完。
3. 定义证据等级：每一档写明判定方法、产出物和对应的处置 SLA。
4. 划沙箱边界：允许复现哪些类型的问题、隔离到什么程度、复现产物保存多久。
5. 排序函数可解释：至少能回答“这条为什么排在前面”，且能被人推翻。
6. 修复出口设闸门：默认走 PR 加人工合并，把证据写进 PR 描述；自动应用留给有历史成功率的类别。

这套顺序里，最容易被跳过的是第二步和第三步——因为它们不产出任何可见的功能，却决定了后面所有结论的可信度。Continuum 的 GA 公告值得读的地方，也主要不是“AI 找漏洞”，而是它把验证结果拆成了可被质疑的字段：证据等级、攻击路径、爆炸半径、防御是否拦得住。字段可被质疑，结论才可被信任。