SSVCとは？脆弱性への対応を決めるための判断モデル

SSVCガイド｜CVSSと組み合わせて使う脆弱性対応の判断モデル

イントロダクション：CVSSスコアだけでは対応の順番を決めきれない

公開される脆弱性（CVE）の数は多く、すべてに同じ速さで対応するのは現実的ではありません。

多くの組織がCVSSスコアを基準に対応の要否を決めていますが、この運用には限界があります。

• 「CVSS 7.0以上は全対応」というルールで、現場は疲弊
• スコアは高いが自社環境では脅威にならない脆弱性に工数を奪われる
• スコアは低いが、すでに攻撃コードが出回っている脆弱性が見過ごされる

CVSSは脆弱性の技術的な「深刻度」を示しますが、「自社は今すぐ何をすべきか」という意思決定の指針までは示しません。

この課題に対する枠組みの一つがSSVC（Stakeholder-Specific Vulnerability Categorization）です。カーネギーメロン大学ソフトウェア工学研究所（SEI）のCERT/CCが公開している、脆弱性への「対応方針」を導き出すための意思決定フレームワークです。

SSVCとは何か

SSVCは「ステークホルダー固有の脆弱性分類」を意味し、脆弱性管理のための意思決定フレームワークです。数値の大きさだけで順番を決めず、悪用状況や業務への影響などを分岐条件として扱い、利用者の立場や状況に応じて取るべき対応を判断します。モデルや判断項目の定義はCERT/CCの公式ドキュメントで公開されています。CISAの解説によると、SSVCは2019年にSEIがCISAと協力して作成したもので、CISAは2020年にSEIとともに、米国政府機関や重要インフラなどに関係する脆弱性を評価するための独自の決定木を作成しました（後述）。

CVSSとの根本的な違い

CVSSが「この脆弱性のスコアは9.8です」という深刻度の評価を示すのに対し、SSVCは「Act（即時対応）」や「Track（継続監視）」（CISAモデルの場合）、「Immediate」や「Defer」（CMU標準デプロイヤーモデルの場合）といった行動の区分を導き出します。区分の名前と意味はモデルごとに定められているため、特定のモデルの出力を、SSVC全体で共通の区分として扱わないようにします。

仕組み：決定木（Decision Tree）

担当者は「すでに悪用されているか？」「システムは公開されているか？」といった質問に順に答え、決定木の分岐をたどって対応区分を決めます。同じ回答からは同じ区分が導かれるため、判断の根拠を説明しやすくなります。

ただし、各質問に答えるには、悪用に関する情報や資産の公開範囲などの裏付けが必要です。情報が不足している項目を便宜的に「影響なし」と埋めると、優先度を誤ります。未確認の項目は理由と調査担当を残しておきます。

3つのステークホルダー

SSVCには、判断する立場ごとに異なるモデルがあります。

たとえば同じCVEでも、製品を修正するサプライヤーと、その製品を運用する企業では判断すべきことが異なります。運用側では、影響する機器が業務に不可欠か、外部から到達できるか、代替手段があるかといった情報が必要になります。

本記事では主に「デプロイヤー」の視点を中心に、CMU標準モデルとCISAモデルの両方を解説します。

CVSSの限界とSSVCが必要な理由

1. CVSSスコアの構造的問題

• 対応時期を示さない：スコアは出ても、期限や方針は組織任せ
• 自社環境を反映しない：基本評価（Base）のスコアでは、閉域網のサーバーでも公開サーバーと同じ「9.8」が付く。Environmental（環境）メトリクスで補正できるが、利用は任意
• 脅威の実態を反映しない：基本評価のスコアは、悪用コードが存在しない脆弱性にも高い値が付く
• 高スコアが多すぎる：「7.0以上は対応」というルールでは、対応しきれないほどの件数になりやすい

2. 現場の疲弊と属人化

• 大量のチケットをさばくだけの作業に形骸化
• 優先度付けがベテランの経験則に依存
• 経営層への説明根拠が不明確

3. SBOM時代の複雑化

SBOMの導入によって依存ライブラリまで把握できるようになると、脆弱性情報との照合で見つかる対象も増えます。CVSSスコアの高い順に並べるだけでは、どれから対応するかを決めきれなくなります。

SSVCの仕組み – 2つの主要モデル

SSVCには複数のモデルがあり、組織の役割に応じて使い分けます。ここでは、企業のセキュリティ担当者が主に参照する2つのモデルを解説します。

⚠️ 【重要】 CISAモデルとCMU標準デプロイヤーモデルは、決定ポイントと出力が異なります。混同しないよう注意してください。導入時には、採用するモデル名・バージョン・各項目の意味を記録しておくと、担当者間の判断のばらつきを減らせます。組織独自の変更を加える場合も、元のモデルとどこが違うかを説明できる状態にしておきます。

CISAモデル（Track / Track* / Attend / Act）

