Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
クラウドネイティブ化が進む現代の IT 環境において、企業はこれまでにない速度でセキュリティリスクに晒されています。新しいリソースの追加、設定ミス、権限の膨張、マイクロサービス間の依存関係など、攻撃者が利用可能な「露出（Exposure）」は増え続けています。なお本記事における Exposure（露出）とは、脆弱性・設定ミス・過剰権限・公開資産など、攻撃者が悪用可能な状態の総称を指します。単なる脆弱性（Vulnerability）よりも広い概念だと捉えてください。なお、これらの露出同士がつながって成立する「攻撃経路（Attack Path）」については、後述の優先付け・検証フェーズで扱います。
こうした状況では、従来のように「月に一度スキャンをしてレポートを確認する」といった静的かつ事後的なアプローチでは、もはや防御が追いつきません。攻撃者は常に新しい侵入経路を模索し、クラウド環境そのものが変化し続けるため、“継続的”な露出管理が必要不可欠となりました。
そこで注目されているのが CTEM（Continuous Threat Exposure Management：継続的脅威エクスポージャー管理） です。
ひとことで言えば、CTEM とは 攻撃者の視点で、組織の露出（Exposure）を継続的に「スコープ定義 → 発見 → 優先付け → 検証 → 動員（修復）」するためのフレームワークです。Gartner が2022年に提唱し、現在広く注目されている考え方で、CVE（既知の脆弱性）の数を追う従来の脆弱性管理を、「攻撃者が実際に悪用できる露出をどう減らすか」という発想へと発展させたものです。
その対象は、クラウド・オンプレミス・SaaS を含む組織全体の攻撃対象領域に及び、攻撃者が実際に利用できるリスクを継続的に特定・評価・検証・修復していきます。
なお、CTEM はスコープ定義から検証・動員（修復）までを含む運用フレームワークですが、本記事では CTEM 全体を解説しつつ、特に設計・計画の段階に「攻撃者の視点」を組み込む観点に焦点を当てます。CTEM の基本概念から、その重要性、5 つのコアフェーズ、クラウドネイティブ環境との相性、導入時のポイントまでを体系的に解説しますので、その視点で読み進めてください。
CTEMとは、攻撃者視点で“露出”を管理するフレームワーク
CTEM（シーテム、Continuous Threat Exposure Managementの略称、継続的脅威エクスポージャー管理）とは、組織の攻撃対象領域全体を対象に、脅威の発見・優先順位付け・検証・修復までを絶え間なく行う最新のサイバーセキュリティアプローチです。
従来のセキュリティ戦略は、定期的なチェックや事後対応に依存する傾向があり、環境変化のスピードに追従しきれないという課題がありました。一方 CTEM は、常に稼働し続けることで、リスク状況をリアルタイムに近い形で可視化し、もっとも重要なエクスポージャー（攻撃に利用されうる弱点）を迅速に特定します。
この継続的なモデルにより、組織は、新しい資産の追加や設定ミスが日々発生するクラウド中心のダイナミックな環境においても、攻撃者のスピードや手法の変化に遅れず対応し続けることが可能になります。
CTEM の目的は、単に問題を見つけることではなく、ビジネスインパクトが大きい問題に優先的に集中し、迅速に解決へつなげることです。これは、設計・計画フェーズで「何を守るべきか」「どこから塞ぐべきか」を判断し、対策の優先順位を決めるための考え方として位置づけられます。
CTEMと従来の脆弱性管理は何が違うのか
「CTEM は、結局これまでの脆弱性管理と何が違うのか」――これは多くのエンジニアが最初に抱く疑問です。両者の違いを整理すると、CTEM の価値がはっきりと見えてきます。
端的に言えば、脆弱性管理が「CVE をどれだけ潰したか」に主眼を置くのに対し、CTEM は「攻撃者が本当に到達・悪用できる露出はどれか」を軸に、修復までを継続的に回します。
なお、外部に公開された攻撃対象領域を洗い出す ASM／EASM（Attack Surface Management／External Attack Surface Management）も露出管理の一部ですが、これらは主に「発見」に焦点があります。言い換えれば、ASM／EASM は CTEM の Discover（発見）フェーズを担う代表的な実装手段の一つです。CTEM は、その発見から優先付け・検証・修復までをひとつのサイクルとして束ねる、より上位の枠組みだと捉えると整理しやすくなります。
CTEM が必要な理由、クラウドと攻撃者の“変化”に対応するため
クラウドでは“見えない露出”が急増している
クラウド環境は、常に変化し続ける短命なワークロードで構成されています。
そのため、次のようなリスクが日常的に発生します。
- 一時的に作成した VM が、外部公開されたまま放置される
- Kubernetes RBAC の設定ミスにより、意図せず権限が拡張されてしまう
- セキュリティグループが運用の過程でドリフトし、本来の想定と異なる状態になる
- CI/CD パイプラインの Secrets が誤って外部に露出する
- SaaS の共有設定ミスにより、組織外へ情報が漏洩する
- 監視対象外の Shadow IT が自然発生し、把握できない攻撃面が増える
このような動的リスクに対して、月次スキャンのような定期チェックではリアルタイムの変化を捉えることができず、問題が発生した後に初めて気付く“後追い型のセキュリティ”にならざるを得ません。
ここで挙げた構成ミスや権限膨張を「設計の段階で継続的に検出・是正する」具体策は、関連記事の CSPM（クラウドセキュリティポスチャ管理） と IaC/PaCセキュリティ で詳しく扱います。
攻撃者の戦術が脆弱性主体から“露出主体”に移行している
近年の攻撃者は、もはや CVE だけを起点に攻撃を仕掛けているわけではありません。
外部公開されたクラウドストレージ、不必要に広い IAM 権限、マイクロサービス間の通信経路、コンテナの誤設定、ソフトウェアサプライチェーンの露出――こうした “手の届く場所” にある隙を足がかりに侵入を試みます。
つまり重要なのは、脆弱性の数そのものではなく、攻撃が実際に成立する状況が存在するかどうかです。この「攻撃成立の現実性」を設計段階から評価する姿勢こそ、攻撃者視点の設計・計画の核心です。
広すぎる権限や通信経路を「最小権限」で設計し直す考え方は、ゼロトラスト・責任共有モデル の記事で深掘りします。
環境変化が加速し、セキュリティ対策が追いつかない
環境変化のスピードは年々加速しており、セキュリティがその変化に追いつけなくなっています。毎日のデプロイ、数時間で消えるコンテナ、一時的に付与される開発者アクセス権、マイクロサービスの再配置――。こうした高速かつ断続的な変更は、静的なセキュリティプロセスでは捉えきれません。そこで、CTEM のように「継続的・動的」にリスクを監視し続けるモデルが必要になるのです。
CTEM を構成する5つのフェーズ（構造化されたフレームワーク）
CTEM は、単一のツールや製品ではなく、5 つの重要なフェーズから構成される継続的なフレームワークです。これらのフェーズは、設計・計画における「露出評価の標準プロセス」として位置づけられます。
5つのフェーズは一度きりで終わるものではありません。下図のように、スコープ → 発見 → 優先付け → 検証 → 動員と進み、再びスコープに戻って繰り返す——この終わりのない循環こそがCTEMの本質です。
1. スコープの決定（Scope）
CTEM の第一フェーズでは、対象とする資産・環境・ビジネス領域を明確化します。
具体的には、社内インフラストラクチャ、クラウドサービス、SaaS アプリケーション、開発環境、Kubernetes クラスタ、さらにサプライチェーンにおける依存関係まで含め、組織全体の攻撃対象領域（attack surface）を定義します。
このとき、最初からすべてを対象にするのではなく、重要資産や重要業務から優先的に対象範囲を定めるのが一般的です。Scope の設定を誤ると後続のフェーズすべてが空振りしかねないため、ここは CTEM の成否を左右する起点になります。
こうして資産の境界を明確にすることで、漏れのないエクスポージャー（露出）管理が可能になります。
2. 発見（Discover）
このフェーズでは、定義したスコープ内の資産について、既知の脆弱性だけでなく、設定ミスや公開状態、権限の過剰付与、認証情報の露出といった見落とされがちな露出も含め、攻撃に利用されうる要素を継続的に洗い出します。
具体的には次のような項目が対象となります。
- 既知の脆弱性
- 外部公開されたエンドポイント
- Kubernetes やクラウドサービスにおける設定ミス
- IAM 権限のスプロール（過剰付与）
- 暗号鍵・Secrets・認証情報の露出
- Shadow IT や未管理の SaaS 利用
なお CTEMの対象はクラウドやKubernetesに限らず、SaaSの利用状況まで含みます。Shadow ITのように管理外で発生する攻撃面も、攻撃者にとっては等しく「露出」だからです。クラウド環境のように、マルチアカウントでリソースが分散し、変化が激しい基盤では、クラウド上の全リソースを把握するための「資産インベントリ」の自動化と継続的な更新が不可欠です。この「発見」の精度と継続性が、その後のリスク評価や優先順位付けの精度を左右します。
3.優先付け（Prioritize）
発見した露出は、すべてを評価したうえで優先付けを検討します。このフェーズでは、ビジネスへの影響と攻撃成立の現実性を、実環境のコンテキスト（構成情報・権限情報・ネットワーク到達性など）に基づいて分析し、「どのリスクに優先的に対処すべきか」を判断します。ここで行うのは、構成情報や権限情報をもとにした攻撃経路の「推定」です。
- 資産の重要度（Crown Jewel＝最重要資産 にどれだけ近いか）
- 攻撃者が実際に到達できるか（ネットワーク到達性・公開状態）
- 脆弱性の悪用可能性（Exploitability / 実行時リーチャビリティ）
- 既存の防御・制御手段の有無
- 事業への影響の大きさ（ビジネス・インパクト）
- 最新の脅威インテリジェンスとの整合性
これらを総合的に評価することで、“理論上存在するだけのリスク”と“いますぐ対処すべきリスク”を区別します。例えば、CVSS 9.0 でも「攻撃者がアクセスできない場所」にある脆弱性より、 CVSS 5.0 でも「外部公開 × 認証なし」の方がはるかに危険です。
CTEM の優先付けが従来と一線を画すのは、単一の脆弱性の深刻度だけを見るのではなく、「外部公開された VM」「過剰な IAM 権限」「機密データへの到達経路」といった複数の弱点を組み合わせた攻撃経路（Attack Path）全体で危険度を評価する点です。CTEM はこの現実的な優先順位を明確にします。ここで推定されるのは、あくまで「成立し得ると見込まれる攻撃経路」の候補です。それが実際に攻撃として成立するかどうかは、次の検証フェーズで実証します。
4.検証（Validate）
優先付けが攻撃経路の「推定」だとすれば、検証はその「実証」です。このフェーズでは、優先順位付けされた攻撃経路について、現実に攻撃が成立し得るか を実際に確かめます。推定にとどめず、「複数の弱点を組み合わせた攻撃が本当に成立し得るか」のエビデンスを確保します。優先付けで推定した Attack Path を実際にたどり、その成立性を検証する手法には、次のようなものがあります。
- Attack Path Validation（推定した攻撃経路の成立性検証）（例：インターネット → 設定ミスのVM → 強いIAM権限を持つサービスアカウント → DBへの横移動、という推定ルートが本当に通るかを実証する）
- BAS（Breach and Attack Simulation） による模擬侵害
- ペネトレーションテスト
- 攻撃者エミュレーション
- ランタイム挙動の検証（実行中プロセス・システムコールの観察）
ここで挙げた BAS やペネトレーションテストは、あくまで Validate を実現する「手段の一つ」です。CTEM はこれらの特定手法を前提とするフレームワークではなく、自組織の環境や成熟度に応じて検証手法を選べばよい点に注意してください。
これにより、数多くの露出の中から、修復すべき“本当に危険な”問題を確実に絞り込むことができます。 検証フェーズを通じて、対応リソースをもっとも重大な脅威に集中させることが可能になります。
なお、ここで触れる「ランタイム挙動の検証」を本番環境で常時実行し、本当に危険なアラートだけに絞り込む仕組み（Runtime Insights）について詳しくは、ランタイム検知の解説記事 で取り上げます。本記事では計画段階での検証手段として位置づけるにとどめます。
5. 動員（Mobilize）
最後のフェーズでは、特定された露出に対し、修復（是正措置）します。 このフェーズでは、セキュリティだけでなく以下の複数の部署が関わります。
- セキュリティ
- IT / インフラ
- 開発（Dev）
- プロダクトオーナー
そのため、「そのリスクは誰が所有しているリソース（コード）なのか」というオーナーシップの明確化と、スムーズな修復ワークフローの設計が成功の鍵になります。
可能な範囲では、IaC（Infrastructure as Code）による設定修正や、セキュリティチームからの自動 Pull Request（PR）の起票、ポリシー適用など、自動化された是正措置を活用することで、開発チームの負担を減らしつつ効率化が図れます。一方で、クラウド環境では状況判断が必要なケースも多いため、自動化と人の判断（コンテキストの理解）を組み合わせたハイブリッド運用が現実的です。
動員フェーズが適切に機能することで、CTEM は“可視化して終わり”ではなく、実際に露出を減らし続ける改善サイクルへとつながります。
検知・是正の「運用フェーズ」を本格的に設計する際は、対応SLA（72時間以内対応）の考え方を含む DevSecOpsの運用設計ガイド を参照してください。本記事は計画段階の是正設計に焦点を当てます。
CTEM を導入する際に押さえるべきポイント
CTEMを成功させるためには、単にツールを導入するだけでは不十分です。組織横断の体制と、継続的に改善できる運用の仕組みが必要です。以下のポイントをあらかじめ整理し、日々の運用に落とし込むことで、CTEMは高い効果を発揮します。
1. 目標と成功指標（KPI）の設定
あいまいな状態で CTEM を開始すると、効果測定ができず形骸化しやすくなります。
まずは次のような指標を明確にします：
- 露出削減率
- 設定ミスの再発防止率
- MTTR（平均復旧時間）の短縮
- クリティカル露出の対応完了率
なお、より高度にCTEMを活用する組織では、Attack Path（攻撃経路）削減率やCrown Jewel（最重要資産）への到達経路数といった、攻撃者視点を取り入れた指標を設定するケースもあります。CTEMでは、「何をもって成功とするのか」をあらかじめ定義し、継続的に評価・改善できる状態をつくることが重要です。
2.経営層・関係部署の支援体制
CTEM は SecOps だけが担うものではありません。
開発、IT、SRE、プロダクトオーナーなど、複数の部門が関与するため、
- 経営層による承認やオーナーシップ、後押し
- 役割と責任の明確化（RACI）
- チーム横断のコミュニケーション体制
が不可欠です。
3. ツールとデータ源の統合
CTEM は“複数のデータを統合して初めて成立する”フレームワークです。次のようなデータソースを横断的に活用し、統合的な露出管理を実現します。
- CSPM（クラウド設定ミス）
- CIEM（権限・アイデンティティ管理）
- CWPP（ランタイム挙動と脆弱性）
- DSPM（データ保護・機密データの位置把握）
- 脅威インテリジェンス
- 資産インベントリ（自動更新）
発見・優先付け・検証・修復の各プロセスで、同じデータを参照できることが重要です。たとえば、CSPMが検知した「設定ミス」とCIEMが検知した「過剰権限」が別々のツールに分かれていると、それらが“同じコンテナ上で同時に起きている致命的なコンボリスク”であることに気づけません。複数の弱点を1つのコンテキストとして捉えるためには、データ統合が欠かせません。
前提として、CTEMは特定の製品やツールを前提とするフレームワークではありません。そのうえで、この「データ統合」を一気通貫で実現する有力な選択肢の一つがCNAPP（Cloud-Native Application Protection Platform）です。CNAPPは、CSPM（構成）・CIEM（権限）・DSPM（データ）・CWPP（ワークロード）・ランタイム分析を単一のプラットフォームに束ね、前述の攻撃経路（Attack Path）を横断的に可視化します。CTEMはあくまでフレームワークであり、CNAPPはそれを実践するための実装手段の一つです。分散しがちな露出データを統合し、リスクの優先順位付けにつなげやすい点で、CNAPPはCTEMを実践するうえで有効な選択肢になります。
どの製品を CNAPP として選ぶべきか、CSPM / CIEM / CWPP などをどう統合・比較するかは、CNAPP選定ガイド で詳しく解説します。
4. 自動化の推進（ただし人とのハイブリッドが最適）
自動化の徹底は、運用負荷を最小化するためのもっとも効果的な手段です。
- IaC による自動修正 PR
- 過剰権限の自動縮小
- ポリシー適用の自動化
- アラートノイズ削減
ただし、クラウドでは文脈依存の判断が必要な場合も多く、「自動化 × 人の判断」を組み合わせたハイブリッド運用が現実的です。
5. 長期的な露出指標のトラッキング
クラウドは常に変化しているため、継続的な露出管理が前提です。
追跡すべき指標の例：
- 露出レベルの月次推移
- 修復までのリードタイム
- 設定ドリフト発生頻度
- 本番環境に残存するクリティカル露出数
これらを継続的にトラックすることで、CTEM の改善サイクルを維持できます。
まとめ｜CTEMはクラウド時代の露出管理を攻撃者視点へ転換するフレームワーク
継続的な脅威エクスポージャー管理（CTEM）は、セキュリティ運用を進化させるアプローチです。従来の「定期的な評価」にとどまらず、リスクの変化に応じて優先順位を見直し、必要な修復を継続的に進める考え方です。
クラウドネイティブ技術や分散型アーキテクチャの採用が進むなか、組織の攻撃面は急速に変化しています。CTEMは、こうしたエクスポージャーを継続的に把握し、優先順位を付けて対処するためのフレームワークです。
CTEMを人・プロセス・テクノロジーに組み込むことで、セキュリティチームは限られたリソースを重要なリスクに集中させやすくなります。その結果、エクスポージャーウィンドウの短縮や、より回復力の高いセキュリティ運用につながります。
CTEMは本来、スコープ定義、発見、優先付け、検証、動員（修復）を継続的に回す運用フレームワークです。一方で、その価値は運用段階にとどまりません。設計・計画の段階から攻撃経路を意識し、「何を守るべきか」「どこから塞ぐべきか」を判断する視点を与えてくれます。
つまりCTEMは、運用を継続的に改善するフレームワークであると同時に、そこで得た知見を設計・計画段階へフィードバックする仕組みでもあります。露出を作り込む前に評価して塞ぎ、運用で得た学びをふたたび設計へ戻す。この循環が、攻撃者視点に立ったクラウド時代の露出管理につながります。
次に読むべき記事（設計・計画フェーズ）
CTEMの考え方を具体的な設計にどう落とし込むかについては、以下の記事で詳しく解説しています。
- CNAPP選定ガイド｜CSPM/CIEM/CWPPを統合する基盤の選び方
- CSPMとは｜クラウド構成ミスを継続的に検出・是正する
- IaC/PaCセキュリティ｜コードの段階で安全な構成を設計する
- ゼロトラスト・責任共有モデル｜最小権限で露出を設計から減らす
クラウドセキュリティ全体像を俯瞰的に確認したい方は、クラウドセキュリティ完全ガイド｜「Code to Runtime」で守る もあわせてご覧ください。