漏洞扫描自动化之后，人工验证环节怎么保留：AWS Continuum 的责任切分与复核证据

简短回答：AWS Continuum 把“发现—验证—提议修复”这一段自动化了，但默认把最后一步留给人——每个修复以 pull request 形式提出，需要审阅并合并后才进入代码库。所以人工验证并没有被取消，它被压缩到“合并前的证据复核”这一环。要保住这一环的质量，需要先分清三件事：服务负责证明什么，团队负责判断什么，复核时到底看哪些证据。

一、责任切分：谁证明，谁决定#

根据 AWS 官方博客的说明，Continuum 会确认哪些发现（finding）在特定环境中确实可利用，按业务影响排序，并为每个问题提出修复；修复以可自动化的补丁或仓库中的 PR 交付。AWS News Blog 同时写明：每个修复都从“Continuum 提议、人批准后才发布”的模式开始。把这句话拆开，责任边界大致如下。

这张表里最容易混淆的是“验证”和“决定”。服务做的是把“这个发现到底能不能被利用、攻击者能走到哪”从猜测变成带证据的判断；团队做的是在业务语境下决定这次改动值不值得现在上线。两者不能互相替代。

二、复核证据由哪几层构成#

博客里反复强调的一点是：Continuum 交付的不是一个风险分，而是攻击路径、支撑的源码分析和影响半径评估。对人工复核来说，这些材料可以分成五层来看。

• 证据等级（evidence level）：例如由静态分析证明的漏洞代码路径（博客示例中显示为 Static proven），并伴随验证运行状态。它是分级结论，不是“已验证/未验证”的二元开关，读的时候要看它停在哪一级。
• 可复现证明：对能复现的发现，沙箱运行结果、PoC 代码与复现步骤会一并附上。复核时要确认复现前提与自己的运行环境是否一致。
• 攻击路径与影响半径：是否可从网络到达、是否需要认证、是否需要用户交互，以及攻击者能读到还是能改业务数据、波及范围有多大。博客示例中把可利用性判为 Exploitable、可能性 High、影响 Moderate，并说明影响半径可达同租户的其他用户。
• 防御评估：服务还会评估现有防御是否会检测并阻断这条已验证的路径。这一层直接影响“现在修还是排期修”的判断。
• 原始发现溯源：控制台的 Contributing findings 会列出该问题由哪些扫描器发现构成；Findings 标签保留环境的原始扫描输出。问题（issue）是加工后的结论，发现（finding）是输入，两者不应混为一谈。

三、PR 作为复核与审计的载体#

把复核放在 PR 里，而不是另建一套工单，是这套流程比较实用的地方。博客说明，PR 描述会携带与控制台相同的风险评估、修复摘要和证明，审阅者在 GitHub 中不必跳回控制台就能看到证据。示例中 PR 标题为“Continuum fix”，改动 4 个文件、新增 50 行、删除 24 行——这是 AWS 作者在控制台演示中的例子，不是本文的实测结果。

这样一来，合并动作本身就留下了“谁在什么证据下批准了什么改动”的记录。但仅有合并记录还不够，建议在 PR 中补一条人工结论，说明批准依据与遗留风险。下面是记录模板示例，属建议做法，不是产品内置功能：

复核结论（示例模板，未执行）
- 证据等级：Static proven / 沙箱复现：已附 PoC 与步骤
- 攻击路径：可从网络到达，无需认证，无需用户交互
- 影响半径：可修改业务数据，波及同租户其他用户
- 现有防御：未确认可阻断
- 改动范围：4 个文件，+50 / -24（以实际 diff 为准）
- 测试情况：待填写（本地/CI 结果）
- 决定：合并 / 退回 / 拆分为后续任务
- 遗留风险与跟进人：待填写

四、落地时的几个操作建议#

1. 区分问题与发现：只对已验证并排序的问题排期，把原始发现当作输入而不是待办列表。扫描器每天产生大量发现，其中不可达、不可利用或已被运行时控制缓解的占相当比例，这是博客给出的背景判断。
2. 先定义“证据充分”的门槛：例如要求有沙箱复现，或至少达到静态证明级别；对只有风险分、没有路径证据的问题，走另一条低优先通道。
3. 管理扫描节奏：控制台提供 Configure scan frequency 与 Queue scan，可按需调整或手动触发。环境是按时计划扫描的，复核能力要与之匹配，否则问题会积压。
4. 为未来的自动应用预留门槛：博客提到未来可以按修复类别逐步建立信心，在测试覆盖、范围边界、历史成功率等置信门通过后允许自动应用。这仍是未来能力，现阶段不要把流程设计成“默认自动合并”。
5. 保留配置变更记录：environment 的代码源、上下文源、collector 与“是否生成修复补丁”等设置会影响证据质量，改动时应同步记录。

五、边界与待核实#

按博客，Continuum for code vulnerabilities 目前在 US East (N. Virginia) 和 US West (Oregon) 两个区域提供；定价指向 pricing page，本次材料未给出具体数字，价格待核实。自动应用修复的置信门机制，材料表述为未来能力，尚不可用。

本次材料未涉及以下细节，实际选型时需另行核对：支持的语言与仓库类型范围、代码源除 GitHub 集成与 S3 桶外是否还有其它形式、沙箱隔离的实现方式、误报率的统计口径、服务等级承诺，以及与其它 AWS 安全服务的联动方式。这些都应查用户指南或咨询支持渠道确认，本文不作推断。

回到标题的问题：漏洞扫描自动化之后，人工验证保留在“合并”这一步，但它的质量取决于证据是否被结构化地摆到审阅者面前。把证据等级、复现材料、攻击路径、防御评估和原始发现溯源当作 PR 的必读项，再把人签字的位置固定下来，自动化才不会变成“看起来修过了”的错觉。