CISAが米国政府機関や重要インフラ向けにカスタマイズしたモデルです。コーディネーターの視点に近い設計となっています。内容はCISAのSSVC解説ページとCISA SSVC Guide（PDF）で公開されています。

5つの決定ポイント

1. Exploitation（悪用状況）：None / PoC / Active
2. Automatable（自動化可能性）：No / Yes
3. Technical Impact（技術的影響）：Partial / Total
4. Mission Prevalence（ミッション普及度）：Minimal / Support / Essential
5. Public Well-being Impact（公共福祉への影響）：Minimal / Material / Irreversible

決定木では、Mission PrevalenceとPublic Well-being Impactを組み合わせた「Mission & Well-being（Low / Medium / High）」として扱います。

4つの出力カテゴリ

CMU標準デプロイヤーモデル（Defer / Scheduled / Out-of-Cycle / Immediate）

カーネギーメロン大学SEIのCERT/CCが公式ドキュメントで公開している、デプロイヤー（パッチ適用側）向けのモデルです。

4つの決定ポイント

1. Exploitation（悪用状況）

• None：悪用・PoCなし
• Public PoC：概念実証コードが公開、または既知の攻撃手法
• Active：実環境での活発な悪用を確認

2. System Exposure（システム公開状況）

• Small：ローカルサービス、高度に制御されたネットワーク
• Controlled：アクセス制限のあるネットワークサービス（VPN経由など）
• Open：インターネットに公開（DNSサーバー、Webサーバーなど）

3. Automatable（自動化可能性）

• No：キルチェーンのステップ1-4を自動化できない
• Yes：キルチェーンのステップ1-4を自動化可能

4. Human Impact（組織への影響） ※Safety ImpactとMission Impactの組み合わせで決まります。公式ドキュメントでは、各値が次のように定義されています。

• Low：Safety Impact: Negligible かつ Mission Impact: Degraded/Crippled
• Medium：Safety: Negligible + Mission: MEF Failure、または Safety: Marginal + Mission: Degraded/Crippled
• High：Safety: Critical + Mission: Degraded/Crippled、または Safety: Marginal + Mission: MEF Failure
• Very High：Safety: Catastrophic、または Mission: Mission Failure

ただし、同じ公式ドキュメントに掲載されている対応表（決定表）では、一部の組み合わせが上の定義と異なる値になっています（例：Safety: Marginal + Mission: Degraded/Crippled は Low、Safety: Critical + Mission: Degraded は Medium）。運用では、採用するバージョンの対応表を基準にします。

4つの出力カテゴリ

※ 対応時間の目安（24-72時間、1-2週間など）は公式定義ではなく、各組織が自社のリスク許容度に応じて設定するものです。

決定木の判定ルール（CMU標準デプロイヤーモデル）

CERT/CCの公式ドキュメントの決定表で、ImmediateとDeferになる組み合わせは次のとおりです。表記は「Exploitation + System Exposure + Automatable + Human Impact」の順です。

Immediateになるケース：

• Active + Open + Yes + High/Very High
• Active + Open + No + Very High

Deferになるケース：

• None + Small + No + Low/Medium
• None + Small + Yes + Low
• None + Controlled + No + Low
• None + Open + No + Low
• Public PoC + Small/Controlled + No + Low

Active Exploitationの場合、Deferにはならない（最低でもScheduled）

※ 完全な決定テーブル（3×3×2×4の72パターン）は、CERT/CCの公式ドキュメントで公開されています。決定表はバージョンによって見直されることがあるため、運用では採用するバージョンの表を基準にします。

CVSSとSSVCの併用

両者は「置き換え」ではなく「補完」の関係です。CVSSは技術的な深刻度、EPSSは今後悪用される可能性を考える材料です。SSVCは、それらの情報や自組織の状況を基に行動を決めるための枠組みで、どれか一つを選んで他を捨てる必要はありません。

併用戦略

1. CVSSで初期フィルタリング：例えば「4.0以上」を評価対象として抽出。ただし、CISAのKEVカタログに掲載されているなど悪用が確認された脆弱性は、スコアにかかわらず評価対象に含めます
2. SSVCで優先度決定（判断の例）：
   • CVSS 9.8でも、悪用なし・社内のみ・影響軽微 → Defer / Track
   • CVSS 6.5でも、活発悪用・ネット公開・自動化可能・重要システム → Immediate / Act

SSVCのメリット

1. 意思決定の透明化

「なぜ対応したか/しなかったか」を決定木の分岐で説明できます。判断の経緯が記録として残るため、監査や経営層への説明にも使えます。

2. 判断の標準化・属人化の解消

判断の分岐が明文化されるため、ベテランの経験則に頼らず、担当者間の判断のばらつきを減らせます。脅威インテリジェンスや資産情報を入力として整備すれば、判断の一部をツールで支援することもできます。ただし、自社環境に依存する項目は人が確認する必要があり、対応区分を決めた後は、社内の担当・期限・承認方法へ結び付けることも欠かせません。

