SSVCとは?徹底解説
SSVC完全ガイド｜CVSSを超える次世代脆弱性管理
メタディスクリプション: SSVC（Stakeholder-Specific Vulnerability Categorization）の完全ガイド。CVSSの限界を超え、決定木で対応優先度を自動判定。SBOM、ASM、CSPMとの統合で実現する次世代脆弱性管理を解説。
イントロダクション：CVSSの「呪縛」からの解放
NVDに登録される脆弱性（CVE）は増加の一途をたどり、2024年には過去最多の40,009件（前年比約39%増）に達しました。
多くの組織がCVSSスコアに依存していますが、この運用には限界があります。
- 「CVSS 7.0以上は全対応」というルールで、現場は疲弊
- スコアは高いが自社環境では脅威にならない脆弱性に工数を奪われる
- スコアは低いが、すでに攻撃コードが出回っている脆弱性が見過ごされる
CVSSは「深刻度」は教えてくれますが、「自社は今すぐ何をすべきか」という意思決定の指針を与えてくれません。
この課題を解決するのがSSVC（Stakeholder-Specific Vulnerability Categorization）です。カーネギーメロン大学のソフトウェア工学研究所（SEI）とCISAが共同開発した、「対応方針」を導き出すための意思決定フレームワークです。
SSVCとは何か
SSVCは「ステークホルダー固有の脆弱性分類」を意味し、脆弱性管理のための意思決定フレームワークです。2019年にカーネギーメロン大学SEIとCISAが共同で開発しました。
CVSSとの根本的な違い
| 観点 | CVSS | SSVC |
|---|---|---|
| 目的 | 脆弱性の「深刻度」を評価 | 取るべき「対応方針」を決定 |
| 出力 | 0.0〜10.0のスコア | 4段階の対応方針（モデルにより異なる） |
CVSSが「この脆弱性は9.8点です」で終わるのに対し、SSVCは「Act（即時対応）すべき」または「Track（継続監視）してよい」という行動指針を導き出します。
仕組み：決定木（Decision Tree）
担当者がいくつかの客観的な質問（「すでに悪用されているか？」「システムは公開されているか？」など）に答えるだけで、標準化された対応方針が自動的に導き出されます。
3つのステークホルダー
| ステークホルダー | 役割 | 主な関心事 |
|---|---|---|
| デプロイヤー | パッチ適用側 | 自社システムの脆弱性にいつ対応すべきか |
| サプライヤー | パッチ提供側 | 修正パッチをいつ顧客に提供すべきか |
| コーディネーター | 情報統制側 | 脆弱性情報をいつ公開すべきか |
本記事では主に「デプロイヤー」の視点を中心に、CMU標準モデルとCISAモデルの両方を解説します。
CVSSの限界とSSVCが必要な理由
1. CVSSスコアの構造的問題
- 対応時期を示さない：スコアは出ても、期限や方針は組織任せ
- 自社環境を反映しない：閉域網でも公開サーバと同じ「9.8」が付く
- 脅威の実態を反映しない：悪用コードが存在しない脆弱性にも高スコア
- 高スコアが多すぎる：「7.0以上は対応」ではリソースが足りない
2. 現場の疲弊と属人化
- 大量のチケットをさばくだけの作業に形骸化
- 優先度付けがベテランの経験則に依存
- 経営層への説明根拠が不明確
3. SBOM時代の複雑化
SBOMの導入により、管理すべき脆弱性の対象が桁違いに増加。CVSSスコアだけでは破綻します。
SSVCの仕組み – 2つの主要モデル
SSVCには複数のモデルがあり、組織の役割に応じて使い分けます。ここでは、企業のセキュリティ担当者が主に利用する2つのモデルを解説します。
⚠️ 【重要】 CISAモデルとCMU標準デプロイヤーモデルは、決定ポイントと出力が異なります。混同しないよう注意してください。
CISAモデル（Track / Track* / Attend / Act）
CISAが米国政府機関や重要インフラ向けにカスタマイズしたモデルです。コーディネーターの視点に近い設計となっています。
5つの決定ポイント
- Exploitation（悪用状況）：None / PoC / Active
- Automatable（自動化可能性）：No / Yes
- Technical Impact（技術的影響）：Partial / Total
- Mission Prevalence（ミッション普及度）：Minimal / Support / Essential
- Public Well-being Impact（公共福祉への影響）：Minimal / Material / Irreversible
4つの出力カテゴリ
| カテゴリ | 方針 | 説明 |
|---|---|---|
| Track | 継続監視 | 現時点で対応不要。標準パッチサイクルで対応 |
| Track* | 注視監視 | 状況変化に注意が必要。標準パッチサイクルで対応 |
| Attend | 迅速対応 | 管理者レベルの注意が必要。標準より早く対応 |
| Act | 即時対応 | 経営層レベルの対応が必要。可能な限り早急に対応 |
CMU標準デプロイヤーモデル（Defer / Scheduled / Out-of-Cycle / Immediate）
カーネギーメロン大学SEIが提唱する標準的なデプロイヤー（パッチ適用側）向けモデルです。
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
4つの出力カテゴリ
| カテゴリ | 方針 | 対応目安（組織定義の例） |
|---|---|---|
| Defer | 対応保留 | 現時点で対応不要。状況変化まで保留 |
| Scheduled | 定期対応 | 通常のパッチサイクルで対応 |
| Out-of-Cycle | 迅速対応 | 通常サイクル外で優先的に対応 |
| Immediate | 即時対応 | 全リソースを集中し最優先で対応 |
※ 対応時間の目安（24-72時間、1-2週間など）は公式定義ではなく、各組織が自社のリスク許容度に応じて設定するものです。
決定木の判定ルール（CMU標準デプロイヤーモデル）
CMU公式ドキュメントに基づく主要な判定パターンを示します。
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）
※ 完全な決定テーブル（72パターン）は、CMU SEIの公式ドキュメントを参照してください。
CVSSとSSVCの最適な併用
両者は「置き換え」ではなく「補完」の関係です。
| 観点 | CVSS | SSVC |
|---|---|---|
| 環境考慮 | なし（Environmentalメトリクスは任意） | 必須（System Exposure等） |
| 脅威考慮 | なし（Temporalメトリクスは任意） | 必須（Exploitation） |
| 判断プロセス | 不明瞭（スコアのみ） | 透明（決定木で追跡可能） |
| 対応時期 | 示さない | 明確に示す |
併用戦略
- CVSSで初期フィルタリング：例えば「4.0以上」を評価対象として抽出
- 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・CSPM・DASTとの統合が不可欠
脆弱性管理は「もぐら叩き」から、リスクベースの合理的な意思決定へシフトしています。SSVCはその中核フレームワークです。
Securifyで次世代の脆弱性管理を実現
Securifyは、SSVC・SBOM・ASM・CSPM・DASTを統合した包括的なセキュリティプラットフォームです。
脆弱性管理の課題を抱えている方、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)