アマゾン ウェブ サービス (AWS) のエンジニアが、EC2 インフラストラクチャの Linux カーネルを保守するチームがカーネル CVE をどのように処理するかについて説明しました。このプロセスでは、自動フィルター、AI エージェント、人間によるレビューが組み合わされます。またチームは、古いブランチは決してバックポートされない修正を収集するため、新しい長期サポート (LTS) カーネルに移行する必要があると主張しています。
Dylan Johnson 氏と Justinien Bouron 氏は、今月初めにプラハで開催された Linux Plumbers Conference で講演しました。録画の冒頭で、ジョンソン氏は、チームが EC2 インフラストラクチャ内で使用されるカーネルを保守していると説明しました。これは、Amazon Linux および顧客が仮想マシンで実行するカーネルとは別のものです。
2024 年 2 月にカーネル プロジェクトが CVE 番号付け機関となった後、チームは 2024 年以前は 1 週間に約 2 件、その後は 1 日あたり約 16 件のカーネル CVE を確認し、2026 年 8 月 15 日には 848 件が公開されました。カーネル CVE のドキュメントには、特定のシステムがカーネルをどのように使用するかをプロジェクトが把握できないため、ユーザーはどの CVE を適用するかを決定する必要があると記載されています。
AWS のプロセスの最初の段階では AI は使用されません。 Bouron 氏は、カーネル CVE レコードが JSON で公開され、影響を受けるバージョンとソース ファイルがリストされていると説明しました。カーネルのバージョンが影響を受ける範囲外の場合、またはリストされたファイルがイメージに組み込まれていない場合、スクリプトは CVE を破棄します。 AWS の環境では、これにより CVE の約 70% が削除されますが、Bouron 氏は、この数字はカーネル構成に大きく依存すると述べました。
残りの CVE は AI エージェントに送られます。 AWS のカーネル ソース ツリー、各プラットフォームの構成、環境と脅威モデルの説明、および重大度ルーブリックを受け取ります。エージェントは、影響を受けるサブシステム、脆弱性の種類、および攻撃ベクトルを記録するテーブルを作成します。 Bouron 氏は、CVSS スコアはその環境に固有のものではないため、チームは無視していると述べました。
「私たちはそれを非常に派手な分類器として実際に使用しています。」
ディラン・ジョンソン
通常、2 人のエンジニアがテーブルをレビューします。スライドによると、エージェントは CVE ごとに約 3.4 秒かかりますが、人間の場合は数分かかります。ブーロン氏は、レビューは現在プロセスの中で最も遅いステップであり、チームはそれを削除するつもりはないと述べた。
「私たちは、セキュリティ体制全体を LLM エージェントの出力に依存したくありません。」
ジャスティニアン・ブーロン
正確性について尋ねられたとき、ブーロン氏はエージェントの決定の 5% から 10% に問題があると推定しました。これは非公式な試算であり、講演では正式な評価については述べられていない。
チームはまた、該当する CVE の数を減らすために、必要のないカーネル機能を無効にしました。ブーロン氏は、このアプローチを「一見難しい」と呼んだ。スライドには 32,000 を超える構成オプションがリストされており、間違った構成オプションを削除すると、数か月後にバグやパフォーマンスの低下が発生する可能性があります。
チームのデータはまた、古い LTS ブランチは後で修正を受け取り、より多くの未修正の CVE を保持していることを示しています。調査した 6 つのブランチすべてに影響を与える CVE の場合、メインラインの修正から LTS リリースまでの時間の中央値は、Linux 5.10 では 31.8 日、6.18 では 18.1 日でした。 9 月 16 日、5.10 では 1,709 件の既知の CVE が未修正でしたが、6.18 では 229 件でした。これらは各ブランチの数であり、AWS 自体のカーネルに影響を与える数を示すものではありません。
社内での修正のバックポートには、それ自体のリスクが伴います。 Bouron 氏は、CVE レコードには最終的な修正コミットのみが指定されることが多いと指摘しました。前提条件のコミットを怠ったチームは、リストされた修正を適用した後も脆弱なままになる可能性があります。
AWS は独自のアップグレードを短縮しました。 Johnson 氏は、4.19 から 5.10 への移行には、移植作業の開始から完全な運用展開までに約 2 年かかったと述べました。次のアップグレードには約 1 年かかり、6.18 への移行には約 6 か月かかりました。 5.10 から 6.12 へのアップグレード中に、ワークロードが古いカーネルの動作に依存していたユーザー空間で、追跡された問題の 43% が修正されました。ジョンソン氏は、チームは今後、年間を通じて安定したカーネルをテストで実行し、新しい LTS リリースが登場するたびにフリートを移動する予定であると述べた。
Microsoft の Azure Linux チームは、同じカンファレンスで同様のパイプラインについて説明しました。トリアージの判定はルール テーブルから得られ、AI はルール テーブルへの入力を提案するだけです。チームはバックポートにエージェントを使用し、ビルドとテストのフィードバック ループにより成功率が約 50% から 80% に向上したと報告しました。 InfoQ が 2025 年 10 月に取り上げた Google DeepMind の CodeMender は、修正の作成に重点を置いています。その発表では、上流に提出される前に人間の研究者がすべてのパッチをレビューすると述べられています。
Process Focus の CTO である Berend de Boer 氏は、クラウド インフラストラクチャの実行に伴う作業について LinkedIn でコメントしました。同氏は、組織が独自のクラウドを構築する際に取り組む作業として、ホストのパッチ適用と Linux CVE を挙げた。 「あなたのビジネスが顧客にとって価値のあるものになることに焦点を当ててください」と彼は書いています。
AWS はツールをリリースしていません。オープンソース化について質問されたジョンソン氏は、チームはフィルタリングツールの共有を検討したいと述べた。同氏はまた、AWS の内部ユーザーの方が汎用ディストリビューションよりも機能を無効にするのが簡単であることも認めた。