3. 運用負荷の削減

即時対応が必要な脆弱性と、通常のパッチサイクルで扱える脆弱性を分けられるため、本当に危険な脆弱性にリソースを集中しやすくなります。「Track」や「Defer」に分類された脆弱性は、通常の運用の中で計画的に扱えます。

4. 継続的な再評価

悪用状況が「None」から「Active」に変わるなど、判断に使った情報が変われば対応区分も変わります。情報の更新を確認する担当と頻度を決めておけば、変化に合わせて優先度を見直せます。

SSVC導入の課題

SSVCの導入は多くのメリットをもたらしますが、実運用には以下のような課題も存在します。

1. 判断基準の定義に時間がかかる

「System Exposure」や「Human Impact」の定義は組織ごとに異なります。

• どのシステムを「Open」とするか
• 「High Impact」の基準をどこに設定するか

これらを社内で合意形成するには、セキュリティチーム・開発チーム・経営層の調整が必要です。

2. 脅威インテリジェンスの継続収集が必須

「Exploitation」の判断には、最新の脅威情報が不可欠です。

• CISA KEV（Known Exploited Vulnerabilities）
• JPCERT/CCの注意喚起
• 商用脅威インテリジェンスサービス

これらを継続的に収集・更新する体制構築が必要で、リソース不足の組織には負担となります。悪用に関する情報は、確認した日もあわせて記録しておくと、後から再評価する際に役立ちます。

3. 資産情報の正確な把握が前提

「どのシステムがインターネットに公開されているか」「影響範囲はどこまでか」を正確に把握していないと、SSVCは機能しません。判断の前に、少なくとも次の情報をそろえておく必要があります。

• 影響する製品・バージョンと、それを利用している資産
• 悪用に関する情報と、その情報を確認した日
• 対象システムの公開範囲や業務上の役割
• 修正プログラム、緩和策、停止の可否

SBOM・ASM・CMDBなどの資産管理基盤が整備されていることが前提となります。

4. 「Defer」判定への心理的抵抗

「CVSS 9.8の脆弱性を対応しない」という判断は、担当者にとって心理的ハードルが高い場合があります。

経営層や監査部門への説明責任を果たせる体制と、組織全体の理解が必要です。

5. ツール対応の状況

CISAのVulnrichmentプロジェクトにより、CVEデータにSSVCの判断項目（悪用状況など）の値を付与する取り組みが進んでいます。ただし、システムの公開範囲や業務への影響といった自社環境に依存する項目は、各組織で判断する必要があります。一部の商用脆弱性管理ツールもSSVC対応を進めていますが、判断をすべて自動化できるわけではありません。

これらの課題を踏まえ、最初は実際に対応した数件の脆弱性を使い、当時の判断と決定木による判断を比べてみると、運用を調整しやすくなります。重要システムなのに担当が決まっていない、といった資産管理上の不足も見つかります。

まとめ

SSVCの核心的価値は、CVSSスコアだけに振り回されず、「自社にとっての現実的な脅威」に基づき「次に取るべき行動」を導き出せる点です。

• 決定木で「Act / Immediate」「Track / Defer」などの対応区分を決める（区分の名前はモデルにより異なる）
• 即時対応が必要な脆弱性を見極め、本当に危険な脆弱性にリソースを集中
• 判断の前提として、SBOM・ASMなどによる資産・構成情報の把握が欠かせない

脆弱性管理は「もぐら叩き」から、リスクベースの合理的な意思決定へシフトしています。SSVCはそのための代表的なフレームワークの一つです。

Securifyで判断の材料となる資産・構成情報を把握

Securifyは、外部公開資産を管理するASM、ソフトウェアの構成と脆弱性を管理するSBOM、クラウド設定を監視するCSPM、WebサイトやAPIを診断する脆弱性診断などを提供しています。ASMではドメイン・IP・クラウドから公開資産を発見でき、SBOMではリポジトリやコンテナイメージからソフトウェアの成分とバージョンを抽出できます。こうした資産・構成情報は、SSVCの判断で影響範囲や公開状況を調べる際の材料になります。SSVCの決定木に沿った対応区分の判断は、自社で採用したモデルと手順に沿って行ってください。

脆弱性管理の課題を抱えている方、資産や構成情報の把握から見直したい方は、お気軽にご相談ください。対象となる資産や環境に合わせて、製品と料金をご案内します。

→ Securifyの詳細はこちら

参考文献

• Carnegie Mellon University SEI: SSVC Documentation (https://certcc.github.io/SSVC/)
• CISA: Stakeholder-Specific Vulnerability Categorization (https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc)
• CISA SSVC Guide (PDF) (https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide 508c.pdf)
• 経済産業省: ソフトウェア管理に向けたSBOMの導入に関する手引ver2.0（2024年8月29日）
• CISA Vulnrichment Project (https://github.com/cisagov/vulnrichment)