フロンティアAI時代の脆弱性ハンドリング：Exploit生成の加速と、防御側が「Detection as Code」で勝つ

AIが変えつつある「脆弱性公開後」のタイムライン

世の中で利用されているOS、ミドルウェア、アプリケーションの脆弱性がより早く公開されることは、より安全なソフトウェア開発が進むということでユーザー側のメリットがあります。一方、それらの中にある重要データが安全に管理されているかどうかの懸念と、組織側の対策コストに重大なワークロードが掛かり始めています。特に脆弱性公開から攻撃(Exploit)が利用されるまでの猶予時間が極めて短期間になっていることが最大の原因と言えるでしょう。

この武器化されるコードの現状と、防御側はどう立ち向かうべきかについて、この記事では紹介したいと思います。

1.【データで見る現状】年間数万件のCVEとExploitの実態

CVE(共通脆弱性識別子)では2023年末頃からCVE Service2.0とCVE JSON 5.0スキーマが利用され始めたことにより、Vulnerability as Codeとも呼べるようなCVEの競合防止と差分アップデート追跡が容易にできる仕組みに変更されています。まさに今日のフロンティアAIを見越した仕組みが予め構築されていたようにも思えるほどであり、2026年7月27日時点の脆弱性件数の推移について見てみましょう。

2026年は7月27日時点で、既に過去最高であった2025年の43,227件の約85%である36,895件まで推移していることから年度末には昨年度比50-60%増の新たな脆弱性の検出が予想されます。これはフロンティアAIが、より脆弱性を見つけやすい、或いは見つかった、という背景と言えるでしょう。(cveMetadata.state=PUBLISHEDのみ抽出)

一方この脆弱性に対してExploitコードがでているかどうかが重要です。コード化できなければ社会的インパクトはそれほど高くないためです。これらはCISA KEV(Known Exploited Vulnerabilities)が公開しており、権威の極めて高い情報に紐づくExploit情報があります。一方nomi-secのExploit情報があり、これはGitHubでAPI botを利用して自動的にExploitを収集しています。KEVはお墨付きのExploitであるのに対し、nomi-secはpocの段階からスピード重視で検出されたExploitコード情報になります。件数と速度は圧倒的にnomi-secが多いため今回こちらのデータを参照してみます。

脆弱性の件数に対してExploitの件数が同様に激増しているかと考えがちですが、Exploitは例年並みの数と言えます。結果として社会的な混乱に陥っていないことが一つの事実として挙げられている根拠にもなるデータになります。(実際のExploitはこれよりも多く、脆弱性とExploitは1対nの関係。この表では1対1にして表記)

加えて、これらのデータを比較して脆弱性が公開されてからExploitが出るまでの日程がどの程度早くなったのかを分析してみました。Exploitの平均リリース間隔は毎年倍程度早くなっていることがわかります。2025年が42.6日に対して、2026年の現時点では25.0日、約41%減です。またCVE公開日と同日またはそれ以前に公開される0-dayは、2025年で43%、2026年は逆に下がって25%程度になっています。

データで分かることはフロンティアAIによってExploitのスピードがさらに早くなるという“触れ込み”であるが、それを示すエビデンスは確認できません。これはProject Glasswingなど限られたユーザーのみに利用を限定しているため、世の中に影響を与えないという意味では効果を発揮していると言えます。しかしながら、ここ3年平均で30%以上が脆弱性公開日の即日リリースされるという速さに変わりはありません。

2. そもそも脆弱性はどう公開されるのか？(CVDと45-90日ルール)

• 脆弱性の公開の基本ルールとしては、協調的脆弱性開示(CVD: Coordinated Vulnerability Disclosure)で定義されており、脆弱性の開示(ISO/IEC/29147)と、脆弱性の取り扱い手順(ISO/IEC/ 30111)でルールが定められています。
• 45日は目安であることと、一般的には脆弱性を見つけた本人がベンダー或いはOSSのPSIRT窓口に通知し、この国際概念に則ってやり取りを行います。Googleはこれをベンダーとして90日に設定しています。フロンティアAIだからといってこのルールが変わるないので、0-dayになるということではありません。

