カテゴリー別アーカイブ: Mythos

「VulnOps:AI時代の脆弱性管理」を公開しました!

本書「VulnOps:AI時代の脆弱性管理」は、CSA本部が公開している「VulnOps: Vulnerability Management in the Age of AI」の日本語版で、リサーチノートです。

資料はこちらからダウンロードしてください。

AIによる脆弱性の自動発見でCVEの登録件数が急増する一方、米国のNVDは2026年4月に情報付与(エンリッチメント)の対象を一部に限定し、公表から悪用までの時間も数時間単位にまで縮まっています。本書は、定期スキャンと四半期ごとのパッチ適用を軸とする従来の脆弱性管理はもはや通用しないと指摘し、脆弱性への対応を絶え間ない流れとして回し続ける運用手法「VulnOps」を提唱しています。そのうえで、継続的な発見、リスクベースの優先順位付け、修正の自動化など6つの基本原則と、組織が最初に取り組むべき3つの施策を示しています。

本書の背景には、Anthropicの「Claude Mythos Preview」をはじめとする高性能なAIモデルが、未知の脆弱性を大量に発見できるようになったことがあります。これを受けてCSAは、SANS、OWASPなどと共同で2026年4月に「The AI Vulnerability Storm: Building a Mythos-ready Security Program」を公表し、AIによる脆弱性発見の時代に備えた「Mythosレディー」なセキュリティプログラムの構築を呼びかけました。「Mythosレディー」ではその柱の一つとして、VulnOpsを組織の恒常的な機能として立ち上げることを求めています。本書は、そのVulnOpsとは何か、なぜ必要なのかを掘り下げています。

また、VulnOps、CTEMの実装について、以下のブログを公開していますので、合わせてご覧ください。

「Mythosレディ」とは何か(続編-3)~ VulnOps と CTEM を実装する実施例

以上

PHP2Shell(PHP騒動)をMythosレディの観点から読み解く ~ 3層モデルによる評価、国内外の対応比較と今後の推奨

2026年10月24日
AIWGメンバー 諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

エグゼクティブサマリー

  • 何が起きたか:PHP本体に、認証なしで任意コード実行(RCE)に至る可能性がある2件の重大な脆弱性(CVE-2026-109618/109619、通称PHP2Shell、CVSS v4.0で9.2)が見つかった。PHP 5.4以降、修正版より前のバージョンが影響を受ける。本脆弱性はPHP本体のリクエスト処理に起因するため、アプリケーション側の認証・入力検証だけでは根本的に解消できない[1][23]。
  • AIの役割:Calif(OpenAIの「Patch the Planet」の中でGPT-5.6 Solを使用)、OpenAI、Wizが、それぞれAIを使って独立に発見した。欠陥自体は10年以上前からあった。Wizは、AIによる分析が脆弱性の理解や、実際に動作する攻撃コードの作成・標的ごとの調整を支援したと説明している[1][2][3]。
  • 防御側の窓は開いたが、早く閉じた:発見から公開まで約2か月半あったが、10月20日に情報がリークし、公開の4日前(10月17日)から悪用の試みが観測されていた。公開から1日足らずで、攻撃の試みは数百万件規模に達した[10][11]。
  • 国内外で予防停止が広がった:欧州では、複数の政府機関や公共サービスが予防的にサイトを停止した[17][18]。日本でも首相と国家サイバー統括室が深夜に呼びかけ、省庁・自治体・銀行・交通まで停止が広がり、停止告知は502件を超えた。このうち285件は、調査対象のX上で再開告知を確認できなかったものであり、実際の停止継続件数とは一致しない可能性がある[26][30]。
  • 被害:2026年10月23日時点で、確認した公開情報の範囲では、PHP2Shellを原因とする被害を公表した国内組織は確認できなかった。CISAのKEV(悪用が確認された脆弱性の一覧)にも未登録である[12][31]。
  • 3層からの示唆:止める範囲と戻す速さには、第1層(資産管理・EOL管理)の成熟度が大きく影響したと考えられる。今回は、防御側のAIを活用した脆弱性発見と協調開示によって、修正準備の時間を確保できた事例である。ただし、攻撃側より防御側が常に先行できることを示すものではない。次は「攻撃側のAIが先に見つける」前提で、第2層(侵害前提の封じ込め)と第3層(VulnOps・CTEM)を同時に育てる必要がある。

1. Mythosレディの3層モデル

「Mythos」は、Anthropicが2026年4月に発表したAIモデル「Claude Mythos Preview」に由来する。このモデルが、脆弱性の発見から攻撃コードの作成までを機械の速度で行えることを示したことを受け、CSA・SANS・OWASPなどが2026年4月に緊急公開した文書「AI脆弱性の嵐(AI Vulnerability Storm):『Mythosレディ』なセキュリティプログラムの構築」[36]が、「Mythosレディ」という言葉を広めた。同文書は言葉を明示的には定義していないが、AIによる脆弱性発見の急増に備えて、今すぐ取り組むべき対策を示している。

以前のブログ「Mythosレディとは何か」[33]は、同文書を踏まえ、これを「機械速度の攻撃が常態化した世界において、組織が生存できる状態を継続的に維持すること」と定義している。特定のAIモデルへの対抗策ではなく、その背後にある構造的なリスクに継続的に適応し続けられる組織の状態である。PHP2Shellでも、発見に使われたのはMythosではなく、他社のAIモデルだった[1][3]。

同シリーズでは、Mythosレディの目的を「コントロール可能な状態」、すなわち攻撃を100%防ぐことは不可能でも、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することに置いている[33][37]。そして、それを実現する道筋として、基本的なセキュリティ対策、ゼロトラスト、VulnOps・Agentic Control Planeの3層を定義している[37]。本書でも、この枠組みに沿ってPHP2Shellを評価する。

層主な内容役割
第1層
基本的なセキュリティ対策
資産管理、パッチ適用、ログ収集と保全、バックアップと復旧手順、インシデント対応手順他の層が機能するための土台。守る対象が分からなければ何も守れない
第2層
ゼロトラスト
守るべき資産(プロテクトサーフェス)ごとに「信頼せず、常に検証する」設計。最小権限、セグメンテーション、継続的な監視侵入される前提で、被害を封じ込め、攻撃者の難易度を構造的に上げる
第3層
VulnOps・CTEM・Agentic Control Plane
悪用される前に脆弱性を見つけ、事業への影響で優先順位を付けて直し続ける運用。AIを防御側にも組み込み、AIエージェントを統制する攻撃側と同じ速度で動き、誰が見つけた脆弱性でも、攻撃者より先に塞ぐ

なお、3層モデルは続編[37]で定義したもので、基本対策の重要性は第1回[33]、第3層のVulnOpsとCTEMの具体的な実装は続編-2[34]で詳しく論じている。この3層は「順番に完成させる」のではなく「同時に育てる」。第1層のログ基盤が第2層の継続的検証を支え、第2層の守るべき資産の定義が第3層の優先順位を決め、第3層で見つかった脆弱性が第1層のパッチ適用と第2層のポリシーに反映される。この循環が回っている状態がMythosレディである[37]。

2. PHP2Shellの概要

2.1 何が起きたか

  • 規模:PHP 5.4以降、修正版より前のバージョンが、2件のCVEの少なくとも一方の影響を受ける。影響を受けるCVEはバージョンによって異なる。PHPは世界のWebサイトの約70%で使われ、WordPress、Drupal、MediaWikiなどの土台になっている[1]。
  • 性質:本脆弱性はPHP本体のリクエスト処理に起因するため、アプリケーション側の認証・入力検証だけでは根本的に解消できない。攻撃の成立条件やリスクは、PHPの実行方式(mod_php、PHP-FPMなど)や構成も踏まえて評価する必要がある[1][23]。
  • 影響:認証なしで任意コード実行(RCE)に至る可能性があるほか、他のリクエストのパスワード、トークン、APIキーを含むプロセスメモリを読み出せる可能性がある[1]。
  • 修正:PHP 8.5.12、8.4.27、8.3.36、8.2.35で修正。PHPの開発チームによる更新の対象外だったが、7.4・8.0・8.1には例外的なソースのバックポートが公開された[23]。

「PHP本体に起因する」ことの何が問題か

通常の脆弱性はアプリ(WordPressやEC-CUBE、自社開発のシステムなど)のコードの中にあり、アプリ側の対策で守ることができる。PHP2Shellは、PHP本体がリクエストを受け取って処理する段階に原因がある。このため、次の問題が生じる。

  1. アプリ側の対策だけでは防げない:入力チェック、ログイン認証、フレームワークのセキュリティ機能は、アプリのコードが動いて初めて効く。PHP2Shellは、構成によってはアプリのコードが動く前に成立し、PHPの開発チームは、セキュリティアドバイザリで、Apacheのmod_phpでそれを実証したと説明している[23]。アプリをどれだけ堅牢に作っても、それだけでは根本的な解決にならない[1]。
  2. アプリを最新にしても防げない:WordPressやEC-CUBE、プラグインを最新にしても、サーバのPHPが古いままでは防げない[31]。「CMSは最新だから大丈夫」という判断が通用しない。
  3. 直す責任がアプリの担当者の手を離れる:修正はPHP本体の更新でしか行えず、担当はサーバの管理者、レンタルサーバー事業者、委託先になる[31]。アプリの担当者やサイトの所有者が自分で直せない場合が多く、日本で「止める」以外の選択肢を持てなかった組織が多かった一因でもある。
  4. 見つけにくい:PHP本体の処理で起きるため、アプリのログにはほとんど手がかりが残らない可能性がある[1]。異常なリクエストやメモリ上限エラー、PHPのワーカーの異常終了など、サーバやプロセスの単位で見張る必要がある。
  5. 影響範囲が「PHPを使うものすべて」になる:特定のアプリの欠陥ではないため、PHPで動くものはアプリの種類を問わずすべて対象になる。PHPは他のソフトや機器に同梱されていることも多く、自社がPHPを使っていると認識していない場所まで影響が及ぶ[16]。

これを3層との関係でみると次のようになる。資産の把握をアプリやCMSの単位で止めず、その下で動く言語処理系やライブラリの単位まで持つ必要がある(第1層)。アプリの防御を越えられる前提で、サーバ上の権限やデータを最小化して被害を封じ込める(第2層)。検知もアプリのログだけに頼らず、サーバやプロセスの振る舞いで行う(第3層)。

2.2 発見から公開までの経緯

発見者は複数いる。最初に見つけたのはOpenAIの取り組みに参加していたCalif(8月1日)で、OpenAI自身とWizもそれぞれ独立に同じ問題にたどり着いた[2][3]。

日付(2026年)出来事
7月30日Califが監査を開始[2]
8月1日Califの説明による発見日[2]
8月11日Califの研究者が無条件のRCEを報告。同日、OpenAIも同じ根本原因を独自に報告[2][5]
8月14〜15日CalifがRCEのPoCをPHPに共有し、PHPが確認[2]
8月19日Wizが独自に発見(Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを使用)[1]
8月24日WizがPHPに報告[1]
9月18日OpenAIが追加の攻撃経路を報告[2]
9月21日PHPが報告を受理し、協調した修正の開発に着手[1]
10月17日最初の悪用の試みをAmazonが観測(公開の4日前)[10]
10月20日脆弱性の存在とCVE番号がオンラインでリーク[7][14]
10月21日予定を1日前倒しして修正版を公開(日本時間22時台。予定は23時)[7][26]
10月23日PHPが、21日の修正版では直らない別のセッション処理の欠陥(CVE-2026-115560)を公表[12](詳細は3.3)

OpenAIは、こうした最先端のAIが攻撃者より先に脆弱性を見つけたことで、PHPの開発チームやセキュリティ事業者が、公開前に修正と防御策を準備できる期間(「Defender’s Window」=防御側の窓)が生まれたと説明している[3][32]。Cloudflareは公開の9時間前に防御ルールを展開するなど、業界横断の準備が行われた[14]。

2.3 AIが変えたこと

  • 欠陥は10年以上前からあり、2024年の監査でも見つかっていたが、悪用できることは示されていなかった[2]。
  • Wizは、AIによる分析が脆弱性の理解や、実際に動作する攻撃コードの作成・標的ごとの調整を支援したと説明している。複数の欠陥をつなぎ、標的ごとのメモリ配置に合わせて調整する作業を、AIの支援で数時間のうちに行えたという。Wizによれば、1人の研究者が1週間で、以前なら一流チームが数か月かかる作業を終えた[1]。
  • Wizは、AIによって攻撃コードの作成と標的ごとの調整の手間が下がり、複雑さはもはや防壁にならない可能性があり、「実際に悪用可能」の定義が変わると指摘している[1]。これを踏まえると、これまでの「人間が現実的な手間で攻撃コードを作れるか」という判断に加えて、「欠陥が存在し、外部から届くか」を重く見る必要があると考えられる。「悪用は困難」として後回しにされてきた脆弱性も、狙われる対象になりうる。

2.4 補足:CISAの「自動化可能性」評価

CISAは「Vulnrichment」というプログラムで、公開されたCVE記録に優先順位付けのための情報を追記している。その簡略版SSVCには「悪用状況」「自動化可能性(Automatable)」「技術的影響」の3つの判断項目がある。自動化可能性は、その脆弱性を自動で悪用でき、大量の攻撃が起こりうるかを問う項目である[9]。

PHP2Shellの公開時の記録では、悪用状況は「観測なし」、自動化可能性は「No」で、CVSSでも攻撃の複雑さは「高」とされていた[8]。これはメモリ破壊型の脆弱性として一般には妥当な評価である。ただし、Wizの研究で示されたように、AIが標的ごとの調整を支援できるようになったことは、従来の自動化可能性の評価の前提を見直す理由になる[1]。一方で、本件で攻撃全体の大量自動化が実証されたわけではなく、CISAの評価がAIによって無効になったと断定することはできない。

これらを踏まえて、公的機関の評価や点数は、公開時点の、人間の攻撃者を前提にしたスナップショットにすぎず、AIの時代には、それを鵜呑みにせず、自社の環境で継続的に評価し直す仕組み(CTEM)が必要であると考える。

3. 悪用の状況とAmazonの分析

3.1 Amazonの観測(MadPot)

Amazonは、自社の大規模なハニーポット網MadPotでの観測結果を公表した。毎分2,000億件を超えるイベントを分析し、MadPotからの脅威情報と組み合わせて攻撃を検知・遮断しているとしている[10]。

日時(UTC)日本時間観測内容[10]
10月17日10月17日最初の攻撃の試み。商用の匿名化ネットワークに関連するIPから。攻撃者による活動とみられるが、公開前に情報をどう入手したかは不明
10月21日 02:0021日 11:00最も早いPoCを確認
10月21日 02:00〜08:0021日 11:00〜17:00別の匿名化基盤からの攻撃が続く。ペイロードも手段もばらばらで、複数の攻撃者とみられる。成功したかは不明
10月21日 14:0021日 23:00情報公開の解禁とパッチ公開
解禁後 数時間22日未明追加のPoCが次々に現れ、ほぼ即座にセンサーへの攻撃に使われる

なお、Amazonは、識別した6つのIPアドレスを公表したが、これらは匿名化のための共有基盤であり、遮断ではなく、観測された場合の調査に使うよう求めている[10]。

3.2 Amazonが示した教訓と、見直すべき前提

教訓1:公開日まで情報を伏せておく取り決め(エンバーゴ)が防御側を守るのは、他の誰かが同じバグを見つけるまでに限られる。協調開示は今も正しいやり方だが、公開日を最も早い悪用の日と考えてはいけない。PHP2Shellでは、公開前に侵害されている可能性がある[10]。

教訓2:パッチから攻撃コードまでの時間は、構造的に縮んでいる。かつては少数の能力ある攻撃者が攻撃コードを作り、他はそれを待つ構造だったが、AIによる分析でパッチの差分やアドバイザリーから攻撃コードを作るのが簡単になり、数時間から数分で動ける攻撃者が増えている[10]。

見直すべき前提[10]内容
修正期限は時間単位で測る脅威インテリジェンスを公表したAmazonは、7日・30日の修正期限では、インターネット公開システムの重大脆弱性への対応に十分な猶予を確保できないと指摘した[10]
調査は最も早い悪用の日から公開日ではなく、最も早く悪用が確認された日から調査する。PHP2Shellなら少なくとも10月17日から
シグネチャに頼らない検知最初の悪用は、特定のCVE向けのシグネチャができる前に来ることが多い

これを踏まえ、インターネットに公開された重大脆弱性では、攻撃が修正公開前または公開直後に始まる可能性を考慮し、従来の一律的な日数ベースの期限だけでなく、露出状況・悪用情報・事業影響に基づく時間単位の対応基準を設ける。

3.3 公開後の状況

  • Cloudflareは、公開から45分で数万件、2時間で数十万件、10月22日早朝には数百万件の攻撃の試みを観測した。23日時点で3,440万以上のPHPサービスがなお脆弱とみられる[11]。
  • 攻撃者が管理するサーバ上で、PHP 8.4.26とApacheのmod_phpを狙った攻撃ツールと、標的のPHPのバージョン、サーバ構成、セッション設定、エラー表示の有無などが攻撃の前提条件を満たすかを調べるスクリプトが確認された。このツールは、メモリの漏えいを使ってASLR(メモリ上の配置をランダムにして攻撃を難しくするOSの防御機能)を回避する仕組みだった。報道によれば、調べられたサイトでは10月22日時点でシェルアクセスの証拠はなく、前提条件を満たしていなかったとみられる。この時点では、攻撃者のツールが成功するのは特定のバージョンや構成に限られていた可能性が高い[11]。
  • 一方、VulnCheckの研究者は、PHPが推奨する本番向けの設定(エラーを画面に表示しない設定など)でも、ASLRを回避してRCEを成立させる手法を示した。攻撃者のツールより広い条件で攻撃が成立しうることを意味し、攻撃者が同様の手法を取り入れれば、成功する範囲が広がるおそれがある。ただし、確実なRCEは当初の想定より難しいとの見方もあり、状況は流動的である[11]。
  • 10月23日時点で、CISAのKEVには2件とも未登録[12]。
  • 10月23日、PHPは別のセッション処理の欠陥(CVE-2026-115560)について情報提供の告知を出し、次の定期修正版が出るまでアップロード進捗機能を無効にしておくよう勧めた[12][13]。PHP自身はこのリスクを「起こりにくい」と評価しており、悪用には特殊なアプリの作りが必要で、悪用も報告されていない[35]。アップロード進捗機能は、ファイルのアップロード中に進み具合を表示するためのもので、多くのサイトでは使われておらず、無効にしても通常の動作に影響はない。ただしPHPの標準設定では有効になっており、サイトが使っていなくても外部からのリクエストで動かせてしまうため、設定を確認して無効にしておくとよい[1][13][15]。

