LLM時代における90日開示ポリシーの死

10年以上にわたり、セキュリティ業界は以下の基本的前提に基づいて運営されてきました：バグを見つける人は比較的稀であること、エクスプロイトの開発は時間がかかり高度なスキルを要すること、そして90日間の開示ウィンドウはベンダーに対し、一般公開や攻撃者が認識する前にパッチを適用するための十分な猶予を提供する、というものです。

これらの前提はもはや有効ではありません。大規模言語モデル（LLM）を攻撃的・防御的なワークフローに組み込むことで、発見からエクスプロイトまでの時間がほぼゼロにまで圧縮されました。私たちは「責任ある開示」ウィンドウがユーザーを保護するのではなく、バグを既に見つけて報告しない者に先手を与える時代に突入しています。

発見独占の崩壊

従来のモデルでは、研究者が重大なバグを発見すると、数週間にわたりその知識を唯一の所有者として保持していました。現在、LLM支援のハンティングにより「収束的発見」という現象が生まれています。

最近の事例を考えてみましょう。攻撃者がウェブサイトの支払い検証を回避できる重大な脆弱性が報告されたケースです。報告者は、同じバグを6週間のウィンドウ内で11人目の報告者であることが判明しました。このパターンは体系的になりつつあります。LLMのプロンプトや自動化スキルが共有されたり独立して導出されたりすると、無関係な複数の研究者がほぼ同時に同じ根本原因に収束します。

これにより危険なインセンティブ構造が生まれます。10人がバグを見つけても、CVEクレジットやバウンティを受け取るのが1人だけであれば、残りの9人は強力な武器を手に入れたまま報酬が得られません。発見が迅速かつ豊富な世界では、90日間の時計は保護ではなく露出の期間となります。

パッチからエクスプロイトまで数分

歴史的に、「n日ギャップ」――パッチがリリースされてからそのパッチを元に動作するエクスプロイトが開発されるまでの時間――は重要な安全ネットでした。システム管理者は数日から数週間の間にシステムを更新できました。

そのギャップは消失しました。Reactのセキュリティパッチに関する最近の実験では、LLMがパッチのdiffを解析し、脆弱なコードパスを特定し、わずか30分で動作する概念実証（PoC）を生成できることが示されています。単純から中程度に複雑なバグに対して、熟練したリバースエンジニアはもはや必須ではなく、LLMが面倒な解析を担当し、人間はプロセスを指示するだけです。

ケーススタディ：今週のLinux「炎上」

最近のLinuxカーネル脆弱性2件は、旧来の開示モデルが完全に機能しなくなったことを示しています。

Copy Fail (CVE-2026-31431)

crypto/サブシステムをAI自動スキャンでわずか1時間で発見されたこの論理欠陥は、2017年以降にリリースされたほぼすべてのLinuxディストリビューションで100％確実にルート権限をエスカレートさせました。武器化の速度は驚異的で、公開から数日以内に国家レベルのアクターがこのバグを利用し、UbuntuサーバーをDDoSキャンペーンの標的にしました。

Dirty Frag (CVE-2026-43284 & CVE-2026-43500)

この脆弱性チェーンはCopy Failに対して導入された緩和策を回避しました。協調的な取り組みと5日間のエンバーゴにもかかわらず、第三者が数時間以内にエクスプロイト情報を公開してエンバーゴを破りました。完全なレポートとPoCが公開された時点で、パッチが提供されているLinuxディストリビューションはゼロでした。MicrosoftのDefenderチームは、24時間以内に実際の環境でのエクスプロイトが確認されたと報告しています。

新たなセキュリティの必須事項

90日間のウィンドウと月次パッチサイクルが廃れたのであれば、業界はリアルタイム対応モデルへ転換する必要があります。

ベンダーと研究者向け

重大なセキュリティ問題はP0緊急事態として扱うべきです。時計は報告が届いた瞬間に開始し、トリアージが終了した時点ではありません。研究者は、欠陥を見つけたのは自分だけではない可能性が高いことを認識し、できるだけ短い開示ウィンドウを求めるべきです。

ブルーチーム向け：AI駆動防御

防御側はLLM駆動の攻撃者と手動プロセスで戦うことはできません。防御パイプラインは攻撃側と同等の速度で自動化される必要があります。

プッシュ時レビュー: AI支援のセキュリティレビューをCIパイプラインに統合します。脆弱性はCVEが発行された後ではなく、Pull Request (PR) フェーズで検出されるべきです。
自動パッチ解析: 上流の依存関係がパッチされると、AIが自動的にdiffを解析し、ローカルコードベースへの影響を判断し、即時対応のためにフラグを立てます。
AI検証パッチング: セキュリティ修正をリリースする前に、LLMを使用してパッチが実際に問題を解消し、新たなリグレッションを導入していないことを検証します。

反論：これは単なる「低ハングフルーツ」フェーズなのか？

一部では、LLMが見つけたバグの急増は一時的なピークに過ぎないと主張されています。理論的には、レガシーコードの「簡単」なバグがすべて除去されれば、業界は人間の洞察が発見の主要な推進力である状態に戻ると考えられています。

しかし、これはAIの反復的性質を過小評価しています。LLMが複雑な状態機械やレースコンディションを理解できるようになるにつれ、「低ハングフルーツ」の定義は拡大します。リスクはすべてのバグが見つかることではなく、エクスプロイトされる前に修正できるウィンドウが永続的に縮小してしまうことです。

最後に

現代のセキュリティの現実は、脆弱性とエクスプロイトの間のギャップがゼロに向かって縮小していることです。この変化を乗り切る唯一の方法は、AIを防御パイプラインの第一級コンポーネントにすることです。スキャン、解析、パッチ適用を自動化するツールは既に存在します。残された唯一の疑問は、防御側が攻撃側に先んじてそれらを導入できるかどうかです。