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つのフェーズ
- Scoping（スコープ定義）：何を守るかを決める。ビジネス上の優先度に従い、対象資産と攻撃面を定義する。初期スコープには外部攻撃面（インターネット露出資産）と SaaS セキュリティポスチャを含めるのが一般的。
- Discovery（発見）：スコープ内の資産と弱点を洗い出す。CVE だけでなく、設定ミスやあらゆる露出を対象に含める。
- Prioritization（優先順位付け）：重要資産を脅かす、実際に悪用可能な攻撃経路に絞る。アラート過多を解消し、本当に重要な脅威へ集中する。
- Validation（検証）：攻撃者の手法を模倣し、その露出が自社環境で本当に悪用可能かを実証する。BAS（Breach and Attack Simulation）や継続的ペンテストが該当し、過検知を排除できる。ここがCTEM独自の強み。
- 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サイクル通し
- Scoping：今四半期は「外部攻撃面 ＋ 主要 SaaS」を対象に設定
- Discovery：EASM・SSPM・スキャナの結果を統合プラットフォームへ集約
- Prioritization：攻撃経路マッピングで、重要資産に至る連鎖だけを抽出
- Validation：BAS でその経路が実際に通るか実証し、偽陽性を除外
- Mobilization：残った真のリスクを ITSM へ自動起票し、IT／アプリ／SOC へ分配
- 一周して終わりではなく、同じサイクルを継続的に回す
たとえば、次の四半期は、今回スコープ外だった領域（例：クラウド上で動く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 を新たな専門領域として論じた論考）
以上