新たな調査によると、AIによって脆弱性の発見が急速に加速している一方で、企業組織はその急増に対して一般に考えられているよりもうまく対応できていることが分かりました。
その鍵となるのは、発見事項を迅速に検証し、リスクに優先順位を付け、利用可能な修正を本番環境に反映させる能力です。
ソフトウェアサプライチェーンセキュリティ企業のEchoは最近、250のオープンソースコンテナプロジェクトにまたがる約4万件のCVEのライフサイクルを分析しました。この分析では、自社プラットフォームの1年分のテレメトリデータ、80名を超えるセキュリティリーダーへの調査結果、そしてAnthropicのClaude Mythosに関する独自分析を活用しています。
AIが加速させたのは方程式の片側だけ
報告書「Mythos Readiness Report」で詳述されている調査結果は、AIが脆弱性の発見とエクスプロイト開発をどのように変容させつつあるかを示しています。これはセキュリティチームがこの1年間、身をもって経験してきたことでもあります。
月間のCVE公開件数は、2024年6月の3,173件から2026年6月には7,765件へと、2年間で145%増加しました。これはCVEプログラムの対象拡大に加え、AI支援による脆弱性発見の増加が要因となっています。年間ベースで見ると、CVE公開件数は急増し、2023年の30,949件から2025年には49,979件に達しており、これまでの推移から見て2026年はこの数字すら上回る見込みです。
Echoは、最も頻繁に利用されるコンテナベースイメージであるNodeとPythonでも同様の傾向を発見しました。2026年1月から6月にかけて、Nodeベースイメージの既知CVE件数は約16,000件から70,000件へと338%急増し、Pythonについても同期間に17,500件から45,000件へと増加しました。
「脆弱性は今やマシンスピードで発見される一方、修復作業は依然としてほぼ手作業のままです」とEchoは報告書に記しています。「つまりAIは方程式の片側を劇的に加速させましたが、もう片側はまだそれに追いついていないのです」
Echoの調査によると、Claude Mythosはエクスプロイト開発の経済性を根本から変え、研究者や攻撃者が既知の脆弱性に対する実働するエクスプロイトを1日足らず、しかも2,000ドル未満のコストで開発できるようにしてしまいました。
セキュリティチームが直面する、より複雑な現実
生のデータだけを見れば、組織にとって状況は急速に制御不能になりつつあるように思えるかもしれませんが、Echoは楽観できる材料もいくつか見出しています。
まず、AIツールが発見する脆弱性の多くはまだ検証されておらず、実際には当初想定していたよりも深刻度が低いと判明するケースが少なくありません。例えば、Echoが調査した期間中、Mythosは約23,019件の潜在的な脆弱性を発見しましたが、外部検証、つまり独立した第三者によるチェックを受けたのは10%未満にとどまりました。Anthropicが公開した27件の脆弱性のうち、Mythosは当初8件を「クリティカル」の深刻度に分類していました。しかし研究者がこの8件を独立して精査した結果、クリティカルの評価が維持されたのは1件のみでした。
「最大の驚きの一つは、Mythosへの備えが実は想定していたよりもはるかに達成しやすいということでした」と、Echoの最高技術責任者(CTO)兼共同創業者であるEylam Milner氏はDark Readingに語っています。「Mythosは実在する脆弱性を発見するのは非常に得意ですが、それらの脆弱性が実際にどれほど深刻かを判断する精度についてはかなり劣ります。これは、どこに注意を向けるべきかを判断しようとするセキュリティチームにとって非常に重要な違いです」
同氏によれば、組織は脆弱性管理に関する取り組みを一から見直す必要はなく、むしろ膨大な数の脆弱性を迅速に検証し、何が重要かを見極めた上で効率的に修復するためのインフラ整備に注力すべきだといいます。
自ら招いたリスク露出?
Echoはまた、組織が直面している脆弱性管理上の課題の少なくとも一部は、組織自身の行動によって生じていることも明らかにしました。例えば、Echoが調査した脆弱性のうち実に89%には修正が存在していました。深刻度がクリティカルおよび高（High）の脆弱性に限れば、その割合はさらに高くなります。それにもかかわらず、修正可能な脆弱性の実に40%近くが6か月以上にわたって未解決のまま放置されていたことが判明しました。
この数字が示しているのは、実際の最大の問題は修正の有無ではなく、その修正を本番環境に反映させることにあるとMilner氏は指摘します。「修正が存在するからといって、それを容易に適用できるとは限りません。適用には依存関係のアップグレード、互換性や破壊的変更に対するテスト、そして組織の通常の開発・リリースプロセスを経ることが必要になる場合があります」
セキュリティチームがこのプロセスを何千もの脆弱性に対して適用しなければならなくなると、修復作業は膨大な優先順位付け・リソース配分の問題と化しかねません。エンジニアリングチームの時間には限りがあり、セキュリティ修正はプロダクト開発などの他の優先事項と競合するため、修正が存在する脆弱性であっても何か月もバックログに積まれたままになることがあります。
「だからこそ私たちは、こうした手作業をできる限り排除することが解決策だと考えています。エンジニアリングチームがすべての修正を自ら追跡し展開することに頼るのではなく、パッチ済みのソフトウェアを継続的に届ける仕組みが必要なのです」と同氏は述べています。
Echoはさらに別の問題も明らかにしています。自らのセキュリティ対策を「成熟している」と評価していた組織であっても、多くの場合、自ら招いた形で脆弱性へのリスク露出を抱えていたのです。コンテナの脆弱性のうち実に6割近く(56%)が、本番環境では不要なパッケージ、ユーティリティ、開発ツールなどのソフトウェアに起因していました。
「AIが発見する新たな脆弱性のすべてに追いつく方法を心配する前に、組織はまず既に抱えている攻撃対象領域を縮小することに注力すべきです」とMilner氏は助言します。「そもそも脆弱性の少ないソフトウェアで構築し、不要な依存関係を取り除き、利用可能な修正をより迅速に本番環境へ反映させることに力を入れるべきです」
翻訳元: https://www.darkreading.com/application-security/ai-vulnerability-surge-manageable-than-first-feared
