亚马逊云科技谈CVE处理：AI分诊提效，人工审查不可省

亚马逊云科技的工程师介绍了负责维护EC2基础设施Linux内核的团队如何处理内核CVE，流程结合自动化过滤器、AI智能体和人工审查。Dylan Johnson和Justinien Bouron本月早些时候在布拉格举行的Linux Plumbers Conference上发表了相关演讲。Johnson解释说，该团队维护的是EC2基础设施内部使用的内核，与Amazon Linux以及客户在虚拟机中运行的内核彼此独立。

Linux内核项目于2024年2月成为CVE编号授权机构。在此之前，该团队每周大约收到两个内核CVE；此后增至每天约16个，2026年8月15日当天更是发布了848个。处理流程的第一阶段并不使用AI：内核CVE记录以JSON格式发布，列出受影响的版本和源文件，若内核版本不在受影响范围内，或列出的文件都未被构建进镜像，脚本就会丢弃该CVE。在亚马逊云科技的环境中，这一步可排除约70%的CVE，但该比例在很大程度上取决于内核配置。

其余CVE交给AI智能体。智能体会收到内核源代码树、各平台配置、环境与威胁模型说明以及严重程度评定标准，随后生成一张记录受影响子系统、漏洞类型和攻击途径的表格。团队会忽略CVSS分数，因为这些分数并不针对其具体环境。Bouron称，智能体处理每个CVE约需3.4秒，而人工处理需要数分钟，审查现已成为流程中最慢的步骤，但团队并不打算取消它。“我们不希望把整个安全体系都押在一个大语言模型智能体的输出上。”

当被问及准确率时，Bouron估计智能体作出的决策中约有5%到10%存在问题，这只是非正式估计，演讲中没有介绍正式评估。团队还禁用了不需要的内核功能以减少适用的CVE数量，Bouron称这种方法“看似简单，实则困难”，演示文稿列出了超过3.2万个配置选项，移除错误选项可能导致数月后才出现的缺陷或性能回退。

团队数据还显示，较旧的LTS分支获得修复更晚且包含更多未修复CVE。对于同时影响所研究全部六个分支的CVE，从主线修复到LTS版本发布的时间中位数在Linux 5.10上为31.8天，在6.18上为18.1天；截至9月16日，5.10中有1709个已知CVE尚未修复，6.18中为229个。自行反向移植修复也有风险，CVE记录通常只列出最终完成修复的提交，若遗漏必要的前置提交，系统仍可能存在漏洞。亚马逊云科技已缩短内核升级周期，从4.19升级至5.10约花两年，下一次约一年，迁移到6.18约用六个月。