4. 海外の対応

  • 英国:NCSCの警告を受け、自治体やロンドン警視庁のサイトが停止。NCSCは、すぐにパッチや緩和策を入れられない場合はオフラインも検討するよう呼びかけた[17]。
  • オランダ:行政ポータル[19][20]、市民が自分の個人データを確認するポータル、下院、NCSC自身、データ保護当局のサイトなどが停止[18]。認証基盤DigiDも止まり[20]、ロッテルダム港、サッカー協会、多数の病院も停止した[19]。
  • その他の欧州:フィンランドでは国のIT機関が政府の公開ウェブサービスを停止、フランスは内務省が自治体の行政サイトを停止、ドイツでも連邦のIT機関がサイトを停止[17]。デンマークでは全国の学校連絡プラットフォームにも影響[21]。スイスのホスティング事業者が顧客ポータルやWebメールを含めて停止し、Wikipediaも一時停止した[19]。
  • 欧州以外:カナダの担当相が一部サイトの一時停止を公表し、オーストラリアではサイバーセキュリティセンター自身も影響を受けた[20]。
  • 当局の方針:EUのCERT-EUは、すぐに更新できない場合は一時的にサイトを止めるよう助言[19]。米国のNSAと欧州のサイバーセキュリティ機関は即時対応を求め[6]、CISAもすぐにパッチを当てるよう呼びかけた[16]。
  • 停止の意味:止めた組織は侵入の兆候はないと説明しており、停止の一覧は被害の数ではなく、各組織の慎重さを表している[18]。
  • 資産把握の差:PHPの所在を把握している組織は必要な部分だけを止め、把握していない組織は全部を止めた結果、ウィーンではWebメールまで止まった、という指摘がある[18]。
  • 保険:英国の保険業界は、多数の契約者が同時に影響を受ける「集積リスク」として注視し、侵害がないまま自ら止めた場合に事業中断の補償が出るかも論点になっている[17]。

5. 日本の対応

5.1 時系列(日本時間)

日時出来事
21日 日中IPAが同日23時の修正版公開を予告し、PHPの利用状況を確認して速やかに適用できるよう準備を要請。攻撃は確認しておらず予防的な発信と説明[25]
21日 14時〜19時コドモンが14時ごろに全サービスを停止。BASEが15時50分、エックスサーバーが16時に公式サイトや管理画面を停止。19時にニコニコ、pixiv、ConoHa WINGなどが続く[26]
21日 21時44分/55分国家サイバー統括室(NCO)、続いて高市首相がXで対応を呼びかけ。首相は「今夜に対応して頂きたい大至急のお願い」とし、すぐ適用できない場合はサイトの一時停止も有効策の一つとした[26]
21日 22時台PHPの修正版が公開(予定は23時)[26]
21日深夜〜22日朝pixivが23時30分、コドモンが3時22分、BASEが8時に再開[26]
22日 日中国税庁が10時20分ごろに停止し16時10分ごろに再開[26]。気象庁なども一時停止[27]。官房長官は、政府系機関や基幹インフラの被害は現段階で報告されていないと述べた[26]
22日 13時11分JPCERT/CCが注意喚起。パッチ適用に加えて侵害の有無の調査を要請し、痕跡がなくても攻撃を受けていないとは断定できないとした[26]
23日 14時アシュアードの集計で停止告知は累計502件、再開告知を確認できたのは217件[30]

5.2 停止の規模と分野

  • 件数:X上の停止告知は502件、うち285件(約6割)は再開告知が未確認。ただし再開してもXで告知していない組織や、Xで停止を告知していない組織は反映されておらず、全体を網羅した数字ではない[30]。
  • 省庁:国税庁と気象庁のほか[27]、財務省と厚労省も一部サービスを停止[28]。
  • 自治体:札幌市が公式ホームページを止めて簡易サイトに切り替え、大阪府も検索機能を制限[28]。三重県では26サイトの公開や一部機能を停止し、8市6町にも影響[29]。
  • 金融:三菱UFJ銀行がネットバンキングの一部取引を停止し、地銀も一部アプリを停止、みずほ銀行も臨時メンテナンスを実施。一方、全国銀行協会は金融機関をつなぐオンラインシステムには影響がないと説明しており、止めたのは決済ではなく周辺サービスが中心だった[31]。
  • 交通・インフラ:JALはWebサイトの一部を予防的に閉じ、予約や運航への影響はないとした。九州電力はホームページを停止し、再開予定を延期した[31]。
  • サービス終了:古い仕組みで十分な対策が取れないとして、ゲーム2本がサービスを終了した[31]。

5.3 被害の状況

22日昼、バルテックが顧客情報流出の可能性を公表し、当初は原因を「PHPの脆弱性を標的とした攻撃」としていた[26]。しかしその後、これは誤報だったと訂正し、原因は自社サービスの脆弱性だと説明している。2026年10月23日時点で、確認した公開情報の範囲では、PHP2Shellを原因とする被害を公表した国内組織は確認できなかった[31]。

5.4 ホスティング事業者の対応の差

対応の型例[26]
利用者のサイトを止めずに更新さくらインターネット(21日23時からのメンテナンスで数秒程度の接続断のみ)、mixhost、カラフルボックス、Value-domain系、エックスサーバー(PHP 8.2〜8.5)
一時停止して更新し、再開ロリポップ!、ヘテムル、ムームー(22日午後までに再開)
利用者に判断を委ねるKAGOYA(事業者側では利用者のサーバーを止めず、修正版の適用を調整する間、利用者にサイトの公開停止やアクセス制限の検討を求めた。22日夕方時点)

PHPの開発チームは、Linuxディストリビューションなどに事前に修正を渡していたとされ、この準備を日頃の運用に組み込めていたかで、止める範囲が変わったと指摘されている[26]。

古いバージョンの扱いも分かれ、さくらインターネット、mixhost、カラフルボックス、ヘテムルなどは、サポートが終わったバージョンにも独自に修正を入れた。こうした修正ではバージョン番号が変わらない場合があり、番号だけでは修正済みか判断できない[26]。

6. 日本と海外の比較

この比較は、10月23日までに公開された報道や各組織の告知に基づくものであり、各国・各組織の対応能力を網羅的に測定したものではない。報道の多い事例に偏っている可能性がある点に留意されたい。

観点日本欧州米国
トップの発信首相とNCOがXで深夜に直接呼びかけ。サイト停止も有効策と明言[26]英NCSC、CERT-EUが「更新できなければオフラインも」と助言[17][19]CISA、NSAが即時対応を要請[6][16]
政府機関の停止国税庁、気象庁、財務省、厚労省、自治体[27][28]オランダの行政ポータル、フィンランドの政府サービス全停止、英仏独の行政サイト[17][18]確認した範囲では、連邦政府サイトの大規模な停止の報道は見当たらなかった
民間の停止502件超の告知。銀行、交通、EC、ゲームなど[30][31]病院、港湾、報道機関、ホスティング事業者、Wikipedia[19]確認できず
悪用の観測10月23日時点で、公的機関による国内の攻撃観測データの公表は、確認した範囲では見当たらなかった。民間では、独自の観測網での観測を公表した企業があるオランダのNCSCは、公開前の時点では悪用を確認していないと説明した[18]Amazonが公開4日前から、Cloudflareが公開直後から攻撃の試みを観測した[10][11]
侵害調査の呼びかけJPCERT/CCが調査観点を提示[26]確認できずAmazonが「10月17日から遡って」と起点を明示[10]
確認された被害PHP2Shellを原因とする被害の公表は確認できず(23日時点)[31]停止組織は侵入の兆候なしと説明[18]KEV未登録(23日時点)[12]
復旧約6割はX上で再開告知が未確認(実際の停止継続件数とは一致しない可能性あり)。サービス終了も[30][31]確認できず大規模な停止の報道が見当たらないため、比較の対象なし

比較から見えること

  • 共通点:止めた範囲には、資産の把握度が大きく影響したと考えられる。欧州でも、PHPの所在を把握していない組織は全部を止めたと指摘されている[18]。日本でも、復旧が長引く要因として、自社や委託先で使っているPHPのバージョンの特定作業とEOL対応が挙げられている[30]。
  • 日本の特徴1:「止める」は速く、「戻す」に時間がかかった。首相とNCOの呼びかけもあり予防停止は素早く広がったが、23日時点でX上の再開告知が確認できないものが約6割あった。実際に停止が続いている件数とは一致しない可能性があるものの、夜のうちに更新を終えた組織と、止めたまま長引く組織の差が大きい[26][30]。
  • 日本の特徴2:委託先・ホスティング事業者への依存。レンタルサーバーやCMS提供元の対応で、利用企業ができることが大きく変わった。自社で直せない組織は「止める」以外の選択肢を持てなかった。
  • 日本の特徴3:国内の攻撃観測データの公表が少ない。海外では事業者が自社の観測データで「いつから、どれだけ」を示したが、確認した範囲では、日本の公的発信は「対応してください」が中心で、脅威の強さの判断を海外のデータに頼っている。

7. 3層に照らした評価

PHP2Shellは、3層のすべてを同時に試した事案だった。各層で何が試され、日本でどうだったか、今後どう変えるかを整理する。

層PHP2Shellで試されたこと日本の状況(観察)今後の変え方
第1層
基本対策
PHPがどこで、どの版で動いているかを即答できるか。PHPは他のソフトや機器に同梱され、気づかない露出が生まれやすい[16]。CybelAngelの調査では、約224万のインターネット公開PHPホストのうち、バージョンを確認できた約150万台の59%が、修正版の公開前の時点で修正提供の見込めないバージョンを使用していた[15]。今回は、PHPの開発チームによるサポート終了版(7.4〜8.1)への例外的なバックポートや、OSの配布元・ホスティング事業者による独自の修正が提供されたが[23][26]、こうした例外的な対応が次も得られるとは限らない止めた後の再開に時間がかかり、X上で再開告知が確認できないものが約6割あった(実際の停止継続件数とは一致しない可能性あり)[30]。古い環境のサービスは終了に至った[31]。委託先・ホスティング事業者に依存資産台帳を言語処理系・ライブラリ単位(SBOM)まで下げる。EOLは「修正が届くかどうかを自分で決められない資産」として扱い、撤去期限を設ける。外部公開の重大脆弱性は、日数ベースの期限に加え、露出状況・悪用情報・事業影響に基づく時間単位の対応基準を設ける。委託契約に緊急時の対応時間を入れる。ログを遡って調査できる期間保存する
第2層
ゼロトラスト
PHP本体に起因するため、アプリ側の防御だけでは防げない。メモリから資格情報が漏れる可能性がある[1]封じ込めの主な手段が「サイトを止める」になった。GMO Flatt Securityは、侵害時に備えた権限とデータの最小化を推奨[22]侵入される前提で、サーバ上のデータとIAM権限を最小化。シークレットを短命化しサーバに置かない。外向き通信の制限とセグメンテーションで横展開を止める。「止める範囲を小さくできる」設計にする
第3層
VulnOps・CTEM
数時間で判断し動けるか。シグネチャ前に検知できるか。CVSSや「自動化不可」の評価を鵜呑みにしないか[8][10]JPCERT/CCが侵害調査の観点を提示[26]。夜のうちに更新を終えた事業者とそうでない組織で差。国内の攻撃観測データは乏しいCTEMで外部公開面と事業影響を常時評価し、外部ソフトの脆弱性は通知を受けたら数時間で塞ぐか止める。振る舞い検知と自動遮断。仮想パッチを即日配る経路。停止の基準と決裁者を事前合意。自社開発のコードはAIでリリース前に診断

3層の重心を、「パッチを早く当てる」(第1層)だけから、「パッチがない期間を生き延びる」(第2層・第3層)へ広げる。ただし、第2層・第3層は、パッチがない期間のリスクを低減するものであり、脆弱性の根本修正を代替するものではない。修正版が出たら速やかに適用することが前提である。また、止める範囲と戻す速さには第1層の成熟度が大きく影響したと考えられ、3層は同時に育てる必要がある。

8. 攻撃側のAIが先に見つける時代への備え

今回は防御側が約2か月半先行できた。しかし、異なる組織が、それぞれAIを使って同じ欠陥にほぼ同時期にたどり着いた事実は、攻撃側も同じものに到達しうることを示している。さらに、リークと公開前の悪用の試みで、その先行期間は想定より早く閉じた[10]。次は、攻撃側のAIが先に見つけ、パッチが存在しない期間に攻撃される前提で備える必要がある。

  1. 露出を減らす:インターネットに出ている面を棚卸しし、不要な公開、EOL、管理外のサーバを消す。攻撃側のAIは面が広いほど有利になる。
  2. ゼロデイ前提の封じ込め:最小権限、シークレットをサーバに置かない設計、外向き通信の制限。パッチがなくても「乗っ取られても被害はここまで」と言える状態にする。
  3. 振る舞いで検知し、自動で止める:シグネチャのない攻撃に備え、サーバのプロセスの異常終了や再起動の多発、メモリ上限エラーやHTTP 500の多発、予期しないシェルの起動など、ふだんと異なる振る舞いを検知して遮断する。PHP2Shellでも、PHPのワーカー(リクエストを処理するプロセス)の異常終了が兆候として挙げられた[1][10][26]。
  4. 仮想パッチを即日展開できる経路:WAFやCDNのルールを数時間で全体に配れるようにする。ただしWAFやIPSは本体の修正の代わりにはならない[23]。
  5. 「止める判断」を事前に決める:停止の基準、決裁者、顧客への連絡手順、サイバー保険の条件を経営として事前に合意しておく[17]。
  6. 自社のコードはAIで先に探す:自社で開発したシステムは、ソースコードを持つ防御側が有利であり、AIによる診断を開発の流れに組み込めば、リリース前に脆弱性を見つけられる可能性が高まる。一方、PHPのような外部のソフトウェアの脆弱性を自社で先に見つけることは現実的ではない。外部のソフトウェアについては、発見を待つのではなく、通知を受けたら影響範囲を即座に特定し、数時間で塞ぐか止められる状態にしておく。これが第3層の役割である。

振る舞いの検知と自動遮断を支える仕組み

上記3つ目の「振る舞いで検知し、自動で止める」は、次のような仕組みを組み合わせて実現する。

種類役割PHP2Shellとの関係
サーバ用のEDR・ランタイム保護サーバ上のプロセスの動きを常時監視し、不審な動きを検知して、プロセスの停止やサーバの隔離を自動で行う「Webサーバのプロセスからシェルが起動された」などの動きを直接捉えられる。中心となる仕組み
ログとメトリクスの監視エラーログ、アクセスログ、メモリ上限エラーなどを集め、ふだんより急に増えたら警告するワーカーの異常終了やHTTP 500の急増に気づける。自動で止めるには、次の自動対応と組み合わせる
自動対応の仕組み警告を受けて、該当サーバを切り離す、送信元を遮断するなどの対応を自動で実行する気づいてから止めるまでの時間を縮める
OSの強制アクセス制御Webサーバのプロセスがシェルを起動できないよう、あらかじめ制限する検知ではなく予防。乗っ取られても攻撃者ができることを減らす
WAF不審なリクエストの急増を検知して遮断する未知の攻撃はシグネチャがないと見逃す場合があり、本体の修正の代わりにはならない[23]

PHP2Shellは構成によってはアプリのコードが動く前に成立するため、アプリの中に組み込む防御では捉えられない場合がある。サーバやOSの単位で見張る仕組みの方が向いている。

導入にあたっては2点に注意する。第一に、レンタルサーバーやISPにサーバの管理を任せている場合、これらの多くは利用者側では導入できない。事業者がこうした監視や自動遮断を行っているかを確認するのが現実的である。第二に、自動で止める仕組みは、誤検知で正常なサービスを止めてしまうおそれがある。最初は「検知して通知」から始め、誤検知の傾向を見てから自動遮断に進めるのが一般的である。

9. 対策を経営判断にする: PHP2Shellを使った経営層への説明

7.と8.で挙げた対策の多くは、現場の判断だけでは進められない。時間単位の対応基準を設けること、サービスを止める基準と決裁者を決めること、委託契約に緊急時の対応時間を入れること、そしてVulnOps・CTEMの体制に投資することは、いずれも経営の判断を必要とする。PHP2Shellでは、国内外の多くの組織が深夜に「止めるかどうか」の判断を迫られた。こうした判断を平時に済ませておくには、経営層の理解が欠かせない。

しかし、VulnOpsやCTEMという言葉は、一般にはわかりにくい。そこで本節では、用語から入るのではなく、PHP2Shellという具体的な事案を題材に、経営層に何を問い、何を報告してもらうかという形で説明する方法を示す。

出発点は、PHP2Shellの情報がリークした10月20日から23日までの約72時間で、経営に問われた3つの質問である。

#経営に問われた質問問われた力
1うちでPHPが動いているサーバやサービスは、どこに、いくつあるのか?可視化(資産把握)
2そのうち、止まると売上や顧客に響くのはどれか?事業影響の評価(優先順位付け)
3何時間で直したのか。止める判断は誰がしたのか?修正と意思決定の速さ

CTEMは「この3つの質問に、平時から常に即答できる状態を保つ経営の仕組み」、VulnOpsは「それを毎日回す運用チームと手順」と説明できる。

言い換えの例

  • 健康診断から24時間モニタリングへ:年1回の脆弱性診断は健康診断にあたる。発見から悪用までが数時間になった今は、常時モニタリングと「即入院の判断基準」が要る。
  • 点数ではなく、自社にとっての危険度で並べる:今回は、攻撃の複雑さが「高」、自動化可能性が「No」とされた欠陥でも、AIの支援で攻撃コードが作られ、公開直後から大量の攻撃の試みが観測された[1][8][11]。CVSSの点数順ではなく、「公開されているか」「重要業務か」「実際に悪用可能か」で順位を付ける。
  • Amazonの発言を使う:脅威インテリジェンスを公表したAmazonは、7日・30日の修正期限では、インターネット公開システムの重大脆弱性への対応に十分な猶予を確保できないと指摘した[10]。自社の規程の修正期限と並べて示し、外部公開の重大脆弱性について、露出状況・悪用情報・事業影響に基づく時間単位の基準が必要なことを伝える。
  • お金の言葉に置き換える:「数時間の計画停止のコスト」と「侵害されたときの情報漏えい・長期停止のコスト」を比べる。今回、予防的に止めた組織は前者を選んだ。

経営に報告してもらう指標(月次)

指標意味
外部公開資産のうち台帳にあるものの割合「どこに何があるか」を把握できているか(質問1)
重大脆弱性を修正・緩和するまでの時間外部公開の重大脆弱性について、時間単位の対応基準を守れているか(質問3)
EOLソフトの残存数と撤去期限修正が届くかどうかを他者の例外的な対応に頼っている資産がどれだけあるか
停止判断にかかった時間止める決断を自社で速く下せるか(質問3)
停止から再開までの時間戻す力。第1層の成熟度を反映しやすい指標

10. まとめ

PHP2Shellは、防御側のAIを活用した脆弱性発見と協調開示によって、修正準備の時間を確保できた事例である。ただし、攻撃側より防御側が常に先行できることを示すものではない。実際、リークと公開前の悪用の試みで、確保した時間は想定より早く失われ、国内外で大規模な予防停止が起きた。日本では、止める判断は速かったものの、戻すまでに時間がかかる組織が多く、資産把握とEOL管理という第1層の課題が表れたと考えられる。

次は攻撃側のAIが先に見つける前提で、第1層の土台を固めつつ、第2層の封じ込めと第3層のVulnOps・CTEMを同時に育てる必要がある。経営層には、「3つの質問に即答できる会社にしておく」ことを目標として示すのが有効である。

注:本書は2026年10月23日までの公開情報に基づいている。悪用状況や被害の報告は今後変わりうるため、判断の際は各機関・事業者の最新の発表を確認されたい。

参考資料

以上

「AI脆弱性の嵐」から半年 ~ 4月の予測はどこまで現実になったか

2026年10月17日
AIWGメンバー 諸角昌宏

はじめに

2026年4月19日の本ブログで、CSA、SANS、[un]prompted、OWASP GenAI Security Projectなどが共同でまとめた緊急戦略ブリーフィング「AI脆弱性の嵐(AI Vulnerability Storm):『Mythosレディ』なセキュリティプログラムの構築」の日本語版を紹介した[1][2]。Claude Mythos Previewの発表を受けて、AIによる脆弱性の発見と悪用が加速する世界に、組織がどう備えるべきかを示した文書である。

