オープンソースのメンテナーたちは、自らの手に負える数をはるかに超える脆弱性報告を受け取るようになっており、その中で機械的な速度で稼働するAIシステムに由来する割合が増えつつあります。この春の約2カ月間、AnthropicのClaude Mythos Previewは23,000件を超えるオープンソースのコードパスを調査し、検証済みの発見事項をそれぞれの所有プロジェクトへと振り分けました。Tuskiraは、これらの発見事項がひとたび人間の手に渡った後どうなるのかを調査しました。
このプログラムは、約9週間にわたって数百件のプロジェクトに及ぶ1,596件の検証済み脆弱性を報告しました。6社の外部セキュリティ調査会社が、これらの発見事項をメンテナーに届く前にトリアージしています。
これらの発見事項は、精査に耐える内容でした。外部の調査会社が確認した対象のうち、真陽性率は90.8パーセントに達しており、この件数が実際のバグを反映していることを示しています。より曖昧なのは深刻度の判定です。Anthropicとベンダー側のレビュアーは、半数を大きく上回るケースで正確な深刻度について一致し、ほぼすべてのケースで1段階以内の差に収まりましたが、AIモデルの方がメンテナーよりも深刻度を高く評価する傾向が見られました。Anthropic自身は、確認済みの真陽性件数を影響度を測る一つの指標に過ぎないと位置づけ、より実態を示す遅行指標としてパッチ適用件数の方を重視しています。
問題が生じるのは開示後です。発見のペースは1日あたり検証済み脆弱性約25件に達した一方、修正が認定されたペースは1.5件に近い水準にとどまりました。Tuskiraはこの不均衡を約16.5対1という単一の比率にまとめています。
研究者たちは、この拡大し続ける未処理案件の山を「脆弱性デフィシット(vulnerability deficit)」と呼んでいます。プログラムは日々、メンテナーが目に見える形で解決している数をはるかに上回る発見事項を届けており、未解決案件の山は1日あたり約24件のペースで増え続けています。「企業は修復のペースだけでなく、発見のペースに合わせて動く必要があります」と同社は記しています。
メンテナー自身の対応は迅速です。報告への確認までの所要時間の中央値は1日の5分の1程度に収まっていました。しかし、確認と修復の間には大きな隔たりがあります。スナップショット時点で、開示された脆弱性のうちアップストリームでパッチが適用されていたのは約6パーセントにとどまり、この数字も一部のメンテナーが公表せずに修正を出荷しているケースがあることから、下限値として扱われています。
メンテナーの先には、もう一段の遅延が存在します。アドバイザリデータベースが修正情報を取り込むには時間がかかり、商用スキャナーが情報を更新するにも時間がかかり、さらに企業側が本番環境に反映する前にパッチを検証するにも時間がかかります。多くのプログラムは、アドバイザリが公開されて初めて本格的な対応に着手します。Mythosによる開示のうち、スナップショット時点で公開アドバイザリが存在しなかったものは約95パーセントに上りました。レポートの構造的な試算によれば、非公開の開示から企業側での実際のパッチ適用までの期間は、おおよそ3カ月から5カ月に及びます。
パッチの適用自体にも固有のリスクが伴います。メモリ安全性のバグに対する修正はタイミング挙動を変化させることがあり、より厳格な入力チェックはこれまで通っていたペイロードを拒否するようになることがあり、依存関係のアップグレードは連鎖的なバージョン変更を強いることがあります。一般的な言語パッケージの検証には通常2週間から6週間かかり、組み込み系、暗号関連、規制対象のコンポーネントではさらに長くなります。その期間中、脆弱性はすでに公開されており、悪用ツールが出回っている可能性がある一方で、本番環境は依然として旧バージョンのコードのまま稼働していることになります。
アップストリームでの一つの発見事項が、単一のアラートで済むことはまずありません。単一のImageMagickの欠陥は18件以上のダウンストリームパッケージのバリアントに波及することがあり、ディストリビューションの再ビルドはソースのみの修正であっても多数の個別フィードに伝播します。防御側にとって重要なのは、本番環境で到達可能なすべての影響インスタンスの数であり、これはアップストリーム側の集計から想像する以上に膨れ上がります。
Tuskiraが示す答えは、パッチ適用を意思決定の問題として捉え直すことです。同社のモデルは4つの問いに基づいています。脆弱なコードパスが本番環境で実行されているか、誰がその公開されたインスタンスに到達できるか、環境に実際の悪用の兆候が見られるか、そして既存の制御機構がすでにその悪用を防いでいるか、という4点です。これらの答えによって、各発見事項は「緊急対応レーン」「段階的対応レーン」「対応記録付きの先送り」のいずれかに振り分けられます。
ある実例が、このポイントをよく示しています。nginxの重大な欠陥は、一見すると1,200インスタンスで構成される環境全体を脅かすように見えるかもしれません。しかし、次々とフィルタをかけることで、その対象範囲は急速に絞り込まれていきます。コンパイル済みモジュール、有効化された機能、脆弱な設定、そして外部への公開状況を考慮すると、最終的に残るのは、外部に公開されており、認証機構がなく、Webアプリケーションファイアウォールも導入されていない3インスタンスだけです。緊急対応はこの3件に振り向けられます。残りのインスタンスは、対応理由を記録しながら、より緩やかなレーンで処理が進められます。
このパターンは、単一のプログラムの枠を超えて広がっています。OSS-Fuzzは9年間の運用の中で13,000件を超える脆弱性を記録してきましたが、Mythosはそのごく一部の期間で、この蓄積の相当な割合に達しています。AIによる発見の取り組みは今後さらに増えていくと見られており、これはエコシステム全体における発見ペースがさらに加速する可能性を示唆しています。
CVEフィードは今や後追いでしか届かなくなっており、有用なシグナルはそれよりも早い段階、すなわちアップストリームのコミットや透明性ログの変更、そしてアドバイザリでクレジットされるセキュリティ企業の動きの中に現れます。こうした早期のシグナルを読み取り、どの依存関係が本番環境で稼働しているかをあらかじめ把握しておくことが、今やこの業務の中核になりつつあります。
翻訳元: https://www.helpnetsecurity.com/2026/07/02/open-source-ai-patch-gap/
