Azulの2026年AI脆弱性ギャップレポート、企業のパッチ適用がAIの脅威に後れを取っていると指摘

Azulの2026年AI脆弱性ギャップレポートは、AIを活用する攻撃者の速さについてセキュリティ責任者が想定する時間と、組織が修正プログラムを適用するのに必要とする時間との間に隔たりがあることを明らかにしている。米国のセキュリティ責任者300人を対象とした調査では、69%が攻撃者は3日以内に実際に機能するエクスプロイトを作成できると回答した一方、44%は本番環境全体の重大な脆弱性にパッチを適用するのに4日以上かかると答えた。

報告書で最も注目すべき調査結果は、回答者がこうした遅延と結び付けている経験だ。85%が、パッチ適用の遅れに起因するインシデント、インシデントの疑い、またはニアミスを報告した。この数字は回答者が報告した経験を示すもので、独立して検証された侵害率ではない。また、これらの事象がAIによって引き起こされたことを立証するものでもない。

Azulの委託を受けてCensuswideが実施したこの調査は、大規模なJava導入環境を持つ組織に焦点を当てている。調査が示すより広いメッセージは、運用面に関するものだ。脆弱性を認識することは出発点にすぎない。修正プログラムはテストを通過し、影響を受けるシステムに届き、チームが全容を把握できていない可能性のある環境全体のリスクを解消しなければならない。

2つの時計は一致しない

この調査では、攻撃者について責任者が抱く予想と、自組織の導入能力とを分けて示している。

• 69%は、AIを活用する攻撃者が3日以内にエクスプロイトを作成できると考えており、そのうち22%は24時間未満と見積もっている。
• 56%は、本番環境全体に重大なパッチを3日以内に適用できると回答した。内訳は、24時間未満が13%、1～3日が43%。
• 44%はそれ以上の時間を要し、32%は4～6日、12%はさらに長くかかると回答した。

これらは調査回答の分布であり、同じ脆弱性をめぐって攻撃者が特定の組織と競い合う状況を測定したものではない。この差は備えに関する懸念を裏付けるものだが、すべての企業に当てはまる正確な3日間のリスク期間と解釈すべきではない。

1日の基準で見ても、同じ不均衡が表れている。攻撃者がそれほど速く動くと予想する回答者は22%であるのに対し、その時間内に修正プログラムを適用できると答えた組織は13%だった。一方、59%は、セキュリティ体制を変更していないものの、AIを活用した攻撃ツールによるリスクが高まっていると認識している。

テストが遅延の大きな要因に

調査対象組織の58%では、Javaランタイムの更新をテストすることで、パッチ適用サイクルに4日以上が加わっている。このうち36%は4～6日、22%は1週間以上かかると回答した。また、33%は1～3日、9%は24時間未満と回答した。テストを省略したと答えた回答者はいなかった。

ランタイムの変更は多くのアプリケーションに影響する可能性があるため、テストには実務上の目的がある。セキュリティ更新によって重要なサービスに支障が出れば、新たな運用上の問題が生じるからだ。報告書は、更新範囲も負担の一因だと指摘する。OpenJDKの四半期ごとのフルリリースには、脆弱性の修正とともに、セキュリティ以外の変更が含まれることがある。

Azulは別途、6年を超える期間にわたるOpenJDKの四半期更新26件を評価し、そのうち6件を重大なデグレードを引き起こしたものに分類した。この23%という数字はベンダーによるリリースの評価であり、個々の顧客のアプリケーションがどれほどの頻度で動作しなくなるかを示す調査推計ではない。

パッチ適用を迅速化するうえで大きな障壁として挙げられたのは、広範なテストが44%、影響を受けるシステムの複雑さや老朽化が40%、既知の脆弱性に対する可視性の不足が36%だった。ベンダーによるパッチ提供の遅れは25%が挙げた。この傾向は、修復に伴う課題の多くが、企業自身の導入プロセスにあることを示している。

インシデント報告と資産把握の不足は、分けて見る必要がある