この文書の特徴は、強い危機感と具体的な時間軸にあった。今週着手すること、45日以内、90日以内、12か月以内という区切りで優先アクションを示し、取締役会には「90日計画」を求めた。言い換えれば、「四半期の単位で動かなければ間に合わない」という見立てである。 それから約半年がたった。日本では9月下旬から、不正アクセスによる情報漏えいの公表が連日のように続き、10月にはJPCERT/CCが一連の事案の攻撃者によるAIの利用を確認したと公表した。本ブログでは、4月の文書が何を予測し、何を求めていたかを原文に沿って振り返り、この半年で何が現実になり、何が予測と違ったのかを整理してみたい。

1. 4月の文書は何を予測していたか

原文は、次のような見通しを示していた[2]。

論点原文の記述(要旨)
能力の拡散同等の攻撃能力は、他のフロンティアモデルには数か月以内に、オープンウェイトモデルには6か月から1年以内に現れる
悪用までの時間脆弱性の公開から悪用までの時間は分単位に短縮されている。いわゆる「ゼロデイ・クロック」は2026年に1日を切った
脆弱性の量脆弱性の公表の頻度と量は、これまでに経験したことのない水準になる
攻撃の担い手平均的な犯罪者が、かつては国家レベルの資源が必要だった能力を持つようになる
インシデント同じ週に複数の重大インシデントが同時に起きる事態を想定した机上演習を行うべき
影響ただし、悪用までの時間の短縮は、まだ悪用の影響の比例的な増大にはつながっていない

最後の一文にも注目しておきたい。4月の時点では、「速度の変化はすでに起きているが、被害の規模にはまだ表れていない」という認識だった。この点が半年後にどう変わったかは、後述するとおり、事故の増加とAIとの関係が明確になっていない現時点では判断できない。

そのうえで文書は、11の優先アクションに着手時期と完了の目安を付けている。

優先アクション着手目安
1. コードとパイプラインにAIエージェントを向ける今週継続
2. AIエージェントの導入を必須にする今週継続
3. 自組織のエージェントを守る今月45日
4. イノベーションと加速のガバナンスを整える今週6か月
5. 継続的なパッチ適用に備える今週45日
6. リスクモデルと報告を更新する今週45日
7. アタックサーフェスを棚卸しし、縮小する今月90日
8. 環境を堅牢化する今月6か月
9. ディセプション(おとり)の能力を作る90日以内6か月
10. 自動対応の能力を作る90日以内12か月
11. VulnOpsを立ち上げる6か月以内12か月

4月から数えれば、45日の目安は5月末、90日の目安は7月中旬にあたる。9月下旬の時点で、アクション3、5、6、7はすでに目安を過ぎ、1と2は着手から5か月がたっている。さらに、6か月が目安のアクション4、8、9も、一連の事案のさなかの10月中旬に期限を迎えている。

2. この半年で現実になったこと

2.1 能力の拡散は、予測どおりか、それより早く進んだ

英国AI安全研究所(AISI)は4月30日、GPT-5.5の初期版の評価結果を公表した。専門家レベルのサイバータスクの平均合格率は、GPT-5.5が71.4%、Mythos Previewが68.6%で、ほぼ同水準だった[3]。IPAの「AIセキュリティ短信」2026年9月号は、AIのサイバー攻撃能力が初めてOpenAIの基準で「Critical」水準に達したことを取り上げている[4]。「他のフロンティアモデルには数か月以内」という予測は、ほぼそのとおりに進んだ。

より注目すべきは、攻撃の現場で使われているAIである。Gambit Securityが9月に公表した暫定報告では、攻撃者は3種類のオープンソースのAIエージェントツールを組み合わせ、脆弱性の探索から侵入、データの持ち出しまでの大部分を自律的に実行させていた。1標的あたりのコストは平均で約25ドルにすぎない[5]。AIエージェントを利用することで、一部の攻撃者が比較的低コストで大規模な攻撃を実行できることが示された。これは高度な攻撃能力の利用コストが低下していることを意味するが、平均的な犯罪者が同等の能力を獲得したとまでは断定できない。

2.2 自律的な攻撃が観測され始めた

Google Threat Intelligence Groupは9月、攻撃者のAI利用が「プロンプトで指示する段階から自律へ」移りつつあるとする報告を公表した[6]。IPAの9月号も、AIエージェント群による政府機関への自律的な侵入や、AIエージェントによって企業への侵入が10時間に短縮された事例を紹介している[4]。

そして国内でも、JPCERT/CCが10月15日、一連の不正アクセス事案で攻撃に使用された可能性のあるインフラを調査した結果、「攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました」と公表した[7]。同日の報道では、AIエージェントの使用や、標的の選定からデータの窃取までが自動化されていた可能性に言及している。ただし公表文書は「AIを利用して」という表現にとどまり、個別の事案との対応や、どこまで自律的だったかは示していない。

2.3 「同時多発」は、日本で起きた

4月の文書が机上演習の題材として挙げた「同じ週に複数の重大インシデント」は、9月下旬以降の日本で、ほぼそのままの形で現れた。Aioright Technologiesの集計では、7月1日から10月4日までに検知または公表された確認済みのサイバー攻撃126件のうち、公表月で見ると8月に47件、9月に57件が集中している[8]。なお、件数は公表単位で数えたもので、全数調査ではなく、公表の時期と発生の時期も一致しない。警察庁によれば、2026年上半期のランサムウェア被害の報告件数も123件で、半期として過去最多となった[9]。

委託先1社への侵害が複数の組織の被害につながる事例も目立った。問い合わせ管理システムの提供会社への不正アクセスでは、証券会社、保険会社、製造業者などが相次いで顧客情報の漏えいの可能性を公表している[10]。4月の文書は「サプライチェーンは影響を受ける」と書いていたが、それが具体的な形で表れた。ただし、こうした事案の増加とAIの利用との因果関係は、現時点では示されていない。

2.4 規制当局は「四半期」より速く動いた

金融庁と日本銀行は5月22日、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得るとして、金融機関等に9項目の短期的な対応を、概ね1か月程度を目途に進めるよう要請した[11]。優先システムの特定、技術負債の解消、リスクベースのパッチ適用、停止への備えなど、内容は4月の文書の優先アクションと大きく重なる。要請自身は、これらを「応急的措置」と位置付け、中長期的には脆弱性対応の自動化等への移行が必要としている。さらに金融庁は10月9日、委託先を含むサードパーティのリスク管理の再点検と、ICチップによる本人確認への早期移行を求めた[12]。

3. 予測と違ったこと

一方で、この半年の出来事は、4月の議論がそのまま現実になったわけではないことも示している。

3.1 機械速度は、最先端のAIを待たずに来た

4月の文書の中心にあったのは、機械速度で動く攻撃と、人間の速度で動く防御との非対称性だった。その速度をもたらすものとして想定されていたのは、Mythosのような最先端モデルによる脆弱性の発見と悪用の加速である。しかし、これまでに公表された攻撃で使われていたのは、オープンソースのエージェントツールや一般に利用できるAIだった。機械速度の攻撃は、最先端モデルの能力が広く行き渡るのを待たずに、手頃なAIと既存の手口の組み合わせで現実になった。

3.2 突かれたのは、多くが以前からある弱点だった

JPCERT/CCが確認したAIの用途は、既知の脆弱性のスキャンと、スマートフォンアプリを解析してその裏側にあるAPIの弱点を探す行為だった[7]。推奨している対策も、アプリに秘密鍵を埋め込まない、サーバー側で認証・認可を行う、レート制限と監視を行うといった基本的なものである。Gambit Securityの事例でも、使われたのはSQLインジェクションやファイルアップロード機能の不備、設定ファイルに残された認証情報だった[5]。注意喚起の対象には公開前に悪用された脆弱性に関わるものも含まれるが[13]、全体として見れば、AIが未知の脆弱性を見つけて侵入したというより、既知の弱点を探して突く作業が速く、安く、大規模になったと見る方が実態に近い。

3.3 入口は、自社の中心ではなく周辺にあった

金融分野では、9月下旬以降に公表された主な事案の入口が、自社の中心的なシステムではなく、委託先や周辺のシステムだった[10][14][15]。

事案(公表時期)入口(公表時点)5月の要請との関係
大和証券、損保ジャパン、オリックス生命(10月5〜8日)問い合わせ管理を委託していたFAQシステムの管理サイトへの不正ログイン(アカウントの入手経路は未公表)要請は優先システムを絞り込む構成で、周辺業務の委託先は対象に入りにくい
IDARE(キャッシュレスアプリ、10月中旬)顧客対応などに使う外部ソフトウェアの脆弱性(ソフトウェア名は非公表)要請には、外部のソフトウェアやサービスに預けた顧客データの扱いについての記述がない
内藤証券、大和総研(10月15日)運用を委託しているネット取引システムのWebサーバー(侵入経路は調査中)要請が最優先とした外部公開システム。ただし委託先に関する項目は、パッチ適用作業の契約と役割分担の確認にとどまる

5月22日の短期的要請では、脆弱性への迅速な対応や重要な外部公開システムの保護が重点的に取り上げられた[11]。一方、今回の事案は、委託先や周辺システムに預けた顧客データまで含めて、組織全体のアタックサーフェスとリスクを把握する必要性を改めて示した。なお、金融庁は別途、「金融分野におけるサイバーセキュリティに関するガイドライン」でサードパーティリスク管理を求めており[17]、5月の要請だけをもって委託先対策が欠落していたと評価することは適切ではない。10月9日の注意喚起でも、このガイドラインなどを踏まえ、委託先を含むサードパーティのリスク管理の再点検をあらためて求めている[12]。

一方で、筆者が確認した範囲では、それ以外の部分、つまり銀行の基幹系やインターネットバンキングなど、要請が最優先とした金融機関自身の中核システムが直接破られたという公表は見当たらない。公表がないことは被害がないことを意味しているわけではないし、これを要請の効果と断定する材料もないが、守りを固めるよう求められた中心部ではなく、その外側から入られたという構図ははっきりしている。4月の文書のアクション7(アタックサーフェスの棚卸しと縮小)は、自社のシステムだけでなく、委託先や外部に預けたデータまでを範囲に含めなければならない。

4. 「四半期の行動」は間に合ったのか

では、4月の文書が求めた行動は、この半年に間に合ったのだろうか。各組織がどこまで実行したかを示す資料はなく、実行した組織の被害が少なかったかどうかも検証できない。ただ、9月以降に突かれた弱点と、優先アクションを並べてみると、どの行動が問われたのかは見えてくる。

9月以降の事案で問われたこと対応する優先アクション4月時点の目安
既知の脆弱性の放置5. 継続的なパッチ適用に備える45日
公開されたAPI、アプリ、委託先のシステムの把握漏れ7. アタックサーフェスの棚卸しと縮小90日
認証情報の悪用、横展開8. 環境の堅牢化(フィッシング耐性MFA、セグメンテーション)6か月
影響範囲と復旧速度の評価6. リスクモデルと報告の更新45日
大量・短時間のアクセスの検知と遮断10. 自動対応の能力12か月

問われたのは、新しいAI防御の仕組みではなく、45日から90日で終えるはずだった基本だった。4月の文書が「基本への集中を強めよ」をKey Takeawaysの一つに掲げていたことを、改めて思い起こしたい。

まだ基本ができていない組織へ

この半年で最も大きく変わったのは、攻撃の費用である。1標的あたり約25ドルで自動化された攻撃を仕掛けられるのであれば[5]、「うちは狙われるほどの価値がない」という前提は成り立たなくなりつつある。警察庁の統計でも、2026年上半期のランサムウェア被害123件のうち79件は中小企業だった[9]。規模や業種にかかわらず、基本の穴がある組織は、手頃なAIによる網羅的な探索の対象になると考えるべきである。

4月の文書が45日から90日で求めた基本が、まだできていない組織は少なくないはずだ。そうした組織に必要なのは、次の四半期の計画を立てることよりも、今すぐ着手することであると考える。少なくとも次の点は、新しい製品を導入しなくても速やかに取り組める内容である。

  • 外部から見えるものを棚卸しする:Webサイト、管理画面、API、スマートフォンアプリ、VPN機器に加え、委託先のシステムに預けている顧客データも対象に含める
  • 既知の脆弱性を塞ぐ:特に、すでに悪用が確認されている脆弱性(KEV)を優先して修正する[16]
  • 認証を固める:管理画面と特権IDに多要素認証を導入し、使われていないアカウントやテスト環境を削除する
  • APIとアプリを見直す:アプリに秘密鍵や長期間有効な認証情報を埋め込まない。サーバー側で認証・認可を行い、レート制限と異常なアクセスの監視を設ける[7]
  • 持たなくてよいデータを捨てる:退会者の情報や、目的を終えた本人確認書類の画像など、保有し続ける理由のないデータを削除する

この5項目は、全体として、JPCERT/CCが一連の事案を受けて推奨した対策や、4月の文書の優先アクション5、7、8と重なる。攻撃が機械速度で網羅的に行われる以上、守りの穴は「いつか見つかる」のではなく「すぐに見つかる」と考えて動く必要がある。

5. まとめ:短期の対応が必要だという見立ては裏付けられた

4月の文書が示した短期間での対応の必要性は、この半年に観測されたAI利用攻撃の進展によって、改めて裏付けられた。一方、日本で相次いだインシデントがすべてAIの普及によって引き起こされたと結論づけることも難しい。今回明らかになったのは、攻撃の自動化が進む環境において、従来から存在する脆弱性や認証・認可の不備への対応を先送りできなくなっていることである。問われたのは、先送りしてきた基本であった。

次の半年に向けて考えておくべきことが二つある。第一に、オープンウェイトモデルが同等の能力に達するという「6か月から1年」の時期に、いま入りつつある。攻撃の民主化はさらに進む前提で備える必要がある。第二に、4月の文書が6か月から12か月の目安としていたアクション、つまり環境の堅牢化、ディセプション、自動対応、そしてVulnOpsの立ち上げが、これから本番を迎える。

Mythosレディとは、一度到達すれば終わる状態ではない。次の四半期に何をするかを、四半期ごとに見直し続けることである。半年前の文書は、そのことを予告していたといえる。

参考資料

以上

最近、なぜセキュリティ事故が多いのか ~ AI時代のサイバー攻撃を考える

2026年10月16日更新
2026年10月9日更新
2026年10月7日初版
AIWGメンバー 諸角昌宏

【2026年10月16日 更新】10月16日分を赤色で示す。10月16日更新内容は、JPCERT/CCによる攻撃者のAI利用の確認(第4章、第12章)部分である。結論と3層の整理は変更していない。

【2026年10月9日 更新】初版の公開後に確認した情報を追記した(緑字で示す)。追記したのは、警察庁の2026年上半期の統計、AIの悪用を指摘する報道とGambit Securityの報告、金融庁・日本銀行の要請である。結論と3層の整理は変更していない。

2026年に入り、日本国内でサイバー攻撃や情報漏洩、ランサムウェア、不正アクセスなどの情報セキュリティ事故が相次いで公表されている。特に夏から秋にかけては、企業、大学、公共機関などさまざまな組織からインシデントが公表され、「最近、セキュリティ事故が増えているのではないか」と感じる機会が多くなった。一方、2026年は生成AIやAIエージェントの利用が急速に広がった年でもある。そこで気になるのが、「最近のセキュリティ事故の多発とAIの普及には関係があるのか」である。

本ブログでは、警察庁、IPA、Verizon、IBM X-Force、Google Cloud/Mandiantなどの公開情報、および国内の民間調査を基に、この問題を整理する。そのうえで、CSAジャパンブログに掲載された筆者の「Mythosレディ」シリーズで示した3層(基本対策、ゼロトラスト、VulnOps / CTEM)に沿って、対策をまとめてみる。

本当にセキュリティ事故は増えているのか

最初に注意しなければならないのは、「ニュースで目にする事故が増えた」ことと「実際のインシデント発生率が増えた」ことは同じではないという点である。デジタルアーツ株式会社が、対象組織による公開報告書およびマスメディアの報道資料を基に独自集計した「2026年上半期国内セキュリティインシデント集計」によれば、2026年1~6月に情報漏えい等のセキュリティインシデントによる被害・影響を公表した国内組織は727件であった。このうち「不正アクセス」が267件で最も多く、「マルウェア感染」が153件でこれに続いている[1]。ただし、この727件は727回の独立したサイバー攻撃を意味するものではない。同調査では、例えば委託先1社への攻撃によって複数の委託元企業が被害を公表した場合、それぞれの公表組織を1件として計上している。したがって、「国内で727回のサイバー攻撃が発生した」と読み替えることは適切ではない。

さらに、もう一つ注意すべき点がある。攻撃の発生日と公表日は一致しない、ということである。調査に数週間から数カ月を要した後に公表されるケースもあるため、特定の月に公表が集中したからといって、その月に攻撃そのものが急増したとは限らない。 警察庁のランサムウェア統計を見ても、この点は興味深い。企業・団体等から警察庁に報告されたランサムウェア被害は、次のとおりである。[6]

年報告件数
2021年146件
2022年230件
2023年197件
2024年222件
2025年226件

【10/9更新】2024年の222件から2025年は226件であり、大幅な増加ではない。したがって、「最近になって突然ランサムウェアが爆発的に増加した」というより、高い攻撃水準が数年間継続していると表現する方が正確である。[6]

【10/9更新】ただし、2026年に入ってこの水準はさらに上がっている。警察庁が2026年9月10日に公表した上半期の統計では、ランサムウェア被害の報告件数は123件で、統計を取り始めた2020年下半期以降、半期として最多となった[14]。2025年は上半期が116件、下半期が110件だったので、急増とまでは言えないが、高止まりから増加に転じた可能性がある。 被害組織の内訳は、規模別では中小企業79件、大企業31件、団体等13件である。業種別では製造業が37件で最も多く、卸売・小売業15件、情報通信業、不動産・物品賃貸業、医療・福祉が各9件、建設業8件、その他36件と続く[14]。特定の規模や業種に限られた問題ではないと思われる。

日本だけで起きている現象なのか

この傾向は日本だけに限らない。Verizonの「2026 Data Breach Investigations Report(DBIR)」では、31,000件を超えるセキュリティインシデントと22,000件を超えるconfirmed data breachが分析対象となった。前年の2025 DBIRではconfirmed breachは12,195件だったため、分析対象件数自体は大きく増えている[7][8]。ただし、DBIRは世界中の法執行機関、セキュリティ企業、保険会社などから提供されたデータを集約している。そのため、この数字をそのまま「世界の侵害件数が約80%増加した」と解釈することはできない。重要なのは攻撃方法の変化である。2026 DBIRでは、脆弱性悪用が31%を占め、初期侵入経路として初めて盗用された認証情報を上回った。[8]

IBM X-Forceの2026 Threat Intelligence Indexでも、2025年には公開アプリケーションの脆弱性悪用を起点とした攻撃が前年比44%増加したと報告されている。また、活動しているランサムウェア/恐喝グループも増加している[9]。つまり世界的に、次の4つが引き続き大きな問題となっている。

  • 脆弱性悪用
  • ID・認証情報の悪用
  • ランサムウェア/恐喝
  • サプライチェーン攻撃

日本の最近の事故では何が狙われているのか

