90日責任開示はもう死んだ、AIが変えた脆弱性の時間軸
セキュリティ研究者のヒマンシュ・アナンド氏が、12年続いた「90日責任開示」モデルの終焉を宣言した。LLMが脆弱性発見と悪用の両側を同時に加速させているからだ。
セキュリティ研究者のヒマンシュ・アナンド氏が、12年続いた「90日責任開示」モデルの終焉を宣言した。LLMが脆弱性発見と悪用の両側を同時に加速させているからだ。
なぜいま「90日は死んだ」と言われるのか
ヒマンシュ・アナンド（Himanshu Anand）氏は、シマンテック、クラウドフレアなどでマルウェア解析やWAFルール設計に携わってきたセキュリティ研究者である。長年責任ある開示プロセスの内側にいた人物だ。その人が2026年5月9日、自身のブログで「90日間の責任ある開示はもう死んだ」と書いた。これは煽りではない。過去12カ月で起きた現実の積み重ねから導いた結論である。
90日モデルは2010年代にグーグル・プロジェクトゼロが普及させた業界標準で、研究者が脆弱性を発見してからベンダーに 90日の猶予 を与え、その間に修正パッチを出してもらうという約束ごとだ。前提は4つあった。バグを見つけた人は希少である。仮に複数の人が見つけても時間差がある。ベンダーには修正を書く十分な時間がある。パッチが出てから攻撃に転用されるまで数日から数週間かかる。
ヒマンシュ・アナンド氏は、これら4つの前提が「すべて崩れた」と書く。原因はLLMだ。脆弱性を探す側も、パッチを攻撃に変える側も、同じスピードで賢くなった。守る側だけが置き去りになっている。
ストーリー1、6週間で11人が同じバグを見つけた
2026年4月下旬に、ある会社にかなりまずいバグを報告した。サーバーの応答に署名検証がない設計で、攻撃者が5000ドルの商品を0ドルで購入できる。書き上げて送って、10分くらい気分が良かった。
ヒマンシュ・アナンド氏のブログから抜粋した報告体験だ。トリアージチームから返ってきた答えは「もう知っている、3月に最初に報告された、あなたは11人目だ」というものだった。11人が同じ重大バグを発見 していた、それも6週間で。
これは個人の体験談ではない。脆弱性トリアージ担当者のサシュコ氏（@d0rsky）も「新しい脆弱性がLLMプロンプトや自動化スクリプトで発見されると、数日以内に重複報告の波が来る。根本原因は同じで、表現だけが微妙に違う」と公にしている。研究者が同じ手口で短時間に発見できるなら、攻撃者も同じ手口で発見できる。「最初の発見」から「広範な認知」までの時間が危険なほど短くなっている、というのが現場の感覚だ。
ここでヒマンシュ・アナンド氏は数字を裏返す。10人が報告したなら、発見したが報告しなかった人は何人いるのか。CVE番号も賞金も最初の1人だけが受け取る。残った9人のうち、何人が嫌気が差したか。何人が地下市場で売る選択をしたか。そして、はじめから報告する気がなかった人々は、90日の時計を見ていない。90日窓は利用者を守っていない。すでにバグを持っている全員に90日の助走を与えているだけだ、と氏は結論する。
1人が見つけられたバグは、すでに10人が見つけている。報告したくない9人は時計を持っていない。
ストーリー2、パッチから攻撃まで30分
リアクト（React）が最近、複数のセキュリティ問題を修正した。CVE-2026-23870、CVE-2026-44575、CVE-2026-44579、CVE-2026-44574、CVE-2026-44578の5件である。リアクトチームはパッチ内容を公開ブログで丁寧に解説した。攻撃者に手の内を見せる「教科書のような責任ある運用」だ。
ヒマンシュ・アナンド氏は記事を読み、好奇心からひとつ試した。このパッチをエクスプロイトに変えるのに何分かかるか。自分の検証用環境、ローカルテストアプリ、AIアシスタントだけで実験した。答えは 30分 だった。差分（diff）を読んで、脆弱なコードパスを特定し、PoCを書くまで。今回は機能停止（DoS）止まりだったが、AIが大半の重労働を担い、人間は方向を決めるだけで済んだ。
これは旧世界では考えられない速度だ。公開されたパッチからエクスプロイトを作るn-day攻撃には、熟練のリバースエンジニアが数日から数週間かけるのが通例だった。その時間差が「パッチを出してから管理者が更新するまでの安全マージン」を成立させていた。 パッチ即エクスプロイト 、その前提で動くしかない時代にすでに入っている。猶予期間はない。
ストーリー3、Linuxカーネルが2週間で2度燃えた
90日モデルの終焉を最も鮮烈に示したのは、2026年4月末から5月初頭にかけてのLinuxカーネルである。わずか2週間で重大な特権昇格脆弱性が2つ連続で公開された。両方ともすべての主要ディストリビューションが対象だった。
Copy Fail（CVE-2026-31431）の衝撃
4月29日、DEF CON CTFを9度制した実力派チームTheori傘下のXint Codeが、Linuxカーネルの暗号サブシステムに潜む論理欠陥「Copy Fail」を公開した。CVE-2026-31431として割り当てられている。732バイトのPythonスクリプトひとつで、2017年以降のあらゆるLinuxディストリビューションでroot権限を奪取できる、と研究者らは説明した。Ubuntu、RHEL、Amazon Linux、SUSE、すべてが対象だ。
恐ろしいのは発見プロセスである。Xint Codeは「Linuxのcrypto/サブシステムに対しておよそ1時間の自動スキャンを走らせ、最も深刻な結果としてこのバグを浮上させた」と報告した。人間の研究者が9年間見逃したバグを、 AIスキャナが1時間で発掘 した形だ。
パッチは出た。a664bf3d603dという単一コミットで、2017年の最適化を巻き戻す内容だ。緩和策も簡単で、algif_aeadモジュールを無効化すれば塞がる。多くの管理者が深呼吸して対応を始めた。
そこへ国家アクターが入ってきた。イランの攻撃者がCopy Failを使ってUbuntuサーバーを侵害し、DDoSの中継ノードに転用していたことが観測されている。AIが発見し、研究者が公開し、国家アクターが武器化する。すべてが数日のうちに完結した。
Dirty Frag、エンバーゴが破られた日
「責任ある開示は死んだ🤦」 ── CTS氏（@gf_256）
Copy Failの公開からわずか1週間後の5月7日、研究者のキム・ヒョヌ（Hyunwoo Kim、@v4bel）氏が「Dirty Frag」を公開した。CVE-2026-43284とCVE-2026-43500を連鎖させる手法で、こちらもページキャッシュ書き込み系の脆弱性である。決定的な差は、Copy Failの緩和策を適用済みの環境でも、 Dirty Fragは独立して悪用可能 という点だ。algif_aeadを無効化していても効かない。Dirty FragはIPSec ESPとRxRPCという別経路を使う。
開示プロセスは完全に崩壊した。キム・ヒョヌ氏は4月29日から30日にかけてLinuxカーネルチームへ通報し、5月7日に主要ディストリビューターのメーリングリストへ5日間の禁輸（embargo）を提案した。ところが同日中に、無関係の第三者がESPの脆弱性に関する詳細なエクスプロイト情報を公開した。embargo破綻だ。ディストリビューターと協議した上で、キム・ヒョヌ氏はやむをえずDirty Fragの完全な技術解説、エクスプロイトコード、動作するPoCを公開した。
この時点で、いかなるLinuxディストリビューションにもパッチは存在しなかった。マイクロソフトのDefenderチームは公開から24時間以内に、実際の攻撃での悪用を確認したと発表している。攻撃者はSSHでアクセスし、ELFバイナリを設置し、suで権限を取り、認証設定を書き換え、セッションファイルを消し、横展開する。本番環境で稼働中の攻撃手順がそのまま動いていた。
6週間で11人が同じバグを見つけ、30分でパッチがエクスプロイトに化け、24時間で国家アクターが実戦に投入する。それが2026年の現実だ。
何が「死んだ」のか、もう少し正確に
ヒマンシュ・アナンド氏が「死んだ」と言うものは3つある。
ひとつは90日窓そのものだ。10人が同じバグを6週間で見つけ、AIがパッチを30分でエクスプロイトに変える世界になっている。その世界で90日が誰を守るのか答えられないなら、それは「丁寧な名前を付けた露出時間」でしかない。Copy Failは数日でAIスキャンから国家アクターによる武器化まで進み、Dirty Fragのembargoは数時間で破られた。同じ脆弱性が複数の研究者とAIツールに同時並行で再発見されるなら、開示を協調する前提が成り立たない。
次が 月次パッチサイクル だ。30日の修正窓は「攻撃者はリリース列車より遅い」という仮定の上に成り立つ。仮定はもう成立しない。マイクロソフトはDirty Fragを24時間で野生環境で観測した。月次のメンテナンス窓は安全マージンではなく、攻撃窓に変わっている。
最後が「アドバイザリを待つ」というワークフローだ。攻撃者がgit log --diff-filter=Mでコミット履歴を追っている時代に、CVE記述を待って読んでいる管理者は手遅れだ。アドバイザリは下流の成果物で、パッチ差分こそが本物のシグナルなのだ。
では青チーム（防御側）はどう動けばいいのか
ヒマンシュ・アナンド氏の提案は徹底している。報告が着地した瞬間に時計が始まる、というのが唯一の頼みだ。「24時間以内」でも「次のスプリント」でもない。なぜなら、報告した人がいるなら、他にも10人が持っていると考えるべきで、そのうち少なくとも1人は悪意ある側にいるからだ。重大バグはすべてP0扱い にせよ、というのが結論である。
防御側にも具体的な処方箋を出している。最も重要なのは、 LLMをコードプッシュに組み込む ことだ。CI/CDのリンターやユニットテストと同じ場所に、AI支援セキュリティレビューを置く。プルリクエスト、マージ、デプロイのたびに走らせる。本番に届く前に欠陥を捕まえる。PRレビューでバグを直すコストは、CVE公開後の対応費用より桁違いに安い。
次がパッチ解析の自動化だ。上流の依存先がセキュリティパッチを出したら、パイプラインが差分を引き、変更点を分析し、自分のコードベースが影響を受けるかを判定し、フラグを立てる。人間がメーリングリストを読んでJiraチケットを切る待ち時間を排除する。Xint Codeが1時間でCopy Failを見つけられるなら、同じ仕組みを自社の依存先スキャンに向けない理由はない。
そしてパッチ自体をAIで検証する。AIが30分でパッチをエクスプロイトに変えられるなら、ベンダー側はパッチを出す前にAIで「このパッチは本当に問題を塞いでいるか」「新しいバグを作っていないか」「同じパターンが他の場所にも残っていないか」を確認すべきだ。攻撃者がパッチ公開直後にやるなら、ベンダーは公開前にやればいい。
攻撃者はすでにLLMをエクスプロイト・パイプラインに組み込んでいる。防御側がやっていないなら、クリップボード片手にガンファイトに出ているのと同じだ。
終わりに、5月7日の一枚の絵
ヒマンシュ・アナンド氏は最後にひとつの光景を描く。5月7日、Dirty Fragの公告を読むシステム管理者だ。利用可能なパッチはない。エクスプロイトはすでに公開されている。マイクロソフトはすでに野生環境で観測している。緩和策は「IPSecモジュールを無効化せよ」だ。そしてこの管理者には触らなければならないサーバーが400台ある。
これは仮想シナリオではない。先週の水曜日に実際に起きたことだ。90日の責任ある開示は死んだ。月次パッチサイクルも死んだ。開示と悪用の間に時間があるという仮定も死んだ。死んでいないのは、速く動き、自動化を徹底し、重大バグを緊急事態として扱う能力だけだ。旧モデルを壊したAIの波が、新モデルも可能にしている。問題は、攻撃者より先に防御者がその波に乗れるかだ。いまのところレースは攻撃者が勝っている。
12年続いた90日モデルが、たった2週間のLinuxカーネル事件で破れた。次の2週間、何が壊れる番か。
参照元
