CISO・経営層向け：これから求められる脆弱性対応
このブログのポイント
- AIによって脆弱性の発見・悪用準備が加速する世界では、防御側に残される対応時間そのものが短くなります
- 脆弱性管理の主戦場は「件数の把握」から「どの経路が実害につながるかを早く見極め、速く止めるか」へ移ります
- CSAが提唱する「VulnOps」は、月次パッチ会議の言い換えではなく、組織能力の再設計を意味します
前回のブログでは、AnthropicのMythos PreviewとProject Glasswingを手がかりに、AIによってPoCとExploitの距離が縮まり、複数の弱点を攻撃経路として組み立てる力が短期間に高まっていることを整理しました。そこで見えてきたのは、単に「脆弱性がたくさん見つかるようになる」という話ではありません。もっと大きい変化は、防御側に残される時間そのものが短くなることです。
この論点を、より経営や運用の言葉でまとめたのが、Cloud Security Alliance（CSA）の戦略ブリーフィング The "AI Vulnerability Storm": Building a "Mythos-ready" Security Program（以下、CSA文書）です。CSA文書では、Mythosを特定モデルのニュースとして扱っておらず、Mythosは最初の大きな波にすぎず、同種の能力は今後さらに広がるという前提で、防御側の運用をどう作り直すべきかを整理しています。
※ CSA文書は、執筆時点ではDraft版として公開されています（最新の体裁や改訂は、CSAの公開ページでご確認ください）。
「Mythos-ready」とは何か：「一つのモデル対策」ではない
CSAがいう「Mythos-ready」は、Mythosという名前のモデルに備えることではありません。意味しているのは、AIによる脆弱性発見と悪用準備の加速が常態化する世界に、組織として対応できる状態を作ることです。
CSA文書では、AIは防御側のコードレビューや修正支援も速くする一方で、攻撃側にとっての利益のほうが構造的に大きいと強調しています。修正にはテスト、調整、展開、影響確認が必要ですが、攻撃側は見つけた弱点を攻撃経路に変えられればよい、という非対称性です。
その結果、公開から悪用までの時間は縮み続け、現在のパッチサイクルやリスク評価の前提では追いつけなくなる可能性が高い、とCSAは見ています。
Glasswingのような限定的な先行共有があっても、防御側の優位は一時的です。世界全体の攻撃可能面は、どんな厳選パートナーのエコシステムでもカバーしきれません。同等の能力が他のフロンティアモデルやオープンウェイトモデルに広がれば、先行アクセスの価値も薄れていきます。
したがって、「どのモデルが強いか」を追うより、「その世界で回る運用」を先に設計することが重要になります。
「修正件数」から「対応スピード」重視へのパラダイムシフト
前回のブログでも触れたように、AI時代に本当に厄介なのは単体の脆弱性ではなく、連鎖です。CSA文書はその話を、より運用側の課題に引き寄せています。
CSA文書が繰り返し指摘しているのは、これからの組織は次のような状況に同時に向き合う必要があるということです。
- パッチ候補や脆弱性情報が短期間に大量に集中する
- CVE（共通脆弱性識別子）やKEV（既知の悪用済み脆弱性）のような既存の脅威インテリジェンスが追いつかない
- 自社コードだけでなく依存関係やサプライチェーンの影響判定が必要になる
- 侵害そのものをゼロにするより、封じ込めと復旧の速度がより重要になる
つまり、脆弱性対応の主戦場は「見つかった1件をどう直すか」から、大量に集中する候補の中で、何を先に止めるかをどれだけ速く決められるかへ移ります。経営報告やリスク委員会の議論も、「件数」中心から影響範囲・復旧時間・封じ込めに軸足を寄せる余地が出てきます。
「VulnOps」とは何か：月次イベントではなく常時稼働の機能
こうした状況を踏まえると、CSAが中核に置いているのが「VulnOps」です。一時的なキャンペーンでも、月次のパッチ会議の言い換えでもありません。脆弱性を継続的に見つけ、優先順位を付け、修正または封じ込めまで回し続ける恒久的な運用能力として定義されています。
四半期ごとのペンテストや定例パッチサイクルは、AIが継続的に見つけるゼロデイや連鎖欠陥のペースに合わない、というのがCSA文書の主張の根拠です。既存のCVE/NVD（国家脆弱性データベース）の仕組みや、月に数十件の重大CVEを前提にした優先付けワークフローは、今後の件数と速度に耐えられない可能性がある、とも示唆されています。
ここでいう「VulnOps」は、単にチケットの処理速度を上げることではありません。少なくとも次の要素がまとまって初めて機能します。
- 継続的な検出
- 影響範囲の把握
- 悪用可能性と攻撃経路に基づく優先付け
- 修正が間に合わない場合の封じ込め
- インシデント対応との接続
言い換えると、AppSec（アプリケーションセキュリティ）、脆弱性管理、インシデント対応、サプライチェーン管理を、AI時代の速度に合わせて一体で回す考え方です。経営・CISO（最高情報セキュリティ責任者）にとっては、予算・人員・責任境界がバラバラなままでは回らない、という含意でもあります。
CSA文書のアクションプラン：「今週・45日・12か月」で備える
以下では、CSA文書が時間軸に沿って示しているアクションを、今週・45日・12か月の三つのレンジに分けて紹介します。即時の着手事項から、体制の立ち上げ、1年スパンでの定着までが一続きで読める構成になっています。
今週から始めること
即時アクションとしてCSAが挙げているのは、まずAIを防御側の現場に入れることです。
コードレビューへの組み込み
自社コードだけでなく依存関係も含め、CI/CDにAIベースのレビューを組み込み、AI生成コードもマージ前レビューの対象にする取り組みです。「AIにコードを書かせるか」より前に、「AIに書かれたコードや既存コードをどう点検するか」を標準化する、という順序の話でもあります。
セキュリティ組織でのコーディングエージェント
脆弱性調査、パッチ確認、監査証跡の収集、プレイブック整備、トリアージ支援など、用途は広いです。CSAは、攻撃側がすでにAIで速度を上げている以上、防御側も同じ土俵に立たなければギャップは埋まらない、とはっきり述べています。
エージェント自体のリスク
ただし、ここで終わりではありません。CSAが同時に強調しているのは、防御側で使うエージェント自体が新しい攻撃面になることです。
権限の強いエージェント、外部プラグイン、MCP（モデルコンテキストプロトコル）サーバー、取得パイプライン、プロンプト設計などは、既存の管理対象から漏れやすい領域です。エージェント導入は推進と同時に、権限境界、人手によるオーバーライド、監査可能性を整備する必要があります。
ガバナンスの横断整備
Security、Legal、Engineeringを横断するガバナンスの整備も即時アクションに含まれます。新しい防御技術を入れようとしても、承認フローが遅ければ意味がありません。AIによってタイムラインが圧縮されるほど、承認の遅さ自体がリスクとして計上される、というメッセージです。
次の45日で整えること
次に来るのは、脆弱性対応を「作業」から「機能」に変えるフェーズです。
- 継続的な「VulnOps」の形を作る
SAST（静的アプリケーションセキュリティテスト）、DAST（動的アプリケーションセキュリティテスト）、スキャン、ペネトレーションテスト、バグ報告、ベンダーアドバイザリ、OSSの脆弱性情報などを、個別イベントとして扱うのではなく、優先順位付きの継続運用へまとめる。月次のパッチ委員会中心のモデルから、常時動く脆弱性対応機能への移行です。 - リスクモデルを更新する
CSAは、これまでのリスク指標や経営報告が、前AI時代の前提に基づいている可能性を指摘しています。問うべきは「侵害を完全に防げるか」だけではなく、「侵害後どれだけ早く封じ込め、通常運転へ戻せるか」です。復旧時間、封じ込め時間、影響範囲といった指標を中心に据え直すことを意味します。 - 資産と露出面の棚卸し
インターネット露出資産、重要なクラウンジュエル、依存関係、シャドーIT、シャドーAI、非開発部門によるエージェント利用まで含め、継続的に可視化する必要があります。AIが普及すると、中央ITの外でコードや自動化が増え、見えない攻撃面が広がるからです。
次の12か月で定着させること
1年のスパンで必要になるのは、単発の改善ではなく、次の二つを定着させることです。
- 影響範囲を小さくする構造
- 対応速度を上げる仕組み
CSAが示す方向性は、大きく次の3つに整理できます。
1. 基本コントロールの強化
セグメンテーション、egress filtering（外部への通信制御）、フィッシング耐性のあるMFA（多要素認証）、Zero Trustといった基本コントロールです。派手ではありませんが、AIによって見つかる欠陥の件数が増えるほど、建築的な分離が最も効く防御になります。AI時代ほど「基本の徹底」が古びないどころか、むしろ価値を増す、という論理です。
2. 検知と対応の速度
AIによる攻撃が機械速度に近づくほど、人手だけのトリアージや手動封じ込めは厳しくなります。ハニートークン、deception、UEBA（ユーザー・エンティティ行動分析）、AI支援トリアージ、自動封じ込めのような仕組みは、今後ますます重要になり得ます。
3. 「VulnOps」の制度化
「VulnOps」を恒久的な組織能力として制度化することです。担当者の善意や瞬発力に依存するのではなく、役割、責任、指標、プレイブック、エスカレーションをセットで回る形にしなければ、最初の波をしのいでも次の波で詰まります。
見落としやすい論点：「人」と「連携」
CSA文書では、技術的な側面だけでなく、人材の課題や業界全体での連携の重要性にも深く言及されています。
人の面：燃え尽きは運用リスク
セキュリティチームの燃え尽きは、CSA文書では直接的な運用リスクとして扱われています。
脆弱性対応件数、コード量、攻撃面、AI学習コストが同時に増える中で、人員やツール、ウェルビーイングの投資が追いつかなければ、最も経験のある人から疲弊していきます。これは単なる組織論ではなく、初動品質や判断速度に直結する問題です。
協調：防御側も「共有」が前提
もうひとつは協調です。CSAは、攻撃側がすでに「シンジケート（組織化された集団）」として知見やツールを共有している以上、防御側もISAC（情報共有分析センター）、CERT（コンピュータ緊急対応チーム）、業界団体、標準化団体などを活用し、連携を強めるべきだと述べています。
前回のブログで触れたサプライチェーンやOEMとサプライヤーの連携にも、そのまま当てはまります。個社で全部を見るのではなく、連携前提で早く判断し、早く伝播させる運用が必要です。
まとめ
以下に整理します。
| 観点 | 重視すべきポイント |
|---|---|
| 「Mythos-ready」の意味 | 特定モデルへの対策ではなく、AI加速が常態化する世界への運用設計 |
| 脆弱性対応の優先軸 | 「件数の把握」から「悪用経路を早く見極め、速く止める」へ |
| 「VulnOps」の本質 | 月次パッチ会議の言い換えではなく、継続稼働する組織能力の制度化 |
| 今週のアクション | AI防御側導入・エージェントリスク管理・横断ガバナンスの整備 |
| 45日のアクション | VulnOps形成・リスクモデル更新・資産と露出面の棚卸し |
| 12か月の定着 | 基本コントロール強化・検知速度向上・VulnOps制度化 |
| 人と連携の論点 | 燃え尽きは運用リスク・ISAC/CERTを活用した業界協調が前提 |
表1. Mythos-readyとVulnOpsの論点整理
企業が本当に備えるべき対象は、Mythosという一つのモデルではありません。備えるべきなのは、AIによって脆弱性発見、悪用準備、攻撃の自動化が加速し続ける世界です。
CSAの「Mythos-ready」と「VulnOps」は、その世界に対する実務に寄せたフレームです。経営・CISOにとっての実務的な含意はシンプルで、脆弱性の数を眺めることより、どの経路が実害につながるかを早く見極め、どれだけ短い時間で止められるかを中心に運用と説明責任を組み直すこと、に集約されます。
出典
- Cloud Security Alliance, "The 'AI Vulnerability Storm': Building a 'Mythos-ready' Security Program" (Expedited Strategy Briefing, April 12, 2026)
(https://labs.cloudsecurityalliance.org/mythos-ciso/) - Anthropic, "Project Glasswing: Securing critical software for the AI era"
(https://www.anthropic.com/glasswing) - Anthropic Frontier Red Team, "Assessing Claude Mythos Preview's cybersecurity capabilities"
(https://red.anthropic.com/2026/mythos-preview/)
関連リソース
VicOne 車載脆弱性・SBOM管理（xZETA） — ゼロデイを含む車載ソフトウェアの脆弱性を検出・優先順位付けし、SBOMを正確に管理
Cloud Security Alliance "AI Vulnerability Storm" — 本ブログで参照したCSAの戦略ブリーフィング（英語）