では、日本国内で2026年に公表された最近のインシデントでは、どのような侵入経路が使われているのだろうか。2026年夏以降については、Aioright Technologies株式会社が、2026年7月1日から10月4日までに国内で検知または公表された143件を公開情報に基づいて集計している[2]。このうち126件が確認済みのサイバー攻撃と分類され、不正アクセスが74件(58.7%)を占めている。さらに重要なのが初期侵入経路である。126件中、初期侵入経路を公開情報から分類できたのは58件であり、その内訳は次のようになっている。

初期侵入経路件数割合
脆弱性悪用23件39.7%
ID・認証関連20件34.5%
サプライチェーン11件19.0%
設定・実装不備2件3.4%
マルウェア感染2件3.4%
合計(分類できた事案)58件100.0%

つまり、侵入経路を分類できた58件に限れば、脆弱性悪用+ID・認証関連=43件、74.1%になる[2]。ただし、この数字についても注意が必要である。確認済みサイバー攻撃126件のうち68件(54.0%)は、初期侵入経路が不明または非公表である。そのため、「日本国内のサイバー攻撃の74.1%が脆弱性またはIDを原因としている」という意味ではない。あくまで、「公開情報から侵入経路を分類できた58件では、74.1%が脆弱性悪用またはID・認証関連だった」と解釈する必要がある。つまり、公開情報から侵入経路を分類できた事案では、脆弱性とIdentityが主要な侵入要因となっているということである。

これは警察庁の過去のランサムウェア調査とも整合する。2024年にランサムウェア被害を受けた企業等へのアンケートでは、侵入経路としてVPN機器が55%、リモートデスクトップが31%を占めていた[10]。ここから見えてくるのは、極めて「従来型」の問題である。VPNやネットワーク機器の脆弱性、盗まれた認証情報、弱い認証、過剰なアクセス権限、委託先やサプライチェーン。これらはAIが登場する以前から存在していた問題である。

ではAIは関係ないのか

ここが今回の問題を考えるうえで最も重要なポイントである。

【10/9更新】2026年に日本で公表された主要インシデントを確認しても、「攻撃者が生成AIやAIエージェントを利用したため侵害された」と明確に公表された事案は、確認した範囲では見つからなかった。したがって、「2026年に日本でセキュリティ事故が増えているのはAIのせいである」と結論づける根拠は、現時点では確認されていない。

【10/9更新】2026年10月に入り、相次ぐ情報漏えいの背景にAIの悪用があるとみる報道や専門家の指摘が増えている。しかし、筆者が確認した範囲では、これらは状況からの推測であり、被害組織がAIの使用を公式に認めた国内事案は見当たらない。指摘されていることと、確認されていることは区別しておきたい。

【10/16更新】その後、JPCERT/CCは2026年10月15日、一連の事案で攻撃に使用された可能性のあるインフラを調査した結果、「攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました」と公表した[17]。一連の事案に関わる攻撃者がAIを利用していたことが、調査に基づいて確認されたことになる。

【10/16更新】ただし、この記述には限定がある。同記事は、調査したインフラと個別の事案との対応を示しておらず、調査対象の一部は「今回の攻撃とは直接関係しない別のサーバー」としている。また、一部の報道では「AIエージェント」の使用とも伝えられているが、JPCERT/CCの記事は「AIを利用して」とするにとどまり、AIが自律的に攻撃を進めていたかどうかには触れていない。したがって、「一連の事案はAIエージェントによるものだ」とまでは言えない。

【10/16更新】むしろ注目すべきは、AIが何に使われていたかである。JPCERT/CCが確認したのは、既知の脆弱性のスキャンや、スマートフォンアプリを解析してその裏側にあるAPIの弱点(SSRFなど)を探る行為だった。推奨している対策も、アプリに秘密鍵や長期間有効な認証情報を埋め込まない、サーバー側で認証・認可を行う、レート制限と異常なリクエストの監視を行う、といった基本的なものである[17]。AIは新しい攻撃を生み出したのではなく、既存の弱点を探し突く作業に使われていたということになる。

しかし、「AIはサイバー攻撃に関係していない」という結論も正しくない。IPAは2026年の「AIセキュリティ短信」などで、次のような動きを取り上げている[11]。

  • AIエージェント群による自律的な侵入
  • AIを利用した攻撃コード生成
  • AI支援によるマルウェア開発
  • LLMを利用した金融不正
  • AIエージェントによる企業侵入時間の短縮

つまり、AIを攻撃に利用する動き自体はすでに現実のものとなっている[11]。

AIは「原因」ではなく「脅威増幅要因(Threat Multiplier)」

この状況を理解するには、AIを新しい攻撃手法そのものと考えない方がよいと思われる。AIが大きく変えようとしているのは、次の3点である。

  • Speed(速度)
  • Scale(規模)
  • Automation(自動化)

例えば従来の脆弱性攻撃では、次のプロセスが必要だった。

AIやAIエージェントを利用すれば、この一部を自動化できる可能性がある。同じことはフィッシングにも当てはまる。生成AIを利用すれば、大量のメールを作るだけでなく、標的に合わせた自然な文章を短時間で作成できる。

【10/9更新】この変化を具体的に示す報告がある。Gambit Securityは2026年9月、ある攻撃者の中継サーバーを分析した暫定報告を公表した[15]。それによると、攻撃者は3種類のオープンソースのAIツールを組み合わせ、脆弱性の探索から侵入、データの持ち出しまでの大部分を自律的に実行させていた。260セッションで人間が入力した指示は1,951件にとどまる。6日間に105件の攻撃が開始され、少なくとも27社で侵害が確認された。1標的あたりのコストは、完了した101件の平均で約25ドルである。

【10/9更新】注目すべきは、そこで使われた手口である。SQLインジェクション、ファイルアップロード機能の不備、設定ファイルに残された認証情報など、いずれも以前から知られている弱点だった。変わったのは手口ではなく、それを試す速度と規模、そしてコストである。なお、これは1つの攻撃グループに関する暫定的な調査結果である。被害例には日本の旅行予約サイトも含まれるが、本ブログで見た国内の公表事案との関係は確認されていない。

つまりAIは、新しい脆弱性を生み出しているというより、既に存在する脆弱性を攻撃する能力を増幅していると考える方が現状を説明しやすい。この意味でAIは、Root Cause(根本原因)ではなく、Threat Multiplier(脅威増幅要因)と位置付けるのが適切である。

「AI普及」と「事故増加」の因果関係は証明されていない

ここでは相関関係と因果関係を区別する必要がある。現在、AI利用の拡大と同時に、次のような動きが観測されている。

  • 脆弱性探索の高速化
  • 攻撃コード生成支援
  • フィッシング高度化
  • マルウェア開発支援
  • AIエージェントによる攻撃自動化

また日本では、不正アクセス、ランサムウェア、情報漏洩など多数の事故が公表されている。しかし、AI利用の増加→日本のセキュリティ事故件数の増加という因果関係を直接示す統計は、現時点では存在しない。

Mandiantも2026年のM-Trendsにおいて、2025年を「AIが直接breachを引き起こした年」とは位置付けていない。一方で、攻撃者が偵察、ソーシャルエンジニアリング、マルウェア開発などでAIを利用し、生産性を向上させていることは確認している。この区別は非常に重要である[12]。

本当に変わりつつあるのは「時間」である

AI時代のサイバーセキュリティで特に注目すべきと考えるのは、攻撃件数そのものよりも、攻撃に必要な時間の短縮であると考える。これまで防御側には、次のプロセスに充てる一定の時間があった。

しかし攻撃側の脆弱性探索、分析、攻撃コード生成、対象探索がAIによって高速化すると、脆弱性が攻撃可能になるまでの時間が短くなる。これは防御側にとって非常に大きな意味を持つ[8][12]。「毎月脆弱性スキャンを実施する」「年に数回ペネトレーションテストを実施する」といった周期型の脆弱性管理では、攻撃側の速度についていけなくなる可能性がある。

対策をどう整理するか ― 「Mythosレディ」の3層

では、攻撃側の時間軸が変わりつつある状況で、防御側は何から手を付ければよいのか。ここでは、CSAジャパンブログに掲載した筆者の「Mythosレディ」シリーズ[3][4][5]で示した3層に沿って整理したい。

同シリーズは、Anthropicが2026年4月に発表したClaude Mythos Previewを契機に、機械速度の攻撃が常態化する世界で組織が取るべき対策を論じたものである。そこでは、「Mythosレディ」を特定のAIツールへの対抗策としてではなく、背後にある構造的リスクに継続的に適応し続けられる組織の状態として捉えた[3]。これは、AIを根本原因ではなく脅威増幅要因と見る本ブログの立場と一貫している。

【10/9更新】規制当局も同じ問題意識で動いている。金融庁と日本銀行は2026年5月22日、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得るとして、金融機関等に9項目の短期的な対応を要請した[16]。優先的に対応すべきサービスやITシステムの特定、技術負債の解消、リスクベースのパッチ適用、パッチ適用以外の対策の強化、停止への備えなどであり、以下に示す3層と重なる内容である。

同シリーズで示した対策は、次の3層である。

この3層は、上から順に完成させていくものではなく、同時並行で育てていくものである。以下、順に見ていきたい。

第1層:基本対策 : まず基本の穴を塞ぐ

シリーズ第1回[3]では、Mythosレディへの第一歩を、新しいAI防御製品の導入ではなく、基本的なセキュリティの強化に置いた。その前提にあるのは、情報セキュリティの目的を「コントロール可能にすること」と捉える考え方である[3]。攻撃を完全に防ぐことはできなくても、影響を封じ込め、回復し、次に備えられる状態を保つことはできる。そして攻撃者は最も弱い点を狙うため、高度な対策より先に基本の穴を塞ぐ必要がある。 同ブログでは、今すぐ取り組む基本強化として5つの領域を挙げた。本ブログで見た国内事案と対応させると、次のようになる。

領域主な内容国内事案との関係
資産管理IT資産、SBOM、シャドーIT、AIエージェント資産を継続的に把握する把握していないVPN機器や公開サーバーは、修正も監視もできない
ネットワークセグメンテーション機能・リスク別に分離し、横展開を遮断する侵入後の被害拡大(ランサムウェアの全社展開など)を抑える
パッチ管理の継続化CVSSではなくKEVなど実際の悪用状況で優先する。同ブログでは、クリティカルパッチについて24時間以内の適用を目標例としている脆弱性悪用(39.7%)、VPN機器経由の侵入(55%)
IAM最小権限の徹底、過剰権限の棚卸し、フィッシング耐性MFAの展開。AIエージェントにも最小権限を適用するID・認証関連(34.5%)、リモートデスクトップ経由の侵入(31%)
多層防御の再設計単一の対策に依存しない設計、egressフィルタリング、継続的モニタリング一つの防御が破られた後の検知と、情報持ち出しの抑止

上記「日本の最近の事故では何が狙われているのか」で見た「従来型」の問題は、ほぼこの5領域に収まる。AI時代だからといって特別な対策が先に必要になるわけではない。AIによって増幅されるのは既存の弱点への攻撃であり、だからこそ基本対策の価値はむしろ高まっている。

第2層:ゼロトラスト :  侵入されても到達させない

基本対策を講じても、脆弱性悪用 → 侵入、あるいは認証情報窃取 → 正規アカウントによる侵入そのものを完全になくすことは難しい。したがって、「侵入させない」だけではなく「侵入されても重要資産まで到達させない」設計が重要になる。

ここでZero Trustの考え方が生きてくる。プロテクトサーフェスを明確にし、Identity、Device、Network、Application、Dataを継続的に評価し、最小権限を適用する。さらにマイクロセグメンテーションなどによって、侵害されたアカウントや端末から重要資産への横展開を抑制する。

シリーズ第2回[4]では、Mythosレディにゼロトラストが有効な理由を説明した。ゼロトラストは攻撃を完全に防ぐ手段ではなく、攻撃の難度を引き上げ、侵入から被害拡大までの時間を引き延ばすことで、人間が対応できる時間を確保する戦略と位置付けられる。攻撃側の時間が短縮されるのであれば、防御側は侵入後の時間を取り戻す設計を持つ必要がある。 委託先やサプライチェーン経由の侵入(19.0%)のように、正規の経路や正規のアカウントが使われる場合にも、アクセスのたびに検証し、到達範囲を限定する設計は有効に働くと思われる。

第3層:VulnOps / CTEM ― 悪用される前に発見し、修復する

ゼロトラストが侵入後の被害を限定する層だとすれば、第3層は侵入される前のExposureを減らす層である。VulnOpsが脆弱性の継続的な発見・優先順位付け・修復を担うのに対し、CTEM(Continuous Threat Exposure Management)は脆弱性だけでなく、設定、権限、攻撃経路などを含むExposure全体を継続的に評価・低減する枠組みである。シリーズ第3回[5]では、この両者をMythosレディの中核に位置付けた。

「毎月スキャンする」「年に数回ペネトレーションテストを実施する」といった周期型の脆弱性管理は、攻撃側に時間がかかることを暗黙の前提としていた。従来型の脆弱性管理は、Find → Patchという考え方になりやすかったが、実際には、すべての脆弱性を直ちに修正することはできない。そこで必要になるのが、継続的な運用である。GartnerのCTEMは、Scoping、Discovery、Prioritization、Validation、Mobilizationの5フェーズで定義されている。次に示すのはその5フェーズそのものではなく、VulnOps / CTEMを実装する際の本ブログでの運用例である[13]。

CVSSだけを見るのではなく、次の点を評価して、修復の優先順位を決める必要がある。

  • 実際にInternetから到達可能なのか
  • 既に悪用されているのか
  • 重要なプロテクトサーフェスにつながっているのか
  • 攻撃経路として成立するのか
  • どの程度の業務影響があるのか

これは、第1層の「パッチ管理の継続化」を、攻撃側の速度に合わせて常時回り続ける運用へ発展させたものと言える。AIによって攻撃側のサイクルが高速化するのであれば、防御側も同じように継続的なサイクルへ移行する必要がある。

まとめ:AI時代に変えるべきなのは防御側の「時間軸」

ここまでを整理すると、2026年に相次いで公表されている日本のセキュリティ事故について、AIが直接的な原因であることを示す証拠は現時点では確認できない。実際に確認できる主要な侵入経路は、脆弱性、Identity、サプライチェーンなど、以前から存在していたものである。

【10/16追記】JPCERT/CCが攻撃者によるAIの利用を確認した後も、この整理は変わらない。確認されたのは、AIを使って既知の脆弱性やAPIの弱点を探し突く行為だったからである[17]。AIが攻撃に使われていることは事実になったが、突かれているのは依然として以前から存在する弱点である。

一方で、AIが攻撃者の能力を増幅し、探索、分析、攻撃コード生成、ソーシャルエンジニアリング、侵入後活動などを高速化・自動化し始めていることも事実である[8][9][11][12]。

したがって、「AIによってサイバー事故が増えた」と単純化するのではなく、「AIによって攻撃側の時間軸が変わり始めている」と捉える方が適切ではないだろうか。そして問題はAIそのものだけではない。攻撃側の時間軸が変わっているにもかかわらず、防御側が、月次スキャン、四半期レビュー、年次リスク評価という従来の時間軸のままでよいのか、という問題である。AI時代のセキュリティ対策で求められているのは、単に「AIを使ったセキュリティ製品」を導入することではない。「Mythosレディ」の3層に沿って言えば、次の3つを同時並行で進めることである。

Mythosレディは、一度到達すれば終わる状態ではない。攻撃側の速度に合わせて適応し続けられる状態を保つことであり、その出発点は、国内事案のデータが示すとおり、基本対策にある。

参考資料

民間調査

[1]デジタルアーツ株式会社「2026年上半期国内セキュリティインシデント集計」2026年7月28日公開

[2]Aioright Technologies株式会社 2026年7〜10月 国内サイバーセキュリティ事案143件の統計分析――攻撃種別・対象・侵入経路の全体像」 2026年10月6日公開

CSAジャパン ブログ(「Mythosレディとは何か」シリーズ)

[3]CSAジャパンブログ「Mythosレディとは何か ~ 機械速度の攻撃時代における組織生存の条件」 2026年5月26日公開

[4]CSAジャパンブログ 「Mythosレディとは何か(続編)~ Mythosレディにゼロトラストが有効な理由」 2026年6月3日公開

[5]CSAジャパンブログ 「Mythosレディとは何か(続編-2)~ VulnOpsとCTEM:継続的脆弱性管理の具体的な実装」 2026年6月5日公開

公的機関・ベンダー一次資料

[6]警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」

[7]Verizon, 2025 Data Breach Investigations Report(公表資料)

[8]Verizon, 2026 Data Breach Investigations Report(公表資料)

[9]IBM X-Force, 2026 Threat Intelligence Index

[10]警察庁「令和7年版 警察白書」第3項 ランサムウェアの情勢

[11]IPA「AIセキュリティ短信」

[12]Google Cloud / Mandiant, M-Trends 2026

[13]Gartner, Strategic Roadmap for Continuous Threat Exposure Management

[14]警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」(2026年9月10日公表)

[15]Gambit Security, AI Agents Are Hacking Online Retailers for $25 a Company(2026年9月22日、暫定報告)

[16]金融庁・日本銀行「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について(2026年5月22日)

[17]JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」(2026年10月15日)

補足資料

IPA「情報セキュリティ白書2026」

Google Threat Intelligence Group, AI Threat Tracker: From Prompting to Autonomy(2026-09-08)

以上

「Mythosレディ」とは何か(続編-3)~ VulnOps と CTEM を実装する実施例

2026年6月21日
AIWGメンバー 諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

前回のブログ(続編-2)では、AIによる脆弱性発見と攻撃の高度化が「公開から悪用までの時間」を急速に縮め、防御側の運用モデルそのものを変えつつあること、そしてその答えとして VulnOpsと CTEMという2つの概念を取り上げた。「Mythosレディとは何か」についてブログシリーズ(3回連載)でまとめたが、VulnOps、 CTEMで「実際にどう手を動かすのか」ということが不明確であった。そこで、この続編-3として、実施例とユースケースの形で考察することとした。

結論を先に述べると、VulnOpsとCTEMは対立するものでも、別々に導入するものでもない。VulnOpsという日々の運用能力を、CTEMという5フェーズの継続サイクルの上で回すものである。そこに至るまでに、用語の揺れや適用範囲の誤解といった、実務で必ずつまずく論点も整理していきたい。

第1章 VulnOps の実装:実施例とユースケース

VulnOpsの本質は、脆弱性管理を「四半期に一度のスキャン」から「開発・運用ワークフローに組み込まれた継続的なプロセス」へ転換することにある。従来のようにサイロ化した定期スキャンではなく、継続的な監視と自動スキャンを日々の業務へ直接埋め込むことである。以下に、代表的な実施例を5つ挙げる。

1-1. CI/CD パイプラインへの組み込み(シフトレフト)

VulnOpsを最も導入しやすい入口である。コードのビルド・デプロイ段階にセキュリティスキャンを埋め込み、脆弱性が本番に到達する前に捕捉していく。

  • IaC(Terraform 等)テンプレートやコンテナイメージを、本番到達前にスキャンする
  • 開発環境での早期検出により、修正コストとセキュリティリスクを下げる(シフトレフト)
  • 開発チームへ迅速にフィードバックしつつ、デプロイのボトルネックを作らない

ツール例:SAST/DAST、コンテナスキャナ(Trivy、Grype)、IaC スキャナ(Checkov、tfsec)を GitHub Actions/GitLab CI に組み込む。

1-2. クラウド環境の継続的アセスメント

