亚马逊云科技内核CVE分诊：AI 处理3.4秒，人工审查仍留5%误差

亚马逊云科技的工程师讲了维护 EC2 基础设施 Linux 内核的团队怎么处理内核 CVE：自动化过滤器、AI 智能体和人工审查三样并用。团队同时主张往较新的长期支持（LTS）内核迁移，理由是旧分支持续堆着从未被反向移植的修复。

相关演讲由 Dylan Johnson 和 Justinien Bouron 在本月早些时候于布拉格举行的 Linux Plumbers Conference 上发表。Johnson 在演讲录像开头解释，这支团队维护的是 EC2 基础设施内部使用的内核，与 Amazon Linux 以及客户在虚拟机里跑的内核彼此独立。

Linux 内核项目 2024 年 2 月成为 CVE 编号授权机构。在这之前，团队每周大约收到两个内核 CVE；那之后涨到每天约 16 个，2026 年 8 月 15 日一天就发布了 848 个。Linux 内核 CVE 文档的说法是，项目无法知道特定系统怎么使用内核，哪些 CVE 与自己相关，只能由用户自行判断。

流程第一阶段不用 AI。Bouron 解释说，内核 CVE 记录以 JSON 格式发布，里面列出受影响的版本和源文件；如果内核版本不在受影响范围内，或者列出的文件没有一个被构建进镜像，脚本就把这条 CVE 丢掉。在亚马逊云科技的环境里，这一步能筛掉约 70% 的 CVE。不过 Bouron 表示，这个比例在很大程度上取决于内核配置。

剩下的 CVE 交给 AI 智能体。它会拿到亚马逊云科技的内核源代码树、各平台的配置、环境与威胁模型说明，以及严重程度评定标准，然后生成一张表格，记下受影响的子系统、漏洞类型和攻击途径。Bouron 说，团队会忽略 CVSS 分数，因为这些分数并不针对他们自己的具体环境。

Johnson 对这套智能体的定位是：“我们实际上只是把它当作一个非常高级的分类器。”

Dylan Johnson

表格通常由两名工程师审核。演示文稿给出的数据是：智能体处理每个 CVE 约需 3.4 秒，人工处理则要数分钟。Bouron 表示，审查眼下是整个流程中最慢的一步，但团队不打算把它取消。

被问到准确率时，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 个。这些数字分别针对各个分支，并不表示其中有多少会影响到亚马逊云科技自己的内核。

自己动手反向移植修复也有风险。Bouron 指出，CVE 记录通常只列出最终完成修复的那个提交；一旦漏掉必要的前置提交，就算把列出的修复打上，系统仍可能带漏洞。

内核升级这块，亚马逊云科技已经把节奏压短了。Johnson 说，4.19 到 5.10 的迁移前后耗了约两年，时间从启动移植一直算到生产环境全量铺开；再往后那一轮缩到约一年，换到 6.18 只用了约六个月。5.10 升 6.12 时，有 43% 的跟踪问题最后是在用户空间里解决的，因为这些工作负载还指着老内核的行为跑。Johnson 表示，往后团队会整年不间断地测稳定版内核，每出一个新 LTS 版本，就把整个服务器集群迁过去。

Microsoft 的 Azure Linux 团队在同一场会议上介绍了一条类似的流水线。他们的分诊结论来自一张规则表，AI 只负责为它提供输入建议。团队也用智能体执行反向移植，并报告称构建和测试反馈循环把成功率从约 50% 提高到 80%。InfoQ 曾于 2025 年 10 月报道 Google DeepMind 的 CodeMender，后者专注编写修复；其公告称，每个补丁提交至上游之前都会由人类研究人员审查。

Process Focus 首席技术官 Berend de Boer 在 LinkedIn 上评论了运行云基础设施需要做的工作。他把宿主机补丁和 Linux CVE 列为组织自建云时要承担的事项，并写道：“专注于真正能为客户创造业务价值的事情。”