OSプラットフォーム
AI支援によるバグハンティングが、防御側のパッチ適用速度を上回るペースで脆弱性を積み上げており、Canonicalはリリース速度の引き上げに踏み切りました
Canonicalは、Ubuntuのカーネルリリースを週1回のペースに加速させます。AI支援によるバグハンティングが、防御側を膨れ上がり続けるCVEの山に埋もれさせているためです。
Ubuntuの開発元であるCanonicalはカーネルのStable Release Updates（SRU）の配信方法を全面的に見直しており、現行の4週間の通常サイクルと2週間のセキュリティサイクルを、重複する2週間サイクルに置き換えます。これにより毎週カーネルリリースが行われることになります。
Canonicalによれば、この変更が必要な理由は、報告される脆弱性の数が爆発的に増加しているためであり、その一因はAIにあるとしています。パッチ待ちの列のどちら側に立つかによって、これを功績と見るか、それとも問題と見るかは分かれるところでしょう。
Canonicalは水曜日、「大規模言語モデル(LLM)や専門特化型のAIエージェントは、バグ発見のプロセスを、手作業で時間のかかるものから、高度に自動化されたエンジンへと変貌させました」と述べています。
CVEの急増はAIだけが原因ではありません。上流のLinuxカーネルコミュニティは2024年にCVE採番機関(CNA)となり、稼働中のシステムに影響を及ぼしうるほぼすべてのカーネルの欠陥にセキュリティ上の意味があり得るという考えのもと、数千件のバグに識別番号を割り当て始めました。
この2つの要因が重なった結果、Linuxベンダーが対処すべきCVEは大幅に増加しました。Canonicalによれば、積み上がったバックログに対応するにはリリースの高速化が不可欠であり、脆弱性が公表されてからパッチ済みカーネルがユーザーに届くまでの期間を縮める必要があるとしています。
新体制では、各SRUサイクルの期間は2週間のままですが、新しいサイクルが毎週開始されます。1週目はパッチの統合、カーネルパッケージの準備・ビルド、そして重大な問題が発生しないことを確認する基本チェックに充てられます。この段階が終わる頃には、リリース候補がUbuntuの-proposedポケットに公開されます。
2週目は、ハードウェア認証、ディストリビューションへの統合、リグレッションテストといった、より重い作業に充てられます。これが完了すると、カーネルがリリースされます。このテストが進行している最中に次のサイクルが始まるため、Canonicalは翌週にはまた新しいカーネルを公開できることになります。
それでも悠長すぎると考える管理者向けに、より速い経路も用意されています。
パッチ適用の遅れに特に敏感な組織は、1週目が終わった時点で-proposedポケットからリリース候補を取得し、自らの受け入れテストを実施できます。Canonicalはそのトレードオフを明確にしています。こうしたユーザーはより早く修正にアクセスできる一方で、同社が広範な認証テストを完了する前の段階でそれを利用することになります。
これにより、顧客が自らテストの一部を引き受ける意思がある限り、カーネルのCVE修正を1週間以内に利用可能にすることができます。
Canonicalはまた、脆弱性の公表からパッチ提供までの間、顧客の露出をできるだけ減らしたい考えです。可能な場合は安全な回避策を提供し、それが存在しない場合は一般的な強化策を推奨することで、公表から24時間から48時間以内にシステムを同社が言うところの「防御可能で、より安全な状態」に置くことを目指しています。
これらの対策はパッチ適用に取って代わるものではなく、修正がリリースプロセスを経て届くまでの間、管理者にただ指をくわえて待つよりましな手段を与えることを意図したものです。
結果として、カーネルのリリーススケジュールはかなり慌ただしいものになりますが、人間がパッチを当てるよりも速くバグを見つけるためにますます多くの機械が動員されている以上、それは避けられないことなのかもしれません。
AIはあらゆる人の仕事を楽にするはずでした。Ubuntuのカーネルチームには、一言物申したいことがあるかもしれません。®