クラウドではリソースが数分単位で出現・消滅するため、従来型ツールでは追随できない。

  • クラウドネイティブ API を使ったエージェントレススキャンで、性能影響を抑えつつ網羅的に可視化する
  • クラウドの脆弱性の多くはソフトウェアの欠陥ではなく設定ミス(過剰な権限ロール、公開ストレージバケット等)に起因するため、CSPM 的な検知が中心になる

ユースケース:AWS/Azure/GCP 等ののマルチクラウドにおいて、シャドー IT資産や一時的リソースまで含めて常時棚卸しする。

1-3. リスクベースの優先順位付け

「すべて直す」ことは非現実的であり、この優先順位付けが VulnOps の肝である。

  • 脅威インテリジェンスを統合し、攻撃者が実際に狙っている脆弱性を特定し優先する
  • CVSS スコアだけでは特定環境での悪用可能性は判断できないため、資産の重要度・データ機密性・悪用可能性を組み合わせる
  • CISA の KEV(Known Exploited Vulnerabilities)カタログのように『悪用が現に確認された脆弱性』を列挙した公的リストを、優先順位の基準に据える。CVSS が高くても未悪用のものより、CVSS が中程度でも KEV にリストされた実際に悪用されている脆弱性を先に処理する
  • KEV を「絶対対応リスト」、EPSS(今後30日の悪用可能性スコア)を「予測指標」として併用すると、既知の悪用と将来の悪用見込みの両面から漏れなく絞り込める
  • 結果として、真にリスクとなるごく一部(各種研究では数%程度と報告されることもある)の脆弱性に集中でき、対応チームの疲弊を抑える

ツール・情報源例:

1-4. 修復の自動化とワークフロー連携

  • SIEM での相関分析、SOAR での自動対応と連携し、チケット発行まで自動化する
  • 本番投入前に非本番環境でパッチを自動テストし、システムの不安定化を防ぎつつ展開する
  • パッチ適用は数ある対処手段の一つにすぎず、設定強化・代替コントロール・アクセス制御と組み合わせる

製品・ツール例:

  • Splunk Enterprise Security : SIEMによるログ分析・相関分析
  • Microsoft Sentinel : SIEM・SOAR機能による検知と対応の自動化
  • Microsoft Intune : 管理対象端末の更新・構成管理
  • ServiceNow : インシデント・脆弱性対応のチケット管理、ワークフロー
  • Jira : 修復タスクの起票、担当者への割り当て、進捗管理

1-5. コンプライアンス対応

  • PCI DSS、HIPAA、ISO 27001、SOC 2 は、定期的な脆弱性評価と適時の修復を要求している
  • 構造化された反復プロセスにより、継続的なセキュリティ改善の監査証跡を自動生成し、監査対応を「負担」から「戦略的優位」へ変えていく

製品・ツール例:

  • ServiceNow : 対応履歴・承認・期限・責任者の管理
    Jira : タスクと修復状況の追跡
    Microsoft Sentinel : セキュリティイベントやログの集約・検索
    Splunk Enterprise : ログの集約・検索・レポート作成

第2章 VulnOps の適用範囲をめぐる注意点

実装に入る前に、概念の輪郭をはっきりさせておく必要がある。VulnOps は新しく、マーケティング寄りの揺れも大きい言葉である。ここを曖昧にしたまま導入すると、「何をやっているのか分からない取り組み」になりがちである。

2-1. 開発環境だけの話ではない

CI/CD への組み込み(シフトレフト)は印象的なので VulnOps の中心と誤解されがちだが、それは一部にすぎない。DevOps が開発だけでなく運用までを一体化した思想だったのと同じく、VulnOps も 開発から本番まで全ライフサイクルを貫く のが重要である。むしろリスクベースの優先順位付けと継続監視という核心は、本番環境の実資産と脅威情報があって初めて成立する。

段階VulnOps の適用
開発コード/IaC/イメージのスキャン
CI/CD自動チェック・ゲート
本番運用継続監視・設定検知・優先順位付け・修復

2-2. アプリを「使う側」では意味が変わる

アプリ(SaaS など)を利用する側では、その本体・OS・インフラの脆弱性対応はベンダー責任になる。したがって、以下のような対応となる。

  • 設定ミスの管理(SSPM):過剰な共有権限、公開リンク、外部ゲストアクセス、MFA/パスワードポリシー、管理者権限の付与状況
  • アイデンティティと OAuth 連携:誰がどのアプリにどの権限でアクセスできるか、サードパーティ連携が見えない侵入経路になっていないか
  • ベンダーリスク管理:自分でパッチを当てられない以上、SOC 2/ISO 27001、修正・通知の SLA、ペンテスト結果の開示でベンダーの健全性を評価する
  • シャドー IT・アプリ棚卸し:従業員が独自契約した未承認のアプリという、可視化されない攻撃面の発見

上記のアプリ利用側の対策は、VulnOps という言葉が広まる前から独立して確立した一般的なセキュリティ対策である。これらを VulnOps の傘へ後付けで吸収させ「これも VulnOps」と語るのは、用語を膨らませているだけで、有用な区別を消してしまうことになる。したがって、狭い本来の意味(スキャン&修復の継続運用)では、アプリ利用側で VulnOps の出番はほぼない。

重要なのは言葉の所属ではなく、これらの対策を共通のスコープ・優先順位・修復フローの中で一体運用することである。その役割を担うのが、次章の CTEM である。

第3章 CTEM:VulnOps を包含する継続運用サイクル

CTEM(Continuous Threat Exposure Management/継続的脅威露出管理)は、Gartner が定義した5フェーズのフレームワークである。VulnOps と違い用語の揺れがなく、何をやるかが明確に決まっている点が大きな違いである。Gartnerは、CTEMに基づいて投資を優先する組織は2026年までに侵害リスクを3分の2低減すると予測している。

3-1. CTEM は「脆弱性管理そのもの」ではない

ここは誤解の多い点である。CTEM は脆弱性管理から進化したものだが、対象範囲が脆弱性を超えて広がっており、正確には 露出管理(exposure management) と呼ぶべき、より広い枠組みである。

観点脆弱性管理(VM/RBVM)CTEM
対象CVE 中心CVE + 設定・権限・攻撃経路・SaaS 等
検証通常なし攻撃者視点で悪用可能性を実証
優先順位脆弱性の深刻度重要資産への攻撃経路
性質構成要素のひとつそれらを束ねる運用サイクル

つまり脆弱性管理は CTEM の一部(特に Discovery への入力)として組み込まれるが、CTEM = 脆弱性管理ではない。

3-2. 実装方法:5つのフェーズ

  1. Scoping(スコープ定義):何を守るかを決める。ビジネス上の優先度に従い、対象資産と攻撃面を定義する。初期スコープには外部攻撃面(インターネット露出資産)と SaaS セキュリティポスチャを含めるのが一般的。
  2. Discovery(発見):スコープ内の資産と弱点を洗い出す。CVE だけでなく、設定ミスやあらゆる露出を対象に含める。
  3. Prioritization(優先順位付け):重要資産を脅かす、実際に悪用可能な攻撃経路に絞る。アラート過多を解消し、本当に重要な脅威へ集中する。
  4. Validation(検証):攻撃者の手法を模倣し、その露出が自社環境で本当に悪用可能かを実証する。BAS(Breach and Attack Simulation)や継続的ペンテストが該当し、過検知を排除できる。ここがCTEM独自の強み。
  5. Mobilization(動員・修復):修復責任はセキュリティチームの外(IT・アプリ・各部門)に及ぶため、承認・実装・配備を定型化し、組織横断で動かす仕組みが要点。最も停滞しやすいフェーズ。

3-3. 主なユースケース(運用例)

運用例1:外部攻撃面の継続監視

四半期ごとの EASM(External Attack Surface Management)スキャンを常時監視へ変える。承認なしに立てられたキャンペーン用サーバーが検出され、古い CMS の既知脆弱性が悪用可能と実証される。修復責任は該当部門と IT に及ぶため、チケットを自動作成して定型フローに乗せる。年4回では数か月放置された露出が、数時間〜数日で捕捉・実証・修復に回ることができる。

運用例2:攻撃経路ベースの優先順位付け

スキャナが Critical 800件・High 3,000件を吐き出しても、攻撃経路マッピングで「重要資産に到達しうる連鎖」だけを抽出する。Critical の大半は到達不能で、むしろ Medium 評価の認証情報露出1件が、ドメイン管理者権限への唯一の踏み台だと分かる。800件ではなく経路上の十数件に集中する。VulnOps の優先順位付けが最も効く場面となる。

運用例3:SaaS ポスチャの継続評価

第2章で「これは一般的な対策であって VulnOps ではない」と整理したアプリ利用側の対策が、CTEM の中では正規の構成要素となる。SaaS を Scoping に含め、SSPM が設定・外部共有・OAuth 連携を Discovery し、退職者アカウントの広範トークンを Validation で実証し、Mobilization でトークン失効と無効化を行う。

運用例4:検証による過検知の排除

BAS でランサムウェアの典型的な攻撃チェーンをセキュアに模擬実行し、「EDR がここで遮断するはず」という想定が特定セグメントで素通りしていたと判明する。脆弱性スキャンには一切現れない、検知体制側の穴を修復対象に回す。

第4章 統合して扱う:3つの層

ここまで個別に扱った要素(脆弱性管理・ASM・SSPM・検証)を、CTEM という1つのサイクルへ束ねる。「統合」には3つの層があり、いずれか1つでは機能しない。

4-1. 層1:データの統合(単一の露出ビュー)

スキャナの CVE、ASM/EASM の外部露出、SSPM の SaaS 設定、CSPM のクラウド設定ミス、IAM の過剰権限など、これらを統合プラットフォームに集約し、攻撃経路という共通の文脈で1本の優先順位付きリストにする。CTEM の実装には、コードからクラウドまで攻撃面全体の可視性を統一する CNAPPはCTEM実装を支える有力な統合基盤の一つである。単独では低リスクな項目が、横断で見ると重要資産への一本道になっていく。これは個別ツールでは見えてこない。

4-2. 層2:ワークフローの統合(発見から修復まで自動で流す)

CTEM で実証された露出を SOAR や ITSM(ServiceNow、Jira 等)へ自動連携し、担当チームへチケットを自動発行する。SIEM とも連携させ、検証で見つかった検知体制の穴を SOC 側の改善へ回す。多くの CTEM プログラムは動員段階で停滞する。ツールだけ統合してもワークフローと組織が分断されていれば、「発見はされるが直らない」状態に陥る。

4-3. 層3:フレームワークの統合(傘として束ねる)

これまで別々に登場した概念を、CTEM の下に位置づけ直してみる。

個別の取り組みCTEM での位置づけ
脆弱性管理(VM/RBVM)Discovery への入力
ASM/EASM/CAASMScoping・Discovery の資産発見
SSPMSaaS スコープの Discovery〜Validation
BAS・継続ペンテストValidation
SOAR・ITSM 連携Mobilization

これが、第2章の「アプリ利用側の対策は VulnOps ではなく一般的な対策では?」という問いへのきれいな着地点になる。個別には独立した対策でも、CTEM という運用サイクルに乗せれば、共通のスコープ・優先順位・修復フローの中で一体運用される。VulnOps のように用語を膨らませて吸収するのではなく、フレームワークとして正式に束ねる 。ここが決定的な違いである。

4-4. 統合運用の1サイクル通し

  1. Scoping:今四半期は「外部攻撃面 + 主要 SaaS」を対象に設定
  2. Discovery:EASM・SSPM・スキャナの結果を統合プラットフォームへ集約
  3. Prioritization:攻撃経路マッピングで、重要資産に至る連鎖だけを抽出
  4. Validation:BAS でその経路が実際に通るか実証し、偽陽性を除外
  5. Mobilization:残った真のリスクを ITSM へ自動起票し、IT/アプリ/SOC へ分配
  6. 一周して終わりではなく、同じサイクルを継続的に回す
    たとえば、次の四半期は、今回スコープ外だった領域(例:クラウド上で動くVM・コンテナ等の『ワークロード』)を新たに対象へ加え、カバー範囲を段階的に広げる

5つのフェーズを継続サイクルではなく一度きりのプロジェクトとして扱うと CTEM は失敗する。成功には、組織的な足並みの統一・統合されたツール・各フェーズの明確なオーナーシップが必要であり、層2(ワークフロー)と層3(組織・フレームワーク)まで統合して初めて機能する。

まとめ:Mythosレディへの接続

AI による脆弱性発見と悪用が加速し、防御側に与えられる時間は縮み続けている。この新しいベースラインに耐える組織を、「AI脆弱性の嵐」は「Mythosレディ」なセキュリティプログラムと呼んだ。その中核に置かれたのが、脆弱性対応を一過性の作業ではなく恒久的な組織能力として運用する VulnOps の発想である。Bruce Schneierらは、AIによる脆弱性研究の運用化が「VulnOps」という新しい実務領域を生み出す可能性を指摘している。

本ブログの実装編を通して見えてきたのは、VulnOps は「日々の運用能力」、CTEM はそれを規律づけて回す「継続サイクル」である。 VulnOps をスキャン作業と狭く捉えれば、アプリ利用側や設定・アイデンティティの領域では出番がないように見える。しかし CTEM という傘の下に置けば、脆弱性管理も SSPM も攻撃経路検証も、共通のスコープと優先順位の中で一体運用される、Mythosレディな防御態勢の構成要素になる。

はじめの一歩としては、外部攻撃面の継続監視から小さく始め、サイクルを回す習慣をつけてから、攻撃経路の優先順位付けと検証へ広げる進め方が現実的である。最初から5フェーズすべてを完璧に回そうとすると、特に Mobilization の組織連携でつまずいてしまう。

概念を語る段階から、運用として回す段階へ。 それが、AI 駆動の脅威時代に「Mythosレディ」であることの実務的な意味だと考える。

出典・参考

  • CSA, SANS, [un]prompted, OWASP, “The AI Vulnerability Storm: Building a ‘Mythos-ready’ Security Program”(2026年)
  • Gartner, “How to Manage Cybersecurity Threats, Not Episodes”(CTEM フレームワークの出典)
  • 各種ベンダー・コミュニティによる CTEM/VulnerabilityOps(VulnOps)解説(Wiz、CrowdStrike、Rapid7、Splunk、Picus、XM Cyber 他)
  • Heather Adkins, Gadi Evron, Bruce Schneier, “Autonomous AI Hacking and the Future of Cybersecurity” (2025)(VulnOps を新たな専門領域として論じた論考)

以上

セキュリティを脅威で語るかぎり、対策は終わらない

2026年6月13日
ゼロトラストWGリーダー 諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに:ツールは増えたのに、不安は減らない

セキュリティ対策の一覧表を開くとそこに並んでいるのは、EDR、SASE、WAF、SIEM、メールセキュリティ……。気がつけば、対策の一覧が「導入済み製品の一覧」になってはいないだろうか。

毎年新しい脅威レポートを読み、新しい製品を検討し、予算を確保し、導入する。それでも不安は消えない。次の脅威が報じられれば、また次の製品の検討が始まる。多くの組織で、セキュリティはこのサイクルの中にあると思える。

本ブログでは、このサイクルの原因が担当者の問題ではなく、「セキュリティを脅威への対抗として捉える」という捉え方そのものにあることを示し、意思決定の起点に置く問いを入れ替えることで、やるべきことの順番と、それを組織に通す力がどう変わるかを提案してみたい。

第1章. 脅威を主語にすると、対応は「脅威ごとの足し算」になる

セキュリティの議論は、多くの場合「脅威」から始まる。新型ランサムウェア、サプライチェーン攻撃、AIを悪用した攻撃。脅威を主語に置くと、問いは自動的に「この脅威をどう防ぐか」になる。

ここに見落とされがちな構造がある。脅威はマルウェア、エクスプロイト、DDoSといった、個別の技術的な現象として記述される。個別の脅威の粒度で立てられた問いは、その脅威に対応する個別の対策——検知ルールの追加、設定の強化、訓練、そして最も典型的には対策製品の導入——を引き寄せることになる。しかし、いずれの形を取るにせよ、対応は脅威ごとの足し算になる。フィッシングにはメール対策と訓練を、ランサムウェアにはEDRとバックアップを、という具合に、脅威と対策の対応表を埋めていく発想である。

もちろん、脅威の認識から組織の足腰に関わる対応に至る場合もある。ランサムウェアの被害事例を見て、バックアップと復旧体制の見直しに取り組んだ組織は実際にある。しかし注意深く見ると、そこでは問いがいつの間にか「この脅威をどう防ぐか」から「攻撃されても戻ることができるか」に翻訳されている。この翻訳が起きなければ、対応は最短距離にある個別対策の追加——多くの場合は製品の導入——に着地してしまう。問いの立て方は答えを決定するわけではないが、答えの探索範囲を強く方向づける。そして現状、この翻訳は仕組みではなく、担当者個人の力量か偶然に任されてしまっている。

この「脅威ごとの足し算」は、以下の3つの帰結を生むと考える:

  1. 第一に、対策の全体像が「脅威と対策の対応表」になり、表の行を埋めた時点で完了した気になってしまう。個々の対策が製品か設定か訓練かに関わらず、対策同士の整合性や、それらを支える土台(資産管理、復旧力など)の有無は問われない。
  2. 第二に、責任が脅威に最も近いセキュリティ部門とベンダーに局所化され、経営・業務部門・一般の従業員にとってセキュリティは「自分の問題ではない」ものになる。
  3. 第三に、脅威は無限に更新され続けるため、足し算も無限に続く。新しい脅威が報じられるたびに対応表に行が増え、予算と人の疲弊を生む。冒頭の「対策一覧がツール一覧になる」現象は、この足し算の力学に、製品の形で答えを供給する市場の力学が重なった、最も目に見える症状である。

実例:「VPNは危険だ」という言説

身近な例がVPNを巡る言説である。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、「VPNは危険だ。脱VPN・ゼロトラスト移行を」という言説が広まった。脅威(VPN経由の侵入)を主語にした瞬間、答えは「VPNを捨ててZTNA/SASE製品を買う」という製品の置き換えになってしまう。

しかし、以前のブログ(「VPN利用の現状と脱VPNの現実性について」)において、「SaaSセキュリティリーグ」での実務者による議論が示す現実は、もっと複雑である。VPNの利用は、従業員のリモートアクセス・サードベンダー用アクセス・拠点間アクセスという用途ごとに事情が異なる。SIPの制約でVPNを残さざるを得ない領域があり、SASEのコストの問題があり、パートナーからVPN接続を求められれば運用での統制で対応するしかない場面もある。

つまり実務の答えは「製品の総入れ替え」ではない。自組織のアクセス経路を棚卸しして把握し、リスクの高い経路から優先的に手を打ち、技術で解決できない部分は運用で統制することである。さらに言えば、VPNが侵入経路となった事故の多くで実際に効いてくるのは、VPNという技術の存在そのものではなく、パッチ未適用の機器や多要素認証の不在、棚卸しされていないアカウント、つまり基本対策の穴である。

「VPNは危険だ」という脅威の語りは、この現実をすべて覆い隠し、「どの製品に乗り換えるか」という問いだけを残してしまうことになる。

注意: 断っておきたいこと

誤解のないように、これは現場のセキュリティ担当者への批判ではない。脅威ごとの足し算を続けさせてきたのは、脅威の深刻さでしか動かない予算プロセスであり、恐怖を喚起することが最も効率的な営業手段になっているセキュリティ市場の構造であり、さらに遡れば「情報セキュリティとはCIAを維持すること」という定義の構造である。この定義が歴史的にどう成立したかはともかく、CIAは結果として、攻撃者が情報に対してできること(見る・変える・使えなくする)に対応している。そのため、この定義のもとでは、関心が自然と「侵害が有るか無いか」に向かいやすい(この対応関係と、CIAを目的ではなく評価軸として捉え直す考察は、以前のブログ「ゼロトラストとCIA(前編)」「同(後編)」を参照)。

