CTEM（Continuous Threat Exposure Management／継続的脅威エクスポージャー管理）は、自社の攻撃対象領域にどんな露出があるかを継続的に洗い出し、事業へのリスクが高いものから優先して手を打つセキュリティのプログラムです。Gartnerが2022年に提唱した枠組みで、Scoping・Discovery・Prioritization・Validation・Mobilizationという5つの段階を循環させます。この記事では、CTEMの定義、四半期ごとのスキャン中心だった従来の脆弱性管理との違い、5段階それぞれの実務、優先順位を機械的に決めるためのKEV・EPSSの使い方、ASMやBASといった支援ツールとの関係、そして「自社で回すか外部に委ねるか」の判断基準までを、導入を検討する技術選定者の視点で整理します。
まとめ：CTEMは「点の診断」を「継続する運用」に組み替える枠組み
CTEMは新しい製品カテゴリではなく、既存の脆弱性管理・脆弱性診断・ペネトレーションテスト・資産管理を、事業リスク基準でつなぎ直す運用の設計図です。狙いは、年1〜数回のスキャンで積み上がる膨大な脆弱性リストを消化しきれないまま放置する状態から抜け出し、「攻撃者が実際に悪用できる露出」から先に潰す運用へ移すことにあります。
この「悪用できるものから先に」という考え方は、もはや民間のベストプラクティスに留まりません。米国CISAは2026年6月10日付のBOD 26-04（Prioritizing Security Updates Based on Risk）で、長く運用されてきたBOD 22-01とBOD 19-02を失効させ、公開状況・悪用実績・自動化可能性・技術的影響の4変数で是正期限を決める方式へ切り替えました。CTEMのPrioritizationが説明していた発想が、連邦政府の拘束力ある指令として具体化した格好です。
着手のコツは全社一斉ではなく、外部公開資産など被害に直結する範囲を1つ選んでScoping〜Mobilizationを1周させ、回せる幅を広げていくことです。5段階のうち継続的なDiscoveryとValidation、そして是正を実行に移すMobilizationでは、高い運用負荷がかかります。攻撃者視点での検証を担う脆弱性診断・セキュリティ診断を1周目のValidationに充て、継続監視と運用自動化の土台は保守運用・内製化支援で整える、という分担が取りやすいところです。以下、定義から判断基準まで順に解説します。
CTEM（継続的脅威エクスポージャー管理）の定義とGartnerが提唱した背景
まず言葉の輪郭を押さえます。CTEMが対象にする「エクスポージャー（露出）」は、いわゆる脆弱性（CVE）だけを指しません。設定ミス、公開されたままの認証情報、過剰な権限、シャドーIT化した資産まで含めた「攻撃者に付け入る隙を与える状態」の総称です。
CTEMの定義と「エクスポージャー」に含む4種類の露出とその範囲
CTEMは、攻撃対象領域全体の露出を継続的に把握・評価し、事業影響の大きいものから是正する反復プロセスです。従来の脆弱性管理が「既知の脆弱性（パッチ適用対象）」を主に扱うのに対し、CTEMが見る露出はより広く、実務上は次の4種類を含めて扱います。
- 既知の脆弱性：CVEが割り当てられたソフトウェアの欠陥
- 設定ミス：クラウドストレージの公開設定、緩い権限、無効化された多要素認証
- 露出した資格情報：コードや公開リポジトリに残ったAPIキー・シークレット
- 把握外の資産：棚卸しされていない外部公開サーバーやSaaS
この4種を「脆弱性スキャナの結果」だけで捉えるのは困難です。CTEMが資産の発見（Discovery）を第2段階に据えるのは、守るべき対象そのものが動的に増減する前提に立っているからです。国内でも経済産業省が2023年5月にASM（Attack Surface Management）導入ガイダンスを公表し、外部から見える資産の継続的な把握を独立した実務として位置づけています。
Gartnerが2022年にCTEMを提唱した理由と2026年に向けた予測
CTEMという用語はGartnerが2022年に打ち出しました。背景にあるのは、クラウド・SaaS・リモートワークの広がりで攻撃対象領域が膨張し、四半期に一度の脆弱性スキャンでは変化に追随できなくなったという現実です。スキャン結果は数千〜数万件の脆弱性を返す一方、そのすべてに手を回す人員はどの組織にもありません。
母数の実測値も、この窮屈さを裏づける根拠です。FIRSTのUsing EPSSによれば、直近12か月に公表されたCVEは約6.1万件で、そのうちCVSSがCriticalと判定されたものが1割強を占めます。一方、ある30日間で実際に悪用の観測があるのは公表済み脆弱性の1.5〜3%程度に留まります。「Criticalを全部潰す」という運用が破綻するのは人員不足だけが理由ではなく、潰す対象の大半が実際には攻撃に使われないためです。
Gartnerは提唱時点で、CTEMに基づいて投資の優先順位を決める組織は2026年までに侵害を受ける可能性が3分の1程度に下がる、との見通しを示しました。これは2022年時点の予測であり、2026年9月時点まで独立した実測で裏づけられた数値ではない点は割り引いて読む必要があります。ただし「量をこなす」から「悪用され得るものを選ぶ」へ軸足を移す方向性は、後述する検証（Validation）の考え方とも一貫しています。
CTEMと従来の脆弱性管理・脆弱性診断との違いを4つの観点で整理
CTEMを「脆弱性管理の新しい呼び名」と捉えると導入を誤ります。両者は対象範囲と時間軸が異なり、脆弱性診断やペネトレーションテストはCTEMの内部に組み込まれる部品になります。
スキャン中心の脆弱性管理が取りこぼす、悪用可能性という判断の軸
従来の脆弱性管理は、スキャナが検出した脆弱性をCVSSスコア順に並べ、上から潰していく運用が中心でした。ここには2つの穴があります。1つは、CVSSが高くても攻撃経路が塞がれていて実際には悪用できないものに人手を割いてしまうこと。もう1つは、CVEの付かない設定ミスや資格情報の露出が評価対象から外れることです。スコアそのものの読み方はCVSSとは？深刻度スコアの見方と計算方法で整理していますが、CVSSは「悪用されたらどれだけ悪いか」を表す指標で、「悪用されるか」を表す指標ではない点が出発点になります。
CTEMは「悪用可能性（exploitability）」と「事業への影響」の掛け合わせで優先順位を組み直します。スコアの高さではなく、攻撃者が現実に到達できる経路上にあるかどうかを判断基準に置く。これが最大の差です。
脆弱性診断・ペネトレーションテストとCTEMの役割分担と使い分け
脆弱性診断やペネトレーションテストは「ある時点」の露出を深く調べる手段で、CTEMは「継続」を担う枠組みです。両者は競合せず、CTEMのValidation段階に診断・テストが組み込まれる関係にあります。外注の脆弱性診断をどう使うか、費用や進め方の判断基準は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準で整理しているため、CTEMのValidationに外部診断を組み込む前提として併読すると位置づけが掴めます。網羅型の診断と目的型のテストのどちらを1周目に充てるかで迷う場合は、ペネトレーションテストと脆弱性診断の違いで目的と費用の差を先に押さえてください。
| 観点 | 脆弱性管理 | 脆弱性診断／ペンテスト | CTEM |
|---|---|---|---|
| 対象 | 既知のCVE | 指定システムの露出 | 攻撃対象領域全体 |
| 時間軸 | 定期スキャン | 単発・スポット | 継続する循環 |
| 優先基準 | CVSSスコア | 検出重大度 | 悪用可能性×事業影響 |
| 成果物 | 脆弱性リスト | 診断報告書 | 是正の実行と改善 |
表の右列に進むほど、単発の検出から継続的な是正の実行へ重心が移ります。CTEMは診断結果を「読んで終わり」にせず、後述のMobilizationで実際の修正まで運ぶ点に価値があります。
CTEMを構成する5つの段階（Scoping〜Mobilization）の実務
CTEMは5段階を一度きりで終える工程表ではなく、回し続けるループです。各段階で何を決め、何を成果物にするかを具体化します。
Scoping：事業重要度で守るべき保護範囲を最初に絞り込む工程
最初のScopingの出発点は、技術ではなく事業についての会話です。全資産を一度に守ろうとすると破綻するため、外部公開アプリケーション、顧客データを持つ基盤、決済に関わるシステムなど、侵害されたときの事業インパクトが大きい範囲を先に定義します。ここをセキュリティ担当だけで決めず、事業部門を巻き込んで合意する点がCTEMの起点で、範囲を絞る勇気が後段の実行可能性を左右します。
Discovery／Prioritization：資産の棚卸しと悪用可能性による並べ替え
Discoveryでは、定義したスコープ内の資産と、そこに存在する脆弱性・設定ミス・露出資格情報を洗い出します。資産に含まれるソフトウェア部品の内訳は、SBOM（ソフトウェア部品表）をビルドごとに生成しておくと機械的に取り込めます。ここで大量の露出が見つかりますが、件数の多さは目的ではありません。続くPrioritizationで、緊急度・深刻度・代替統制の有無・組織のリスク許容度を組み合わせ、「先に潰すべき少数」へ絞り込みます。
- スコープ内の資産と露出を発見（Discovery）
- 攻撃経路上にあるか、悪用の実現性で選別
- 事業影響と緊急度で最終的な順位を確定
数千件の脆弱性リストを、実際に着手する数十件へ絞る。この絞り込みの精度が、CTEMが回るか形骸化するかの分かれ目になります。
Validation／Mobilization：攻撃シミュレーション検証と是正の実行
Validationは、優先順位を付けた露出が「本当に悪用可能か」をテストで確かめる段階です。ペネトレーションテストや、後述のBAS（侵害・攻撃シミュレーション）を使い、攻撃者視点で経路を再現します。ここで悪用不可と分かった露出は優先度を下げ、限られた人手を実害のある露出に集中させます。
最後のMobilizationは、検証済みの是正を実際の修正作業へ運ぶ段階です。CTEMが最もつまずくのがここで、承認プロセス・変更管理・部門間の調整といった「組織の摩擦」を減らせるかにかかっています。誰が、いつまでに、どの手順で直すかを運用フローに組み込めなければ、CTEMは分析で止まったままです。自社開発のアプリケーションが対象なら、是正をリリースパイプラインの中で受けられるようDevSecOpsの考え方で開発工程側に検査と修正を寄せておくと、Mobilizationの滞留が目に見えて減ります。
CISA BOD 26-04に学ぶ優先順位付けの4変数とKEV・EPSSの使い方
Prioritizationを「事業影響で並べる」と説明するだけでは手が動きません。判断を機械的に落とし込んだ公的な実装例として、CISAの指令と、その材料になるKEV・EPSSという2つの公開データを押さえておくと、自社の基準を設計する足場になります。
BOD 26-04が定めた4つの決定変数と是正期限が動的に変わる仕組み
BOD 26-04は、是正の緊急度を次の4変数で決めます。資産が公開されているか（Asset Exposure）、そのCVEがKEVカタログに載っているか（KEV Status）、攻撃の全手順を自動化できるか（Exploit Automation）、悪用後に部分的な制御と完全な制御のどちらを奪われるか（Technical Impact）の4つです。この枠組みはCERT/CCのSSVCを下敷きにしており、後ろ3つの判定値はCISAがVulnrichmentを通じてCVEごとに公開しています。
実務で効くのは、期限が固定ではなく状態に追従する点です。最も厳しい組み合わせでは3日以内の是正に加えて侵害有無の初期調査（forensic triage）まで求められる一方、公開されていない資産の低リスクな脆弱性は次回の定期アップグレードまで送れます。インターネットから切り離せばAsset Exposureの値が変わって期限は緩み、逆にKEVへ追加されれば即座に縮む仕組みです。CTEMのループが「一度決めた優先順位を更新し続ける」ものである根拠として読める設計で、当てはめ方の手順は同指令の実装ガイダンスにまとまっています。
KEVとEPSSをAPIで突き合わせて着手対象を絞るスクリプト例
民間企業がBOD 26-04そのものに従う義務はありませんが、材料になるデータは誰でも取得できます。CISAのKEVカタログはJSONフィードで配布され、2026年9月10日版の時点での収録件数は1,705件です。悪用確率の推定値であるEPSSはFIRSTのデータ配布ページからCSVとAPIの両方で取得できます。自社の検出結果と突き合わせる最小の実装は次のとおりです。
import json, urllib.request
KEV = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
EPSS = "https://api.first.org/data/v1/epss?cve="
targets = ["CVE-2021-44228", "CVE-2020-29583", "CVE-2024-3400"]
# KEVカタログを取得してCVE IDの集合にする
with urllib.request.urlopen(KEV) as r:
kev = json.load(r)
kev_ids = set(v["cveID"] for v in kev["vulnerabilities"])
print("KEV版:", kev["catalogVersion"], "収録:", kev["count"])
# EPSS（30日以内に悪用される確率）をまとめて引く
with urllib.request.urlopen(EPSS + ",".join(targets)) as r:
rows = json.load(r)["data"]
score = dict((d["cve"], float(d["epss"])) for d in rows)
# KEV掲載を最優先、次にEPSSの高い順に並べて着手順を出す
order = sorted(targets, key=lambda c: (c in kev_ids, score.get(c, 0.0)), reverse=True)
for cve in order:
print(cve, "KEV" if cve in kev_ids else "非KEV", score.get(cve, 0.0))閾値の置き方は、注意して判断したい点です。FIRSTは、CVSS Criticalを着手基準にしている組織が同じ作業量で移行するなら、EPSSの目安はおよそ90パーセンタイル（スコア0.04前後）だと説明しています。EPSSは平均3%弱・中央値1%未満という長い裾を持つ分布のため、「0.5以上を対象にする」といった直感的な線引きは、公表済み脆弱性の98%超を切り捨てる設定になります。KEV掲載を絶対条件、EPSSを連続値の重み、資産の公開有無を掛け算の係数として扱うのが、CTEMのPrioritizationに落とし込みやすい形です。
CTEMを支えるツール群（ASM・BAS）と自社環境への当てはめ
CTEMは単一製品では実現しません。既存資産を役割ごとに組み合わせて5段階を回します。どのツールがどの段階を担うかを把握すると、追加投資の要否を判断しやすくなります。
ASM／EASM・BAS・脆弱性管理ツールの段階別の位置づけ
主要なカテゴリは、CTEMの段階に素直に対応づけられます。無理に全カテゴリを新規導入せず、既に持っている資産を段階に割り当てるところから始めるのが定石です。
| ツール分類 | 主に担う段階 | 役割 |
|---|---|---|
| ASM／EASM | Discovery | 外部公開資産の発見 |
| 脆弱性管理 | Discovery／Prioritization | 露出の検出と順位付け |
| BAS | Validation | 攻撃経路の検証 |
| SIEM／ITSM | Mobilization | 是正の起票と追跡 |
ASM/EASMは棚卸し外の外部資産を見つける「発見」の役割、BASは悪用可能性を確かめる「検証」の役割です。既存の脆弱性管理ツールとチケット管理を土台に、発見と検証を補う順で足すと投資を抑えられます。各カテゴリが自動化できる範囲と人の判断が残る限界は脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界で切り分けました。Mobilization側の起票と追跡は、検知ログの相関分析を担うSIEMと既存のITSMのどちらに寄せるかを、運用チームの日常の作業場所に合わせて決めると定着しやすくなります。
ゼロトラスト・SASEとの関係：露出の低減と検証を両輪で回す
CTEMは露出を「見つけて検証する」枠組みですが、そもそもの露出を「減らす」施策とセットで機能します。ネットワークの信頼を前提にしないゼロトラストや、その接続を統合するSASEは、攻撃対象領域そのものを縮める側の取り組みです。CTEMのDiscoveryで露出が減っていれば、Prioritizationの負荷も下がります。前提となる考え方はゼロトラストとは？境界型防御との違い・NIST7原則と導入判断、接続基盤の統合面はSASEとは？構成要素とゼロトラスト・SSEとの違いで解説しており、原典はNIST SP 800-207が参照先になります。露出低減（ゼロトラスト／SASE）と露出検証（CTEM）は対立せず、両輪で組み合わせる関係です。
CTEMを内製で回すか、運用を外部委託するかを分ける判断の基準
ここは製品ベンダーの解説が手薄になりがちな論点です。CTEMは仕組みより「回し続ける運用」が本体で、着手可否は自社の運用体力で決まります。玉虫色を避け、条件を切って結論を示します。
CTEMを内製で回せる企業の条件と、着手を見送るべき場面の線引き
内製でCTEMを回せるのは、次を満たす組織です。専任のセキュリティ担当が置ける、資産インベントリが最低限維持できている、そして是正を実行に移す変更管理のフローが既にある。この3つ、とくに最後のMobilizationを担う実行体制が欠けていると、Discoveryで露出を見つけても直せず、ダッシュボードだけが育ちます。
逆に、着手を見送る、あるいは範囲を大幅に絞るべき場面もはっきりしています。担当が兼任1名で日々のアラート対応に追われている段階でフルスコープのCTEMを掲げるのは過剰投資です。この状態でまず着手すべきは、CTEMという看板よりも資産の棚卸しと基本的なパッチ運用を回せる体制づくりに尽きます。是正の実行と継続監視を担う運用基盤は、保守運用・内製化支援のように監視・運用自動化を支援する外部の手を組み合わせて立ち上げる選択が現実的です。
スモールスタートの現実解：単一スコープで5段階を1周させる運用
CTEMを全社導入プロジェクトとして構えると、Scopingの合意形成だけで数か月を溶かします。現実的な入り方は逆で、被害に直結する範囲を1つだけ選び、Scoping〜Mobilizationを1周させて「回る手応え」を先に作ることです。
たとえば外部公開しているWebアプリケーション群だけをスコープにし、ASMで資産を洗い、KEV掲載とEPSSで数件に絞り、BASか外部の脆弱性診断で検証し、是正を1サイクル回す。ここで得た運用フローを次のスコープへ横展開する。最初から網羅を狙わない、この一点が形骸化を避ける最大のコツです。
CTEM導入の検討でよくある質問：違い・周期・体制への疑問に回答
CTEMの導入検討でよく挙がる疑問に、実務の観点から簡潔に答えます。
CTEMと脆弱性管理は何が違うのですか？
対象範囲と優先基準が異なります。脆弱性管理は既知のCVEをCVSSスコア順に扱うのが中心である一方、CTEMは設定ミスや露出した資格情報まで含む攻撃対象領域全体を対象にし、悪用可能性と事業影響で優先順位を組み直す点が違いです。脆弱性管理はCTEMのDiscovery／Prioritizationを構成する部品と捉えると整理できます。
CTEMを導入するには専用ツールの購入が必要ですか？
必須ではありません。CTEMは製品カテゴリではなく運用の枠組みで、既存の脆弱性管理ツールやチケット管理を段階に割り当てるところから始められます。優先順位付けの材料になるKEVカタログとEPSSはいずれも無償で公開されており、手元の検出結果と突き合わせる小さなスクリプトから着手できます。発見（ASM/EASM）と検証（BAS）を担う手段が不足していれば、その段階だけを補う順で追加するのが投資を抑える定石です。
CTEMの5段階はどれくらいの周期で回すのですか？
固定の周期は定義されていません。「継続的」の実態は、Discoveryを常時または高頻度で行い、資産や露出の変化を検知したら随時Prioritization以降を回す運用です。BOD 26-04が是正期限をKEVへの追加時点や資産の公開状態の変化に連動させているのも同じ発想で、カレンダーではなく状態の変化が起点になります。四半期スキャンのように周期を長く固定するのではなく、変化に追随して回す点が従来手法との違いです。
中小規模の組織でもCTEMは有効ですか？
有効ですが、フルスコープでの導入は避けるべきです。専任体制が薄い組織では、外部公開資産など被害に直結する単一スコープに絞ってScoping〜Mobilizationを1周させ、回せる範囲を段階的に広げる進め方が現実的です。是正の実行体制がなければ、まず継続監視と運用の土台づくりを先行させます。
CTEMとペネトレーションテストは併用すべきですか？
併用します。ペネトレーションテストはCTEMのValidation段階に組み込まれ、優先順位を付けた露出が実際に悪用可能かを検証する役割を担います。単発の診断・テストを「継続する枠組み」の中に位置づけるのがCTEMの考え方です。網羅型の脆弱性診断との使い分けと外注時の判断基準は、関連記事として挙げた2本を参照してください。
関連記事
- 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：CTEMのValidation段階に組み込む外部診断の選び方・費用感を整理しています。
- ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理：1周目のValidationにどちらを充てるかの判断材料です。
- 脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界：各段階を担うツールの自動化範囲と限界を切り分けています。
- CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説：Prioritizationで使うスコアの前提と限界を解説しています。
- ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：CTEMと両輪になる「露出を減らす側」の設計思想を解説しています。
- SASEとは？構成要素とゼロトラスト・SSEとの違い、導入判断を解説：攻撃対象領域を縮める接続基盤の統合アプローチを扱っています。
