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

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

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

第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／CAASM	Scoping・Discovery の資産発見
SSPM	SaaS スコープの 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月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が脆弱性発見から武器化までの時間をさらに圧縮し、組織が利用できる修復猶予を数日から数時間レベルへ縮小させる可能性がある時代に、従来の脆弱性管理はなぜ機能しないのか。そして何に変わるべきか」について考えていく。

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

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

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化）」へ

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

２．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））を「同時に育てる」ことになる。

３．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ループに統合する。

４．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エージェントを無制限に動かすことは別の話である。

５．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で発見されたリスクの高い経路は、即座にゼロトラストのポリシーに反映される。パッチがない期間のリスクゼロトラストTが一時的に軽減する。
• 【第2層→第3層】ゼロトラストのプロテクトサーフェス定義がVulnOpsの対象資産を決め、セグメンテーションの設計がCTEMのScoping範囲を決める。
• 【第1層→第3層】資産管理が整備されているほど、VulnOpsのカバレッジが上がる。ログ基盤が整備されているほど、BASの検証精度が上がる。

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

６．「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）

以上