現場は、この構造の中で最善を尽くしてきた。問題は人ではなく、語りの構造にある。だからこそ、語りの構造を変えることに意味があると考える。

第2章. 捉え直し:セキュリティとは「コントロール可能にすること」

では、脅威の代わりに何を主語に置くべきか。

以前のブログ「ゼロトラストとCIA(後編)」は、情報セキュリティの目的を「コントロール可能にすること」、すなわち何が起きても、把握し・対処し・戻れる状態を保ち続けることと再定義することを提案した。CIAは目的ではなく、その状態を評価するための軸である。

この捉え直しの実践的な意味は、問いが変わることにある。「この脅威をどう防ぐか」ではなく、「何が起きても、我々は把握し、対処し、戻れるか」である。前者の答えは脅威ごとに積み上がる個別対策となるが、後者の答えは脅威を横断して効く組織の能力となる。資産を把握しているか。侵害の影響を限定できる設計になっているか。何日で事業を戻せるかを自分たちで決められているか。何が起きたかを後から説明できるか。これらは特定の脅威のための対策ではなく、どんな脅威に対しても効く土台であり、その大半は技術製品ではなく組織の営みである。脅威は無限に増えるが、保つべき能力は有限である。足し算が無限に続く世界から、有限の土台を育てる世界への転換と言うこともできる。

実例:Mythosレディの正しい読み方

この捉え直しが机上の空論でないことを示すのが、いま最も「脅威論」を煽りやすい題材、すなわちAIによる攻撃能力の問題であると考える。

2026年4月のClaude Mythos Previewの登場は、AIが脆弱性発見からexploit生成までを機械速度で実行しうることを示し、大きな衝撃を与えた。恐怖で語ろうと思えば、いくらでも語れる題材である。そして脅威論で受け取った組織は、「Mythosにどう対抗するか」「Mythos対策製品はどれか」という問いを立てるであろう。

しかし、「AI脆弱性の嵐」を解説したブログ「Mythosレディとは何か」は、まさにこの読み方を明確に退けている。Mythosレディとは「すごいハッキングツールに対抗する体制」のことではない。すなわち、脅威論として捉えるべきではない、と言っている。実際、各社モデルの能力は急速に収束しており、「Mythosだけを管理すればよい」という特定脅威への対応は、すでに現実から離れつつある。特定の脅威に紐づけた対策は、脅威が一般化した瞬間に意味を失う。脅威を主語にしたアプローチの賞味期限は、それほど短いと考えられる。

注目すべきは、この最先端の脅威に対して同文書が示した処方箋である。それは新しいAI防御製品の導入ではなく、まず取り組むべきは、資産管理、ネットワークセグメンテーション、パッチ管理の継続化、IAM、多層防御の再設計という基本対策の強化であり、その目的は「コントロール可能な状態の実現」である。高度な攻撃への対策より、基本の穴を塞ぐことが先決である。攻撃者は最も弱い点を狙う。

ただし、ここで言う基本対策は「一度整備すれば終わり」のものではない。ブログ「Mythosレディとは何か」の続編-2「VulnOpsとCTEM:継続的脆弱性管理の具体的な実装」が示すように、脆弱性の発見から武器化までの猶予が数時間レベルに縮むと言われている環境では、「スキャンしてパッチを当て、次のスキャンを待つ」という定期イベント型の運用は、その前提から崩れてしまう。だからこそこのブログでは、脆弱性の発見・優先順位付け・修復を常時回し続けるVulnOpsとCTEM、すなわち基本対策の継続的な運用化をMythosレディの中核に据えている。

機械速度のAI攻撃という、史上最も恐ろしげな脅威ですら、行き着く答えは新奇な対抗製品ではない。基本対策を、環境の変化速度に合わせて回し続け、コントロール可能な状態を「保ち続ける」ことなのである。

第3章. 基本対策は「地味な義務」ではなく「コントロール能力の部品」である

脅威を主語にした世界では、基本対策は分が悪い。脅威は常に「新しいもの」として報じられるが、資産管理もパッチ適用もバックアップも何十年も変わらず、ニュース性がなく、ベンダーが売り込む目玉にもならない。結果、最新製品が積み上がる横で、足元の基本が穴だらけになる。そして実際のインシデントの多くは、高度な攻撃ではなく、その基本の穴から起きている。

しかし「コントロール可能にすること」を目的に置くことで、基本対策の位置づけが一変する。基本対策とは、組織のコントロール能力を構成する部品そのものである。

  • 資産管理・ログ収集は「把握する」能力の実体である。何を持っているか知らずにコントロールはできない
  • アクセス制御・最小権限・MFAは「対処する」能力の実体である。侵害が起きたとき、攻撃者が動ける範囲を最初から狭めておく営みである
  • バックアップと復旧訓練は「戻れる」能力の実体である
  • 監査ログの保全・記録は「説明できる」能力の実体である
  • パッチ適用と脆弱性管理の継続運用は「適応し続ける」能力の実体である。VulnOps/CTEMは、この能力を機械速度の環境に対応させた実装形態にほかならない

高度な製品は、この基本の上に載る追加部品にすぎない。たとえば、資産台帳のない組織にEDRを入れても、アラートが指す先が分からなければ対処できないということが起こりうる。

第4章. 実践:問いを入れ替える

実践の核心は、新しい施策の追加ではない。意思決定の起点に置く問いを、入れ替えることである。第1章で見たように、脅威の問いから組織的な答えに至るには問いの「翻訳」が必要であり、それは現状、個人の力量か偶然に任されている。ならば、翻訳を偶然に任せず、最初から翻訳後の問いを置くようにしたい。つまり、「この脅威をどう防ぐか」をやめ、「何が起きても、我々は把握し、対処し、戻れるか」と問うことである。これは、抽象論ではない。セキュリティ担当者が日常的に立てる問い(あるいは経営や他部門から投げかけられる問い)に、そのまま当てはめることができるものである。以下に、そのいくつかの例をあげる:

場面よくある問い新たに入れ替えた問い
重大な脆弱性が公表されたCVSSスコアが高い。対応すべきか。この脆弱性は自社のどこに存在するか、それにすぐに答えられるか。実際の悪用は始まっているか。塞ぐまでの間、悪用に気づく手段はあるか。
他社の大きな被害が報道されたうちの会社は同じ攻撃を防げるか。同じことがうちの会社で起きたら、何時間で気づき、何日で事業を戻せるか。
ベンダーから製品提案を受けたこの製品はどの脅威を防げるか。この製品は我々のどの能力を高めるか。それを活かす土台(資産管理など)は整っているか。
インシデントの振り返りなぜ防げなかったのか。誰のミスか。検知・対処・復旧のどこで時間を失ったか。次は、もっと早く気づき、早く戻れるか。
新システムの導入審査セキュリティ要件のチェックリストを満たしているか。このシステムで事故が起きたとき、気づけるか(ログ)、影響を限定できるか(権限)、戻せるか(バックアップ)。
経営への報告・予算要求今月の脅威動向はこの通り。この脅威への対策費がほしい。検知から対処までの時間は縮んだか。元の状態に戻すのに、いくら投資するか。
従業員への注意喚起怪しいメールを開かせないために、どう注意喚起するか。異変に気づいた従業員が、責められずに、すぐ報告できるようになっているか。

以上のように、入れ替えの規則は単純である。よくある問いの主語は「脅威」や「製品」であるが、入れ替えた問いの主語はすべて「我々」であり、問うている中身は、第3章で挙げた能力——把握する、対処する、戻れる、説明できる、適応し続ける——のいずれかである。会議において問いが脅威や製品を主語にし始めたと気づいたら、「それは、我々のどの能力の話か」と置き直すことが重要である。それだけで、議論は製品の比較から、自組織の足りない土台の話に戻ってくると考えられる。

この問いの入れ替えは、特に経営との対話で効いてくると考えられる。脅威ベースの予算要求では、経営は投資の効果を確かめようがない。それは、攻撃が起きなかった場合、それが投資のおかげなのか、単に運が良かっただけなのかを、区別できないからである。効果が測れない以上、出すか出さないかの判断のよりどころは「どれだけ怖いか」しかなくなってしまう。したがって、恐怖が薄れれば予算は削られ、「昨年対策したのに、なぜ今年もまた要るのか」という問いに答えられなくなる。

これに対し、能力を問う形の予算要求では、投資の前後で数値化が可能になる。検知から対処までの時間がどれだけ縮んだか。復旧訓練で目標時間内に事業を戻せたか。資産の把握率がどれだけ上がったか。効果が測れれば、経営は他の事業投資と同じ物差しでセキュリティを評価し、判断できる。また、能力は放置すれば劣化するものだから、継続的に投資が必要な理由も自然に説明がつく。基本対策の地味な工数に予算と権限がつかないことに悩んでいる現場にとって、これは武器になるはずである。

なお、基本対策が進まない理由の多くは、現場の問題ではなく組織的な障壁である。パッチを当てたくても、古い基幹システムは業務への影響が大きくて止められず、停止する日程について関係部門の合意が取れない。資産の管理責任者が誰なのか分からない。業務部門の協力が得られない。これらは技術では解決できず、経営層の関与によってしか解決できない。NIST CSF 2.0がGovern機能を独立した柱に据えたのは、この認識の表れであると考える。だからこそ、経営に通じる問いへの入れ替えは、現場の自助努力の話ではなく、構造を動かすための要件なのである。

おわりに:脅威とは、天気予報のように付き合えばよい

最後に、誤解のないように以下の2つの点を補足しておきたい。

第一に、本ブログは「脅威を無視してよい」と言っているのではない。台風が近づいていると知れば、私たちは怖がって騒ぐのではなく、雨戸を閉め、ベランダの物を固定し、停電に備える。台風の情報は、人を怖がらせるためのものではなく、備えるためのものである。脅威の情報も同じように扱うべきであると考える。実際、現場では既にそうしている。脅威インテリジェンスを検知に活かすことや、実際に悪用されている脆弱性(KEV)から優先的にパッチを当てる判断は、まさに「備えるための情報利用」であり、「把握する」能力の一部である。本ブログが見直したいとしているのは、人を怖がらせて動かすための脅威の使い方であって、こうした実務まで否定するものではない。

第二に、「コントロール可能にすること」は、新しいバズワードでも、新しい製品カテゴリでもない。NIST CSF、Assume Breach(侵害を前提とする)、レジリエンスといった、現場がすでに知っている考え方を、一つの目的としてまとめ直したものである。この捉え直しのために、新しく製品を買うというようなものではない。

現場のセキュリティ担当者であれば、本ブログの内容の多くは、すでに肌で感じていることだと思う。防御製品を並べても侵害は起き、勝負を分けるのは把握と復旧であることを、インシデントを経験した人ほど知っている。足りていなかったのは知識ではなく、それを組織に通すための問いの立て方だったのではないだろうか。「この脅威をどう防ぐか」ではなく、「何が起きても、把握し、対処し、戻れるか」。この問いから始めることが重要と考える。

以上

Mythosレディとは何か(続編-2) ~ VulnOpsとCTEM:継続的脆弱性管理の具体的な実装

2026年6月5日
AIWGメンバー 諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに:前回のおさらい

前回のブログ「Mythosレディとは何か(続編) ~ Mythosレディにゼロトラストが有効な理由」では、ゼロトラストがMythosクラスの能力を持つAIによる攻撃に対して有効な5つの代表的な理由を説明した。マイクロセグメンテーションによる横展開の阻止、最小権限による攻撃チェーンの分断、継続的検証による早期発見、egressフィルタリングとの相乗効果、フィッシング耐性MFAによる認証情報窃取の無効化である。そして、3層(第1層(基本対策)、第2層(ゼロトラスト)、第3層(VulnOps・CTEM))を順番に完成させるのではなく、同時に育てることがMythosレディへの現実的な道筋であることを示した。

今回のブログはその第3層、「VulnOpsとCTEM」の具体的な実装について検討する。ゼロトラストが「攻撃者の難易度を上げる」戦略だとすれば、VulnOpsとCTEMは「攻撃者に悪用される前に脆弱性を発見し、修復する」戦略となる。これがMythosレディの中核をなすと考えている。「MythosクラスのAIが脆弱性発見から武器化までの時間をさらに圧縮し、組織が利用できる修復猶予を数日から数時間レベルへ縮小させる可能性がある時代に、従来の脆弱性管理はなぜ機能しないのか。そして何に変わるべきか」について考えていく。

1.なぜ今、脆弱性管理が変わらなければならないのか

従来の脆弱性管理は、基本的に「スキャン→リスクベーストリアージ→パッチ適用→次のスキャンを待つ」というサイクルで運用されている。このサイクルは、根本的な前提として「攻撃者が脆弱性を発見・武器化するまでには時間がある」という前提に基づいている。

Mythos時代に崩壊した前提

「AI脆弱性の嵐」が指摘するように、すでに開示から悪用までの時間は高影響度の脆弱性で数日単位に圧縮されており、数時間以内の武器化事例も報告されている。MythosクラスのAIはこの時間をさらに圧縮し、組織が利用できる修復猶予を数日から数時間レベルへ縮小させる可能性がある。従来のパッチサイクルが「数週間から数カ月」である組織では、このギャップが致命的になる。

加えてCVE件数の爆発的増加が追い打ちをかける。CSAの「VulnOps: Vulnerability Management in the Age of AI」(2026年5月)によると、CVE件数は2020年比で約3倍に増加しており2026年も増加が続いている。さらにNISTのNVDは2026年4月15日、リスクベーストリアージポリシーを発表し、CISAのKEVカタログ掲載のCVEや連邦政府使用ソフトウェアなどに限定してフル分析を提供するようになった(CSA Labsの解説記事)。多くのCVEはCVSSスコアやCPE識別子なしで届くことになり、既存の脆弱性管理ツールが依存してきたパブリックインフラが構造的に変化したと言える。

以上のような状況を踏まえ、従来の脆弱性管理が機能しない理由として以下の3点が考えられる:

  1. スキャンは「瞬間のスナップショット」であり、次のスキャンまでに生まれた脆弱性は見えない。
  2. リスクベーストリアージの基本はCVSS、EPSS、資産価値、攻撃経路、ビジネス影響度を組み合わせてリスクを評価することであるが、CVSSスコアだけで判断している組織が多い。
  3. パッチ適用は人間の作業速度に縛られており、発見から修復までの時間的ギャップ(Exposure Window)が、攻撃者が脆弱性を悪用できる機会を生んでいる。

加えて、CVEの公開件数は年々増加しており、すべてに対応することはリソースの面で不可能に近い。「何を先に直すか」という優先順位付けの精度が、生存を左右する時代になってきていると言える。

「管理する」から「継続的に運営する(Ops化)」へ

この状況への1つの答えが「VulnOps(Vulnerability Operations)」という考え方である。脆弱性対応をプロジェクトではなくオペレーションとして継続的に回していく。発見・トリアージ・優先順位付け・修復・検証・監視というループである。

2.VulnOpsとは何か

VulnOpsとはセキュリティオペレーション(SecOps)の文脈で、脆弱性管理を継続的なオペレーションとして組み込む概念である。「脆弱性スキャンを年2回実施する」とかではなく「脆弱性の発見から修復までのループを常時回す」ことを組織の能力として確立する。

VulnOps(Vulnerability Operations)という用語は、2025年9月にHeather Adkins(Google CISO)とGadi Evronが警告を発し、同年10月にBruce Schneierも加わって「Vulnerability Operations(VulnOps)」という概念を提唱した。その後「AI脆弱性の嵐」でVulnOpsを「恒久的な組織能力」として位置づけ、CSA Labsが2026年5月に「VulnOps: Vulnerability Management in the Age of AI」として定義している。

VulnOpsのループ

VulnOpsは以下のループで構成される。このループは継続的に行われる。

ステップフェーズ内容ゼロトラスト、AIエージェントとの接続
①発見継続的スキャン、SBOM、外部インテリジェンスによる脆弱性の検出など。「いつスキャンしたか」ではなく「常に見えている状態」を目指す。ゼロトラストのプロテクトサーフェスと連動。DAASで定義する資産が対象。
②トリアージリスクベーストリアージの基本はCVSS,
EPSS,資産価値,攻撃経路,ビジネス影響度を組み合わせてリスクを評価する。
プロテクトサーフェスが「どの資産の脆弱性を優先するか」を決める。
③優先順位付け「攻撃者が実際に悪用できるか」という観点で修復順を決める意思決定プロセス。CTEM(後述)のValidationフェーズと連動。実際の経路を検証する。
④修復・軽減パッチ適用を最優先とする。パッチがない場合は回避策(ゼロトラストポリシーの一時強化、セグメンテーション追加など)で影響を軽減する。ゼロトラストポリシーへの即時反映。
⑤検証・監視修復が有効であることを確認し、継続的に監視する。修復後も同一クラスの脆弱性が再発していないかを追跡する。第3層で発見した情報が第1層(パッチ)と第2層(ZTポリシー)に戻る。

ゼロトラストとの連動

VulnOpsとゼロトラストは独立した取り組みではない。ゼロトラストのプロテクトサーフェスがVulnOpsの対象を決め、VulnOpsで発見された脆弱性がゼロトラストのポリシー更新を促していく。この双方向の循環が3層(第1層(基本対策)、第2層(ゼロトラスト)、第3層(VulnOps・CTEM))を「同時に育てる」ことになる。

3.CTEMとは何か、VulnOpsとどう違うのか

