AWS Uses AI Agents to Triage Kernel CVEs, Keeps Human Review
AWS engineers at the Linux Plumbers Conference described how their EC2 kernel team filters out roughly 70% of kernel CVEs with scripts, then hands the rest to AI agents that produce triage tables using the source tree, configs and threat models, with human review still required. The team also advocates moving to newer LTS kernels to avoid accumulating unbackported fixes on old branches.
Related Entities
Full Report
亚马逊云科技的工程师介绍了负责维护 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 分数，因为这些分数并不针对其具体环境。
“我们实际上只是把它当作一个非常高级的分类器。” Dylan Johnson
通常会有两名工程师审核这张表格。根据演示文稿，智能体处理每个 CVE 大约需要 3.4 秒，而人工处理则需要数分钟。Bouron 表示，审查现在已成为整个流程中最慢的步骤，但团队并不打算取消它。
“我们不希望把整个安全体系都押在一个大语言模型智能体的输出上。” Justinien 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 列为组织自建云时需要承担的工作，并写道：“专注于真正能为客户创造业务价值的事情。”
亚马逊云科技尚未发布这些工具。当被问及是否会将其开源时，Johnson 表示，团队希望探索共享过滤工具的可能性。他也承认，与通用发行版相比，亚马逊云科技面向内部用户的环境更容易禁用某些功能。
原文链接：
https://www.infoq.com/news/2026/10/aws-ai-agents-linux-kernel-cves/