3. 攻撃の超高速化：フロンティアAIによるExploit作成の現実

CVEにて脆弱性情報が公開され危険度の高い場合、コード発見者でなくても、特に悪意の持った第三者がそれを解き明かしAIを悪用し概念検証し、そしてコード化する可能性が大いに高まっているといえます。公開文章が丁寧であればあるほどAIを利用することで迅速にコードが開発できると言えます。現時点で脆弱性公開日に30％のコードが公開されていることから、フロンティアAIの利用が進むにつれてこの平均値や割合が高まるとデータからも言えるでしょう。

4. 防御側の対抗策：Vulnerability as Code, Exploit as Code,そしてDetection as Code (DaC)という思想

攻撃側はExploitコードを作成してそれを悪用します。それに対して防御側も検知ロジックをコード化して対応していく必要があります。これはコードを意味しますので、それぞれが独立してchangelogを残しながら扱いやすいようにしなければなりません。SplunkのSecurityコンテンツは数年前よりこれらのコンテンツを無償提供しておりgithubからclone可能です。これはそれぞれの検知コンテンツをコード化して、カスタマイズ、CI/CDデプロイできることを意味しており、yamlで記述されたユーザー独自の検知コンテンツをSplunkに反映することを実現しています。

セキュリティパッチ適用をするのであればシステム及び関連領域のテスト、サービス停止時間も考慮しながら計画を練る必要がありますが、どのくらいの攻撃が既にきているかの、インシデント検証や一次対応手段としてこれらの検知ロジックを、パッチ適用の前に、即座に展開することも出来るでしょう。

つまり、Exploitコードがでてもセキュリティパッチがでていないなら、AIを利用し検知コードを作成することが即座に出来ると言うことです。

5. 【実践】AI × Detection as Code パイプラインの構築

大きな流れとしてSplunkのルールsecurity_contentsのforkをgithubから行い、ユーザー独自のルールを記述します。そして検証後、それらを製品側のルールとして登録する流れになります。contentctl-ngで実装可能であり、 今後はEnterprise SecurityのDetection Studioに移行していく予定です。ユーザーサイドで開発した外部公開向けのユーザー/WebアプリケーションにおいてフロンティアAIなどを利用して独自の脆弱性を見つけた場合、これらの手法を利用して検知ルールを迅速に作成することが重要といえます。

検知コードの作成方法について少し解説したいと思います。Exploitコードは脆弱性に対して1件だけであるとは限りません。過去2年をみると最も多かったExploitコードはCVE-2025-55182のReact Server Componentの脆弱性でした。これはcvssのbase Scoreが最大の10点で、極めてリスクの高い脆弱性であり、455のExploitコードが作成されています。

2026年においてはCVE-2026-63030のWordPressの脆弱性はbase Scoreが9.8で、このSQL Injection(CVE-2026-60137との繋がり)は広範囲なユーザーへの影響が考えられる脆弱性として広まりました。これは62件ものExploitが作成されています。

それではサーチ作成に移ります。シンプルにこちらの脆弱性情報、そしてExploit情報をAIにわたし、SPLを作成してもらうだけです。LLMはMCP経由でサーチの解説と複数のパターンのSPLを数分でアウトプットします。

実際MCPを使って環境内のデータソースを特定しながら行うことができるので、ユーザー環境に即した検知サーチが作成されます。これをテストし、チューニングしながらVaCを進めていくことで、ユーザー環境内で検出/対応すべき脆弱性について推し進めることが簡単に出来ます。

まとめ：AI時代のセキュリティは「パッチ適用待ち」から「検知コードの即時更新」へ

• フロンティアAIによって攻撃のタイムラインが縮んだからこそ、防御側もソフトウェア開発と同じ速度感(DaC)を持つ必要がある。
• 45/90日ルールの猶予に頼るのではなく、公開された瞬間に「自動で検知コードをデプロイできる体制」を作ることが、これからの防御側の勝機になると考えます。