CTEM(Continuous Threat Exposure Management)はGartnerが2022年に提唱した概念であり、製品ではなく、企業のデジタル・物理資産の「アクセス可能性・露出度・悪用可能性」を継続的かつ一貫して評価するためのサイバーセキュリティプロセスと能力の集合体である。(出典:Gartner、2022年。https://www.zafran.io/ctem、Gartner原典の直接URLは有料レポートのため、こちらはGartnerの定義を解説したサイト)。つまり、「脆弱性の管理」から「脅威への露出度の継続的管理」へとスコープを拡張したものと理解できる。

ゼロトラストとCTEMの役割分担

CTEMを理解するうえで、まずゼロトラストとの概念的な違いを整理しておく必要がある。ゼロトラストでは、まずDAASの観点からプロテクトサーフェスを定義する。次にトランザクションフローを可視化することで、プロテクトサーフェスに到達可能な経路を明らかにする。これにより、プロテクトサーフェスに対する実効的なアタックサーフェスや攻撃経路を特定できる。ゼロトラストはこれらの経路を厳密に制御・防御するコントロールを設計する。

CTEMはこれを補完する。ゼロトラストが設計した防御が実際に機能しているかを継続的に検証し、環境変化によって新たに生まれた攻撃経路を発見・修復し続ける。ゼロトラストが「プロテクトサーフェスへの攻撃経路を制御する構造を設計する」フレームワークだとすると、CTEMは「その構造が機能し続けているかを継続的に確かめる」フレームワークである。 したがって、両者は競合しない。ゼロトラストのプロテクトサーフェス定義がCTEMのScopingの優先順位を決め、CTEMのValidation(BAS)がゼロトラストのコントロールの有効性を検証し、CTEMが発見した新たな攻撃経路がゼロトラストのポリシー更新を促す。この循環が3層を同時に育てていくと言える。(出典:CSA「Seize the Zero Moment of Trust」2025.01 https://cloudsecurityalliance.org/blog/2025/01/31/seize-the-zero-moment-of-trust)

VulnOpsとCTEMの違い

VulnOpsが「発見した脆弱性をどう処理するか」に焦点を当てているのに対し、CTEMは「攻撃者の視点で自組織の露出度を継続的に評価し、最も悪用されやすい経路から優先的に塞ぐ」という攻撃者視点のフレームワークとなっている。

  • VulnOpsの視点
    • 脆弱性スキャンで発見したCVEを処理
    • CVSSスコアで深刻度を判定
    • パッチ適用を中心とした修復
    • 自組織の資産リストが起点
  • CTEMが加える視点
    • 攻撃者が実際に悪用できる経路を特定する
    • 実際の攻撃可能性(EPSS・BAS結果)で優先順位を決める
    • パッチ以外の軽減策(ZT・セグメンテーション)も活用
    • 攻撃者から見たアタックサーフェスが起点

CTEMの5つのステップ

GartnerのCTEMフレームワークは5つのフェーズで構成される。Mythosレディの文脈で読み解くと以下のようになる。

ステップフェーズ内容ゼロトラスト・AIエージェントとの接続
①Scoping(範囲定義)守るべき対象(アタックサーフェス)と露出(Exposure)の範囲を定義。ゼロトラストのプロテクトサーフェスの定義と直接対応。DAASの4カテゴリで整理。ゼロトラストのNSTACステップ①と完全に一致する起点。
②Discovery(発見)定義した範囲の中で、既知・未知の脆弱性・設定ミス・露出面を継続的に発見する。SBOMやASM(Attack Surface Management)ツールを活用。AIエージェントのMCPサーバー・APIも新カテゴリとして追加。
③Prioritization(優先順位付け)発見した問題の中から「攻撃者が実際に悪用できるか」を軸に優先順位を決める。リスクベーストリアージの複数要素(CVSS・EPSS・資産価値・攻撃経路・ビジネス影響度)を組み合わせて評価し、CVSSはその一要素として使う。Mythosクラスの攻撃が狙う「認証情報・高価値DB・内部API」を優先。
④Validation(検証)Breach & Attack Simulation(BAS)やペネトレーションテスト等で「実際に攻撃が通るか」を検証する。スコアではなく実証で優先度を確認する。ZTポリシーのセグメンテーションが有効に機能しているかの検証にもなる。
⑤Mobilization(実行・定着)修復・軽減策の実行を組織として定着させる。担当チーム・タイムライン・KPIを定義しサイクルで回す。VulnOpsループに統合する。

4.VulnOps×CTEMの実装フレームワーク

VulnOpsのループとCTEMの5ステップを統合した実装フレームワークを以下に示す。理論ではなく「すぐに始められる」具体的なステップとして構成した。

ステップ① プロテクトサーフェスとアタックサーフェスの棚卸し(Scoping+Discovery起点)

まず「守るべきもの」と「攻撃者から見える面」を一致させる。ゼロトラストで定義したDAASをCTEMのScopingに直結させる。これにより「VulnOpsが何を守るか」と「ZTが何を制御するか」が同じ土俵で管理できる。

AIエージェントが使うMCPサーバー・APIも、今後この棚卸しの対象として加える必要がある。Agentic Supply Chainのリスクは、エージェントが接続する外部サービスから侵入するパターンが増えている。

ステップ② リスクベースのトリアージ(CVSSを超える優先順位付け)

発見した脆弱性をリスクベーストリアージで評価する。CVSSは脆弱性の技術的特性を標準化した指標であり、リスク評価の一要素に過ぎない。CVSS、EPSS、資産価値、攻撃経路、ビジネス影響度を組み合わせて「本当に悪用可能か」を評価することが基本である。

ここで、EPSSについて説明すると、EPSS(Exploit Prediction Scoring System)は、特定のCVEが今後30日以内にどこかで悪用される可能性を0〜1のスコアで予測する指標である。CVSSが「脆弱性の技術的特性」を示すのに対し、EPSSは「実際に攻撃に使われる可能性の予測」を示している。CVSSが高くてもEPSSが低ければ修復の緊急度は相対的に下がる。Mythosクラスの攻撃AIは実際に悪用可能な脆弱性を優先的に標的にするため、EPSSによるフィルタリングは特に重要である。

ステップ③ Breach & Attack Simulation(BAS)による実証検証

CTEMのValidationフェーズに対応する。スコアではなく「実際に攻撃が通るか」を自動化されたシミュレーションで確認する。BAS(Breach and Attack Simulation)は実際の攻撃者の戦術・技術・手順(TTP)を安全な環境でエミュレートし、セキュリティコントロールが実際に機能しているかを継続的・自動的に検証するツールだ。ファイアウォール・EDR・SIEMが期待通りに動作しているか、ゼロトラストのセグメンテーションが横展開を実際に阻止できるかを実証する。ペネトレーションテストを補完するが完全に置き換えるものではない。 ペネトレーションテストとの違いは「継続性」である。ペネトレーションテストは年1〜2回の点検であるのに対し、BASは環境変化のたびに再実行できる。MythosクラスのAIが修復猶予を数時間レベルに縮小させる可能性がある時代に、年1回の点検では間に合わない。

ステップ④ 修復とZTポリシーの連動更新

脆弱性を発見・検証した場合、パッチ適用を最優先に行う。パッチがない場合・適用までに時間がかかる場合は、ゼロトラストのポリシーを一時的に強化することで影響を軽減する。以下のような対応が考えられる:

  • 発見された脆弱性のあるシステムへのアクセスを一時的にゼロトラストポリシーで制限する
  • 当該システムのセグメンテーションを強化し、横展開の経路を塞ぐ
  • パッチ適用後にポリシーを通常状態に戻し、BASで検証する

ステップ⑤ AIエージェントによる自動化とHuman-in-the-Loop

VulnOpsの各ステップにAIエージェントを組み込むことで、人間が追いかけられない速度のCVE増加に対応できる。ただしAIエージェントを「信頼されたオペレータ」として無制限に動かすことは、エージェント自体が攻撃の踏み台になるリスクを生む可能性がある。パッチ適用やポリシー変更を自律的に実行する権限を持つエージェントが侵害されれば、攻撃者はそのエージェントを通じて組織全体に影響を及ぼすことができる。CSAIのAgentic Control Planeが定義する5要素、すなわちエージェントのID管理(Identity)・何を許可するかの定義(Authorization)・複数エージェント間の調整(Orchestration)・実行時の行動監視(Runtime Behavior)・継続的な信頼検証(Trust Assurance)を、VulnOpsの自動化設計に組み込む必要がある。

AIエージェントをVulnOpsに組み込む際には以下の3点を考慮する:

  1. エージェントにもIDと最小権限を付与する(Identity・Authorization)。
  2. エージェントが実行する修復アクション(パッチ適用・ポリシー変更)は人間の承認ゲートを通す(Human-in-the-Loop)。
  3. エージェントの行動を継続的に監視し、異常な操作を検知する(Runtime Behavior)。VulnOpsを自動化することと、AIエージェントを無制限に動かすことは別の話である。

5.3層が育つ循環

ここまでの実装フレームワークを3層の循環として整理する。まず3層を簡単に復習しておく。

  1. 【第1層:基本的なセキュリティ対策】資産管理・パッチ適用・ログ収集・バックアップ・インシデント対応手順。すべての土台となる。
  2. 【第2層:ゼロトラスト】「信頼しない・常に検証する」のアーキテクチャ。プロテクトサーフェスを定義し、マイクロセグメンテーションと継続的検証で攻撃者の難易度を上げる。
  3. 【第3層:VulnOps・CTEMとAIエージェント】攻撃者に悪用される前に脆弱性を発見・修復する継続的な運営体制。

3層は順番に完成させるものではなく同時に育てるものである。たとえば、VulnOpsとCTEMを第3層として動かすことで、第1層と第2層にどう還流するかの例を以下に示す。

  • 【第3層→第1層】VulnOpsで発見された脆弱性は第1層のパッチ適用に直結する。継続的スキャンが「今週直すべき脆弱性」を特定し、パッチ適用を優先順位付きで実行する。
  • 【第3層→第2層】VulnOpsで発見されたリスクの高い経路は、即座にゼロトラストのポリシーに反映される。パッチがない期間のリスクをゼロトラストが一時的に軽減する。
  • 【第2層→第3層】ゼロトラストのプロテクトサーフェス定義がVulnOpsの対象資産を決め、セグメンテーションの設計がCTEMのScoping範囲を決める。
  • 【第1層→第3層】資産管理が整備されているほど、VulnOpsのカバレッジが上がる。ログ基盤が整備されているほど、BASの検証精度が上がる。

重要なのは「3層のどれかが完成してから次に進む」のではなく、「各層が少しずつ成熟するたびに全体のリスクが下がっていく」ということである。VulnOpsの最初のスキャンが粗くても、ゼロトラストのプロテクトサーフェスが一つだけでも、始めることに意味があると考える。

6.「AI脆弱性の嵐、CISOが押さえるべき重要ポイント」とブログの対応

ここで、「Mythosレディとは何か」の3つのブログと、「AI脆弱性の嵐」において「CISOが押さえるべき重要ポイント」と説明されている8つのポイントとの対応を明確にしてみたい。

  1. LLMベースの脆弱性発見・修復能力を活用する
    「Mythosレディとは何か ~ 機械速度の攻撃時代における組織生存の条件」(ここからは「第1回と表記」)で、AIエージェント資産の把握として部分的に言及。「Mythosレディとは何か(続編) ~ Mythosレディにゼロトラストが有効な理由」(ここからは「第2回」と表記)では未扱い。本ブログ(ここからは「第3回」と表記)のVulnOps/CTEMが主テーマとして詳述。
  2. リスク・メトリックスを更新する
    第1回でCVSSではなく実際の悪用可能性で判断する考え方を言及。第3回でEPSS・リスクベーストリアージとして言及。
  3. コーディングエージェントの活用でチームを加速させる
    第3回でAIエージェントのVulnOps組み込みとして部分的に言及。
  4. より多くのインシデントへの対応を準備する
    第1回でセグメンテーション・egress等を言及。第2回でZTA・フィッシング耐性MFA・egress・セグメンテーションを詳述。第3回でゼロトラストポリシーとの連動として言及。
  5. 基本の強化に注力する
    第1回で基本強化の5領域(資産管理・セグメンテーション・パッチ管理・IAM・多層防御)として詳述。第2回で第1層として言及。第3回で第1層への還流として言及。
  6. 機械並みのスピードで迫る脅威には、人手だけでは太刀打ちできない。優先順位を見直し、業務を自動化し、バーンアウトに備える
    第1回・第2回・第3回すべてで未扱い。下記で補足。
  7. Mythosレディなセキュリティプログラムへ進化する
    第1回でMythosレディの定義・構造的リスクとして詳述。
  8. 今すぐ業界横断的な共同防御(Collective Defense)を構築する
    第1回・第2回・第3回では未扱い。集団防衛は下記で補足。

3つのブログでカバーできていない2つのポイントについて、以下に補足する。

バーンアウト対策

Mythos時代における脆弱性の爆発的増加は、セキュリティチームの作業量を構造的に増大させる。パッチ対応、インシデント対応、VulnOpsの継続運営が同時に求められる中で、既存の人員体制では限界が来る。本ブログで説明してきたAIエージェントによる自動化は、この問題への現実的な答えの一つである。ただし自動化整備には時間がかかる。その移行期間中、人間のチームが過負荷に陥らないための予備キャパシティと、チームのメンタルヘルスへの配慮が経営課題として浮上する。CISOはセキュリティの技術的課題と同時に、チームの持続可能性を考える必要がある。

業界横断的な共同防御

VulnOpsとCTEMは一組織内で閉じた取り組みとして機能するが、Mythosクラスの攻撃は産業横断的に同時多発する可能性がある。一組織が発見した脆弱性情報、攻撃パターン、修復知見を業界全体で共有することが、集団としての防御力を高めていく。JPCERT/CCや各業界のISACがこの役割を担っている。自組織のVulnOpsで得た知見をこれらの機関に積極的に共有し、逆に業界の脅威インテリジェンスをVulnOpsのトリアージに取り込むことが、Mythosレディを社会的に強化する道筋となる。

まとめ

VulnOpsとCTEMは「導入完了」という状態が存在しない。継続的に回し続けることが目的であり、回し始めることが成果である。「守るべき資産を一つ特定し、スキャンし、優先度をつけ、修復し、検証する」というような小さなサイクルを組織の習慣として定着させることがMythosレディへの道筋と考える。

これで、「Mythosレディとは何か」のブログシリーズ(3回連載)を終了する。次のブログでは、CSAがRSAC 2026で発表したCSAI Foundationが2026年のミッションとして掲げている「Securing the Agentic Control Plane」について考察する予定である。AIのリスクはLLMモデル自体の安全性にとどまらず、エージェントがシステムに接続し、ツールを実行し、他のエージェントと連携する複雑なエコシステム全体——identity・authorization・orchestration・runtime behavior・trust assurance——へと拡大している。CSAIはこの領域を6つの戦略プログラム(AI Risk Observatory・Agentic Best Practices・Education & Credentialing・CxOtrust・Global Assurance・Future Forward)で包括的に取り組んでいる。次回はこの枠組みについて考えてみたい。(出典:https://csai.foundation/csai-mission)

以上

Mythosレディとは何か(続編) ~ Mythosレディにゼロトラストが有効な理由

2026年6月3日
AIWGメンバー 諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに:前回のおさらいと本ブログの位置づけ

前回のブログ「Mythosレディとは何か ~ 機械速度の攻撃時代における組織生存の条件」では、機械速度の攻撃が常態化した世界において組織が生存できる状態を維持することの重要性について説明した。Mythosは「すごいハッキングツール」への対抗問題ではなく、AIが攻撃サイクル全体を自律実行できる時代における構造的リスクであることを認識することが重要である。

本ブログではその続編として「なぜゼロトラストがMythosレディに有効なのか」について考察する。ゼロトラストは2010年代から語られてきた概念だが、Mythosの登場によってその意義が根本的に変わってきたと言える。つまり、「機械速度の攻撃環境で生き残るためにゼロトラストが有効である」ということである。本ブログでは、従来型セキュリティはなぜMythos時代に機能しなくなるのか。そして「信頼しない・常に検証する」というゼロトラストの原則がなぜ機械速度の攻撃に対して構造的に有効なのかを考えてみる。 

1.なぜゼロトラストがMythosレディに有効なのか

ゼロトラストとは「Never Trust, Always Verify(何も信頼せず、常に検証する)」という設計思想であり、製品でも特定技術でもない。その必要性はMythos以前から指摘されてきたが、Mythosが変えたのは「ゼロトラスト未導入組織が直面するリスクの速度・規模・緊急性」である。Mythosが加えたのは「ゼロトラストを導入していない組織のリスクが機械速度で顕在化する」という緊急性である。Mythosはゼロトラストを「いつかやるべきもの」から「今すぐでないと間に合わないもの」に変えたと言える。

以下、代表的な5つの理由でゼロトラストの各要素がMythos時代に持つ意義を考える。

①横展開(lateral movement)を構造的に阻止する

AIによる自律的な攻撃の実例が示すように、Mythosクラスの能力を持つAIによる攻撃は一点の侵入後に社内を自律的に横展開する。従来の境界防御では、境界を突破した攻撃者は社内を自由に動き回れることになる。

ゼロトラストはマイクロセグメンテーションによって、攻撃チェーンの各ステップで認証・認可が必要になるため、AIが自律的に横展開しようとするたびに阻まれることになる。

②最小権限が攻撃チェーンを分断する

「AI脆弱性の嵐」の「CISOが押さえるべき重要ポイント」において、「セグメンテーション、egressフィルタリング、ゼロトラスト・アーキテクチャ、フィッシング耐性のある多要素認証、シークレットのローテーションといった緩和コントロールを検証・有効化しエクスプロイトが発生した場合の影響を最小化する」と明示している。最小権限はこの「影響を最小化」を実現する最も直接的な手段である。以下、その理由についていくつか挙げる。

  • エージェント、ユーザー、サービスアカウントすべてに最小権限を適用する
  • Just-in-Time(JIT)アクセス: 必要な時だけ、必要な期間だけ権限を付与する
  • 過剰権限の定期棚卸し: 誰も使っていない権限を排除する
  • AIエージェント自体にも最小権限を適用する(次世代の課題:AIエージェントが組織全体に普及するにつれ、エージェント自体に付与する権限の管理がAgentic Control Planeの核心課題となると考える)

③継続的検証が「見えていない攻撃」を早期発見する

「AI脆弱性の嵐」のリスクレジスターはリスク#4として「AIが複雑な攻撃を構築するために必要な洗練度と時間が短縮されており、防御側の検知・対応能力はまだこれに追いついていない」と指摘している。また優先アクションPA9・PA10では行動監視・デセプション技術・自動化された対応能力の整備を求めている。

ゼロトラストの「継続的検証」は、ユーザーが一度認証すれば後は信頼されるというのではなく、行動・デバイス状態・アクセスパターンを常時監視・評価し続けることを求めている。これにより以下のようなことが可能になる可能性がある:

  • 認証情報が盗まれても、「いつもと違う行動」を検知できる
  • AIが自律的に異常な頻度でアクセスすれば、行動異常として検出される
  • AIが自律的に生み出す「人間の操作では考えられない速度・頻度のリクエストパターン」が早期に検知できる

④egressフィルタリングとの相乗効果

「AI脆弱性の嵐」の優先アクションPA8は「egressフィルタリングを実装すること(log4jの公開エクスプロイトをすべてブロックした実績がある)」と明示している。

多くの組織ではファイアウォールのinbound制御に注力する一方、outbound(内→外)の通信はデフォルトで広く許可されていることが多い。egressフィルタリングはこのoutboundを厳格に制御する対策であり、ゼロトラストと組み合わせることで相乗効果を発揮する。それは、Mythosクラスの能力を持つAIが生成した攻撃コードがC2サーバーに通信しようとする際、egressフィルタリングがこれをブロックすることが可能になる。

⑤フィッシング耐性MFAで認証情報窃取を無効化する

「AI脆弱性の嵐」の「CISOが押さえるべき重要ポイント」において、緩和コントロールとして「フィッシング耐性MFA」を明示し、PA8では「すべての特権アカウントにフィッシング耐性MFAを義務化する」としている。従来のSMS認証などはリアルタイムフィッシングで突破される可能性があるが、FIDO2/パスキーはフィッシングページに誘導されても認証情報を盗めない設計になる。

ゼロトラストは「常に検証する」原則として強力な認証を求めている。「AI脆弱性の嵐」はその実装としてフィッシング耐性MFAを推奨しており、FIDO2/パスキーはその代表例となる。

2.ゼロトラストはMythosレディの「時間を稼ぐ」戦略である

ゼロトラストはすべての攻撃を防ぐ魔法ではない。しかし「時間を稼ぐ」という観点でMythosレディに本質的に有効であると考える。

以前のブログ「ゼロトラストとCIA(後編) ~ 情報セキュリティはコントロール可能にすること」で、情報セキュリティの目的は「コントロール可能にすること」とした。攻撃を100%防ぐことは不可能だが、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することを目的とすべきと考える。ゼロトラストはまさにこの「コントロール可能な状態」を実現するアーキテクチャである。

それでは、発見から武器化まで数時間のMythos時代において、ゼロトラストが「時間を稼ぐ」とはどういう意味となるのか。

この「時間を稼ぐ」ことの意味について以下のように考える:

  • 侵入から被害拡大までの時間を延ばす(マイクロセグメンテーションによる横展開阻止)
  • 被害範囲を小さく封じ込める(最小権限による爆発半径の制限)
  • 「見えていない攻撃」を早期に検知する(継続的検証による異常検出)
  • 人間が対応できる時間を確保する(機械速度の攻撃に対して「止める機会」を作る)

それでは、「時間を稼ぐ」ことがなぜ重要なのであろうか。Mythosレディは一夜にして完成するものではない。今すぐゼロトラストを導入することで、次の波・より高度な攻撃が来るまでの間に、VulnOpsやAgentic Control Planeの体制を整える時間を確保していくことを考えるべきと考える。

3.NSTACの5つのステップで実装するゼロトラスト

以下では、NSTACゼロトラスト・フレームワークに基づいて、この5ステップそれぞれがMythosクラスの能力を持つAIの攻撃チェーンのどの段階に対応するかを整理してみる。

ステップ本来の目的Mythostとしての意味
① プロテクトサーフェスの定義守るべき対象(DAAS)の特定と、そのプロテクトサーフェスの設定Mythosクラスの能力を持つAIによる攻撃が狙う認証情報、高価値DB、内部APIの棚卸し。
② トランザクションフローの把握データ・通信の流れを可視化AIエージェントがどのMCPサーバー、APIに接続しているかのマッピングに適用。
③ ゼロトラストアーキテクチャの設計プロテクトサーフェスにコントロールを配置マイクロセグメンテーション、最小権限、egressフィルタリングを組み合わせる。
④ ゼロトラストポリシーの策定5W1Hに基づいて、アクセスするかをポリシーに明記。人間向けのアクセスポリシーに対して、AIエージェントにも同じ枠組みが必要になる。エージェントID、許可するツールなどの要否を明記する。
⑤ 監視と維持テレメトリーの継続収集と改善フィードバック発見された脆弱性を即座にプロテクトサーフェスの定義とポリシーに反映する。「Long-term=1四半期」でサイクルを回す。

なお、5ステップは一度やれば完了するものではなく、プロテクトサーフェスを定義・実装するたびに①から繰り返す。この反復のたびに組織のゼロトラスト成熟度は少しずつ上がっていく。最初から完璧なゼロトラスト環境を目指すのではなく、「守るべき資産を特定し、そこにゼロトラストを適用し、監視する」という小さなサイクルを回し続けることが、現実的な道筋である。

4.おわりに:ゼロトラストは手段であり、目的はコントロール可能な状態

ゼロトラストがMythosレディへの「解答」ではないが、「機械速度の攻撃時代に組織が生存できる状態を維持する」ための最も重要な構造的基盤の一つであると考える。

ゼロトラストの前にある「基本的なセキュリティ対策」という土台

ここで重要な視点を加えたい。ゼロトラストは「基本的なセキュリティ対策」の上に成り立つものであって、代替するものではない。「AI脆弱性の嵐」が「基本に立ち返り、環境をさらに強化する」をCRITICALな優先アクションとしている理由がここにある。

そこで、以下の3層をMythosレディへの道として定義したい:

  1. 第1層:基本的なセキュリティ対策
    資産管理、パッチ適用、ログ収集、バックアップ、インシデント対応手順など。第2層・第3層を育てながら、並行して継続的に強化する土台。
  2. 第2層:ゼロトラスト
    プロテクトサーフェスを定義するたびに少しずつ育てる。完成を待たずに第3層と並行して進める。
  3. 第3層:VulnOps、Agentic Control Plane
    第2層の成熟を待たずに着手できる部分から始める。

これらの3層が互いの成熟を促し合うプロセスとなる。3層は相互に依存し、第1層のログ基盤が第2層の継続的検証を強化し、第2層のプロテクトサーフェスの定義が第3層のVulnOpsの優先順位を決めていくことになる。また、第3層で発見された脆弱性が第1層のパッチ適用と第2層のポリシー更新に反映される。この循環がMythosレディに導いていくと考えられる。

3層が揃って初めてMythosレディになる

上記の3層は順番に行っていくものではない。3層を順番に完成させようとすると、「ゼロトラストが完成してからVulnOpsを始める」とか「基本対策が完璧になったらゼロトラストを導入する」となるが、そうではない。3層を同時に育てること、つまり、小さなプロテクトサーフェスから始め、ゼロトラストとVulnOpsを並行して育てるというような、基本対策の改善とゼロトラスト導入を同時進行させることで、各層が少しずつ成熟するたびにリスクが下がっていくことになる。これにより、Mythosレディへ着実に近づいていくことができると考える。つまり、基本的なセキュリティ対策(資産管理、パッチ、ログ、バックアップ、インシデント対応など)という土台の上に、ゼロトラストというアーキテクチャを重ね、さらにVulnOps、Agentic Control Planeへと発展させるという3層の積み重ねが「Mythosレディ」を実現するための重要なステップであると考える。

次回のブログでは「VulnOpsとCTEM:継続的脆弱性管理の具体的な実装」を取り上げる予定である。ゼロトラストで攻撃者の難易度を上げながら、VulnOpsで脆弱性を先に発見・修復するという両輪が、Mythosレディの中核を形成するものと考える。

以上

Mythosレディとは何か ~ 機械速度の攻撃時代における組織生存の条件

2026年5月26日
AIWGメンバー 諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに

2026年4月7日、AnthropicがClaude Mythos Previewを公式発表した(出典:red.anthropic.com)。このモデルは汎用LLMであり、セキュリティ専用ツールとして設計されたわけではないが、コーディングと推論能力の向上から「自然に発生した」として際立ったセキュリティ能力を示した。代表的な成果として、Firefox 147 JavaScriptエンジンを対象とした特定のテストハーネスで181件の動作するexploitを生成した(同条件でClaude Opus 4.6は2件)。また約1,000回の試行・約2万ドルの計算コストをかけたキャンペーンで、27年間専門家の審査・ファジング・自動スキャンをくぐり抜けてきたOpenBSDのTCP SACK実装の脆弱性(DoS)を発見した。

「AI脆弱性の嵐」(CSA/SANS/OWASP/[un]prompted 緊急戦略ブリーフィング)
Mythosの発表から6日後の2026年4月13日、CSA, SANS, OWASP, [un]promptedの共同により「AI脆弱性の嵐(AI Vulnerability Storm):Mythosレディなセキュリティプログラムの構築」が緊急公開された(現在v1.0、日本語版はV0.4)。60名以上の寄稿者・250名以上のCISOがレビューしたこの文書は、Mythosの登場を「最初の波に過ぎない」と位置づけ、CISOがすぐに実行できる具体的な行動指針を提示している。CSAジャパンでは、2026年5月25日にWGセミナーを行い、この文書の内容、CSAI foundationのミッション等について参加者とディスカッションを行った。

本ブログはこの文書の内容およびWGセミナー(2026年5月25日)でのディスカッションに基づいている(注:WGセミナーの資料およびビデオ録画はこちらの「WGセミナー:ビデオ録画、資料」のウエブページより参照)。

「AI脆弱性の嵐」の文書が明確にしている点は、Mythosの登場で生じた「AI脆弱性の嵐」は単一モデルへの対応問題ではないということである。AIが脆弱性発見のコストとスキルの敷居を、組織がパッチを適用できる速度よりも速く引き下げており、発見から武器化までの時間が数時間レベルに短縮されるという構造的な変化である。従来のパッチサイクル・対応プロセス・リスク指標はこのような環境を前提として設計されていない。

したがって、Mythosの登場が示したのは、「Mythosというすごいツールにどう対抗するか」ではなく、AIが攻撃サイクル全体を自律実行できる時代の到来という構造的な転換点である。この転換は、セキュリティの問題を超え、事業継続・安全工学・オペレーションレジリエンス・危機管理にまたがる社会システム全体の設計問題を提起している。

1.Mythosレディとは何か:ツール対抗ではなく構造的リスクへの認識

「Mythosレディ」という概念は、しばしば誤解されている。それは「Mythosというすごいハッキングツールに対抗する体制を整える」ということではない。つまり、脅威論として捉えるべきではない。Mythosレディとは、機械速度の攻撃が常態化した世界において、組織が生存できる状態を継続的に維持することである。重要なのは「Mythos」という特定のモデルへの対応ではなく、その背後にある構造的リスクを認識することである。防御と攻撃が同じ能力空間に存在し、高度なコード理解能力は、自然に攻撃構造理解へと接近する。これは特定ベンダーの問題ではなく、技術進化の構造的必然であるといえる。

「Mythosレディ」は以下の例のように考えられる。

Mythosレディではない状態Mythosレディな状態
四半期ペネトテストを実施している継続的・自動化されたスキャン
CVSSスコアでパッチ優先度を決めている自環境での実際の悪用可能性で判断
月次でセキュリティレポートを出しているリアルタイムのリスクダッシュボード
インシデント対応は人間チームが担当AIエージェントが初動・人間が監督

2.なぜ従来のセキュリティモデルは機能しなくなるのか:非対称性の構造

AIが攻撃サイクル全体を自律実行できる世界では、従来のセキュリティモデルは根本から機能しなくなる。その理由は「非対称性」にある。

機械速度 vs 人間速度の非対称性

攻撃側(AI)防御側(人間)
脆弱性発見 → exploit生成 → オペレーション実行を機械速度で自律完結検知→分析→対応→修復を人間速度で処理
発見から武器化まで:数時間(2026年)四半期ペンテスト・月次パッチサイクル
複数システムへの同時並行攻撃インシデントは1件ずつ対応(直列処理)
攻撃者は「一箇所突ければいい」防御側は「全部守らなければならない」

この非対称性は技術的なものだけではない。文化的・組織的な非対称性でもある。AIを活用しない防御チームは、技術スキルに関わらず、AI武装した攻撃者のスピードや規模に対抗することができなくなる。

つまり、「機械速度の攻撃に対しては機械速度の防御しか対抗できない」という現実を受け入れ、AIエージェントを例外的ツールではなく防御の基盤として制度化することが求められる。

3.これはサイバーセキュリティの課題を超えた社会システム設計の問題である

Mythosの影響は「サイバーセキュリティの問題」にとどまらない。人間の制御速度を超えた自律システムが存在する世界で、社会システム全体をどう設計・運営・管理するかという根本的な問いを提起している。

安全工学への影響

従来の安全工学は「障害は人間のミスか機械の故障」を前提とし、原因分析が可能で、設計段階でリスクを織り込めるという前提に基づいていた。 Mythosが崩す前提は「静的安全設計」である。昨日まで安全だったシステムが今日から危険になる。設計の思想は「壊れないように作る」から「壊されることを前提に設計する」へ転換しなければならない。

オペレーショナルレジリエンスへの影響

従来のBCP/DRは「障害からの復旧」を想定していたが、Mythos時代では復旧インフラ自体が攻撃対象になる。バックアップシステムの完全隔離、サプライチェーン全体でのレジリエンス評価が必須となる。

危機管理への影響

従来の危機管理は「発生を人間が認識できる」「対応に時間的猶予がある」を前提としていた。しかし複数の重大インシデントが同時発生し、発見した時には手遅れになっている可能性がある世界では、事前承認済みプレイブックとAIエージェントによる初動の自動化が不可欠となる。

これらの3つの領域に共通する点として、「人間の制御・認識・対応速度」を超えた自律システムが存在する世界で、社会システム全体をどう設計・運営・管理するかということであり、これに対する回答が「エージェンティックコントロールプレーン(Agentic Control Plane)のガバナンス」ということになる。

4.次の波に備える:Mythosは最初の波に過ぎない

Mythosの登場は「臨界点」として語られることが多いが、より正確には「能力進化の連続性の中で社会が初めて広く認識した転換点」である。

現在の第一波の正確な姿は、脆弱性発見・エクスプロイト生成・攻撃チェーン構築・オペレーション実行が最小限の人間入力で自律的に完結している。現在のMythosはまだ「人間が介在できる機械速度・規模」にとどまっている。アクセスは限定されており、複雑な標的には人間の方向づけが一部残る。しかし次の波では状況が変わる。

次の波のシナリオ

  • 第二波:自律エージェントによる継続・横展開・長期運用の完全自動化
  • 第三波:Mythos級能力の民主化(誰でも使える状態への拡散)
  • 第四波:電力・医療・金融・水道等の社会インフラへの攻撃

英国AISIの独立評価(2026年5月)では、GPT-5.5とMythosは同一ベンチマーク上のスコアが誤差の範囲内で収束していることが確認された(GPT-5.5:71.4%、Mythos:68.6%)。ただし能力の質・アライメント・セーフガードの強度は異なる。より重要なのは、フロンティアサイバー能力が単一ベンダーに限定されなくなったという構造的収束であり、「Mythosだけを管理すれば良い」という発想は、すでに現実から離れつつある。 だからこそ、「Mythos対応」という短期的・特定モデル対応の発想ではなく、「次の波・その次の波が来ることを前提とした継続的適応体制の構築」という長期的・構造的な視点が必要である。ただし、長期的という行動のために利用可能な時間は縮小している。戦略計画の最長単位は「1四半期」と考えるべきである。ロードマップは四半期単位で継続的に更新される設計でなければならない。

5.今すぐ始めること:基本の強化とコントロール可能な状態の実現

「機械速度の攻撃が来る前に、今できることをやる」。これがMythosレディへの最も重要な第一歩である。

情報セキュリティの目的:コントロール可能にすること

先のブログ「ゼロトラストとCIA(後編) ~ 情報セキュリティはコントロール可能にすること」では、セキュリティの本質的な目的を「コントロール可能にすること」とした。攻撃を100%防ぐことは不可能だが、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することはできる。 この「コントロール可能な状態」を実現するための基盤が、まず基本的なセキュリティの強化である。高度な攻撃への対策より、基本の穴を塞ぐことが先決である。攻撃者は最も弱い点を狙う。

今すぐ取り組む基本強化の5領域

1. 資産管理:守るべき対象を把握していない状態で対策はできない

  • ITインベントリ:サーバー・PC・クラウドインスタンスの継続的把握
  • SBOM:使用しているOSSライブラリ・依存関係の管理
  • シャドウIT・未管理資産の自動発見:攻撃者が最も狙う「見えていない穴」
  • AIエージェント資産の把握:動作中エージェント・権限・MCPサーバーの新カテゴリ

2. ネットワークセグメンテーション

  • 内部ネットワークを機能・リスク別に分離し、横展開(lateral movement)を遮断する
  • Mythos時代:攻撃チェーンの連鎖を物理的に切断する最も効果的な手段

3. パッチ管理の継続化

  • KEV(既知悪用脆弱性)リストの優先的・継続的対応:CVSSスコアではなく実際の悪用リスクで判断
  • クリティカルパッチは24時間以内の適用を目標とする
  • パッチdiff分析:パッチ公開が即座にexploit設計図になる逆説を認識する

4. アイデンティティとアクセス管理(IAM)

  • 最小権限の原則の徹底:必要最低限のアクセスのみ付与・過剰権限の定期棚卸し
  • AIエージェント自体への最小権限適用:エージェントの過剰権限が攻撃のリスクになる
  • フィッシング耐性MFA(FIDO2等)の全社的展開

5. 多層防御の再設計

  • 単一コントロールへの依存を排除:1つの防御が破られても次の層が機能する設計
  • egressフィルタリング:不審な外部通信の自動遮断
  • 継続的モニタリング:「見えていない攻撃」を検知する仕組みの整備

時間的余裕がある今のうちにこれらの取り組みを拡大していくことが必要である。Mythos能力の民主化が進む前に基盤を固めることが、組織が生存できる状態を維持するための最優先事項である。

おわりに:Mythosレディは到達点ではなく継続的な状態である

Mythosレディとは、特定の脅威に対応した状態のことではない。機械速度の脅威環境に継続的に適応し続けられる組織状態のことである。 「Mythosレディ」セキュリティプログラムの構築は、1つのモデルや発表に反応することではない。脆弱性が発見される速度と組織が対応できる速度のギャップを恒久的に埋めることである。

Mythosの影響を「サイバーセキュリティの問題」として矮小化してはならない。それは「人間の制御速度を超えた自律システムが存在する世界で、社会システム全体をどう設計・運営・管理するか」という問いであり、セキュリティ担当者だけではなく、経営層・取締役会・社会全体が向き合うべき課題である。 そして、その答えの第一歩は「今すぐ基本を強化し、コントロール可能な状態を実現すること」にある。

補足:CSAIのスタンスとミッション:制度として応答する

CSAは、AIセキュリティ・セーフティに特化した新しい非営利財団「CSAI Foundation」を正式に設立した。そのミッションは以下である。

「エージェンティックコントロールプレーン(Agentic Control Plane)をセキュアにする)」——自律型AIエージェントエコシステムを支えるアイデンティティ・認可・オーケストレーション・ランタイム動作・トラスト保証の層を統治すること。

CSAIのスタンスは明確である。Mythosを「危険なAIの登場」として警戒するのではなく、「エージェントAIが自律的に動く世界において、その制御・監視・信頼の仕組みを社会基盤として確立する」という建設的・制度的に答えることである。

CSAIの6つの戦略プログラム

  • AIリスクオブザーバトリー:MCPサーバーエコシステムの継続監視・CVE番号機関(CNA)として認定・RiskRubricによるリスクスコアリング
  • エージェンティックベストプラクティス:セキュアなエージェント実装のフルライフサイクルガイダンス・非人間アクターのID管理・権限ガバナンス
  • 教育&資格認定:TAISE Agentic(実務者向け)・TAISE CxO(経営幹部向け)・将来的にはエージェント自体を認定するTAISE-Agent
  • CxOトラストCレベルリソース:経営層・取締役会がAIリスクを経営判断に変換するための支援
  • グローバルアシュアランス&トラスト:NIST AI RMF・EU AI Act・ISO/IEC 42001との整合。STAR for AI Catastrophic Risk Annexによる最悪シナリオの監査可能化
  • フューチャーフォワード:既存標準のAIギャップ評価・統合リサーチの開発・CVE/MITRE/OWASPとの連携

以上

 「AI脆弱性の嵐 (AI Vulnerability Storm)」: 「Mythosレディ」なセキュリティプログラムの構築」を公開しました。

2026年4月19日
CSAジャパン 諸角昌宏

本ブログでは、「AI脆弱性の嵐 (AI Vulnerability Storm)」: 「Mythosレディ」なセキュリティプログラムの構築」について記載します。

「AI脆弱性の嵐 (AI Vulnerability Storm)」: 「Mythosレディ」なセキュリティプログラムの構築」は、CSA CISO Community, SANS, [un]prompted, the OWASP Gen AI Security Project,等のコミュニティが公開した「The “AI Vulnerability Storm”: Building a “Mythosready” Security Program」をCSA本部の承認のもとに翻訳して公開したものになります。
AIを活用した脆弱性発見とエクスプロイト開発は劇的に加速しています。脆弱性の公開から悪用されるまでの期間は短縮しており、セキュリティチームには、現在の運用モデルでは対応しきれないほどの迅速な対応が求められています。本ブリーフィングは、CISOおよび経営層向けの枠組みと実践的なガイダンスとして、AI主導の攻撃が新たな基準となった世界で活動するために必要な、即時の対応策、短期的な優先事項、そして長期的な変革の概要を解説しています。
なお、本資料は、16名の著者、約250名のCISOおよび実務家によるレビューア、CISA、NSA、ホワイトハウスの元幹部らによる驚くべき共同作業で作られています。

こちらからダウンロードしてご覧ください。