55%が、パッチ適用の遅れに起因するインシデントを確認したと回答し、53%がニアミスを報告した。回答者は複数の選択肢を選べたため、これらの数字は重複しており、合算すべきではない。より広く報じられている85%という数字には、インシデントの疑いも含まれる。

この調査は、これらの事象すべてがJavaの脆弱性に関係していたことを立証するものではない。参加者はJavaを大規模に利用する組織に所属しているが、調査ではソフトウェアのパッチ適用全般に関する質問に加え、Javaランタイムに特化した質問も行われている。

資産の把握も課題の一つだ。本番環境のJavaランタイム資産の少なくとも90%に最新のセキュリティパッチが適用されていると答えたのは、わずか19%だった。つまり、81%はこの基準に達していないということであり、81%の組織に最新のランタイムが一つもないという意味ではない。約5分の1は、資産の半分以下しか最新の状態にないと回答した。

これとは別に、51%が、組み込み型、レガシー、管理対象外のものを含む重要なJavaランタイムについて、可視性が一部に限られる、または不十分だと認めている。パッケージ化されたアプリケーションやコンテナ内にある脆弱なランタイムを見つけるのは、一元管理されたインストール環境を特定するより難しい場合がある。導入プロセスが一度も到達しないシステムのリスクを、パッチで解消することはできない。

Azulの技術がこの議論にもたらすもの

Azulのセキュリティ更新サービスでは、あらかじめ安定化されたOpenJDKのベースラインを維持し、対象リリースへの更新をセキュリティ修正に限定している。同社は四半期ごとの更新、対象を絞った月次更新、定例外の更新を提供し、緊急修正を適用する際に企業が評価しなければならない無関係な変更を減らすことを目指している。

これは、変更管理を不要にすることとは異なる、より限定的な技術的介入だ。コード変更を抑えれば検証の範囲を狭められる一方、アプリケーション固有の確認、デプロイの責任者の明確化、ロールバックの準備は依然として重要である。Azulは本レポートのスポンサーであり、レポートが測定する問題に対処する製品を販売している。

同社のJava資産管理ツールと脆弱性管理ツールは、ワークフローのもう一方の側面、すなわち実行環境、バージョン、脆弱性への曝露状況を特定し、新たに公表された脆弱性情報を影響を受けるシステムに対応付ける作業に対処する。本レポートには、調査対象組織がこれらの製品を導入することでどの程度改善するかを示す、管理された比較結果は含まれていない。

「私たちの調査によると、セキュリティリーダーは脅威を理解しています。もはや課題は認識ではなく、実行です」と、Azulの共同創業者兼CEO、Scott Sellers氏は述べた。

パッチ適用の意向を測定可能なプロセスに変える

今後1年間に向けて、32%がリスクへの曝露を減らすための最優先戦略として、より迅速かつ頻繁なパッチ適用を挙げている一方、26%はソフトウェアと実行環境の資産管理の改善を重視している。また、17%はパッチ適用の迅速化ではなく、検知と対応を優先している。

この調査は、脆弱性情報の公表から修復までの全過程を追跡することの重要性を示している。具体的には、どのシステムが影響を受けるのか、誰がその管理責任を負うのか、どのようなテストが必要なのか、そして修正が実際に本番環境に適用されたのかを把握することだ。期限が役立つのは、関連するシステム全体で作業の完了をチームが確認できる場合に限られる。

米国の調査結果は、2026年8月3日から7日にかけて、従業員数が少なくとも1,000人で、Java/JVMを本番環境で大規模に使用している組織のセキュリティリーダーを対象に実施した調査に基づく。これらは対象を定めた集団から得られた自己申告の回答であり、企業全体を網羅する全数調査でも、エクスプロイトの開発を直接測定したものでもない。

調査結果と方法論の詳細は、2026年版AI脆弱性ギャップレポートに記載されている。そこから最も明確に読み取れるのは、パッチ適用の迅速化と実行環境の可視化を同時に進める必要があるということだ。影響を受けるすべてのデプロイを組織が特定できず、更新が適用されたことも確認できないのであれば、迅速な修正の価値は限られる。