SSVCを使いこなそう〜CISA × CERT/CCが提案する効率的な優先度付けフレームワーク〜

皆さんは、脆弱性の優先度付けをどうやって決めていますか？「CVSSのスコアを目安にしている」「とりあえずCriticalやHighだけ適用している」という方も多いと思います。

しかし実際には、脆弱性の重大度は組織の役割や立ち位置によって大きく変わることがあります。
たとえば「ソフトウェアを作る側（ベンダー）」と「それを使う側（運用者）」では、対処すべき脆弱性の優先度が異なるケースが出てくるわけです。

そんなときに役立つのが、SSVC(Stakeholder-Specific Vulnerability Categorization) というフレームワーク。
今回の記事では、アメリカのサイバーセキュリティ・インフラストラクチャ・セキュリティ庁（CISA）とCERTコーディネーションセンター（CERT/CC）が共同開発し、2020年4月頃から実運用しているというSSVCのトレーニング動画をもとに、このフレームワークの概要や使い方をご紹介します。

さらに、FutureVulsが提供するSSVCを活用した自動優先度付け機能についても最後に詳しくご紹介しますので、ぜひ最後までお読みください。

eyecatch

トレーニング動画の概要

今回取り上げるのは、こちらの動画です。

YouTubeタイトル: Stakeholder Specific Vulnerability Categorization Analysis Training
所要時間: 約1時間13分
登壇者:
- Stephanie Connell (CISA) … CISAの脆弱性アナリスト。SSVCスコアリングを実務で担当。
- Jonathan Spring (CERT/CC) … 脅威ディレクターレート所属。SSVCの創設メンバー。

主な内容

0:10 〜ステファニーによるイントロダクション
0:44 〜トレーニングのゴール・アジェンダ
1:05 〜 SSVCの基本的なしくみ解説
25分あたりから〜 3つの脆弱性例を題材にステークホルダー別の意思決定を学習
1時間以上のボリュームがあるものの、CISA × CERT/CCが現場で得た知見を元に話しているため、実用性の高い内容になっています。

SSVCとは？〜CVSSとの違い〜

脆弱性管理といえば、まず思い浮かぶのがCVSS（Common Vulnerability Scoring System） ですよね。CVSSは脆弱性の客観的な重大度を数値化するための有名な指標ですが、「自社にとって本当に緊急性が高いか？」という観点まで十分にカバーできないこともしばしばあります。

一方、SSVC (Stakeholder-Specific Vulnerability Categorization) は、「ステークホルダーの立場や役割によって脆弱性の優先度が変わる」という前提で作られています。
CVSSが「脆弱性そのものの客観評価」に注力しているのに対し、SSVCは「誰がその脆弱性にどう対処すべきか」を意思決定ツリーで明確化するイメージです。

CISAでは2020年4月からSSVCを導入しており、効果を実感しているとのこと（1:13 で言及）。
CERT/CCが開発に協力しており、米国政府機関が推奨するフレームワークの1つとなっているのが大きな特徴です。

SSVCを使う前に押さえたい基礎知識

2:10 前後で語られていますが、SSVCを有効に使うにはある程度のセキュリティ知識が必要です。

脆弱性管理の基本
- CVE番号やパッチ管理、設定管理など
- 参考: NIST SP 800-40 (パッチ管理ガイド)
情報セキュリティ全般の知識
- ファイアウォール、アクセス制御、デジタルフォレンジックス
- SOC/CSIRTなどインシデント対応の大まかな流れ
ITオペレーションの一般スキル
- OS、DB、ネットワークの基礎
- 脆弱性スキャンやログ分析の知識

また、Coordinated Vulnerability Disclosure Guide から引用される定義（2:39 付近）は「脆弱性 = 何らかのセキュリティポリシー違反を許してしまう状態」と整理しています。
設定ミス（ミスコンフィギュレーション）の扱いも非常に重要で、SSVCでもそうしたケースを含めて評価が可能です（4:00 参照）。

ステークホルダー3ロール (Supplier/Deployer/Coordinator)

SSVCでは、特に3つの役割を想定しています。

Supplier: ソフトウェアベンダー、開発者
- 製品のパッチ開発やリリース計画を検討する。
Deployer: 利用者、運用管理者
- システムにパッチを適用するか、いつ適用するかを判断する。
Coordinator: 調整機関、複数組織間を取りまとめる役割
- 攻撃手法や脆弱性情報を広く共有し、マルチベンダーの調整を行う。

同じ脆弱性が見つかったとしても、SupplierとDeployerでは対処すべき緊急度・工数がまったく違う可能性があるのは想像に難くないですよね。
SSVCは、こうした“ステークホルダー特有の事情”を決定ツリーに落とし込んで、バラバラになりがちな脆弱性対応を整理する手法として注目されています。

SSVCの意思決定ツリーと意思決定ポイント

SSVCは、いくつかの 意思決定ポイント (Decision Points) を用いて最終的なアクションを導き出します。主な項目は以下のとおり。

State of Exploitation (悪用状況)
- None / Public PoC / Active
- すでに攻撃が確認されているか、PoCが公開されているか etc.
Automatable (攻撃の自動化可能性)
- Yes / No
- エクスプロイトにユーザー操作や高度な手順が不要かどうか。
Technical Impact (技術的な影響度)
- Partial / Total
- 情報漏洩やDoSでとどまるか、リモートコード実行による完全制御か。
Mission/Business Prevalence (自組織における重要度)
- Minimal / Support / Essential など
- そのソフトウェアが事業継続に直結しているかどうか。
Public Well-being (公共への影響)
- Minimal / Material / Irreversible
- 例: 人命に関わる産業制御システムや公共インフラなど。

Coordinator用ツリーの最終区分

Track / Track* / Attend / Act
たとえば「Track」は「とりあえず注視・監視を続ける」、逆に「Act」は「すぐに行動を起こし、情報共有や公表を優先する」という感じで、対応の度合いを4段階に分けています（10:01 前後）。

Supplier/Deployer用ツリーの例

Scheduled / Out-of-cycle / Immediate / Defer
- 通常のパッチリリース周期内で対応するのか、臨時で緊急対応を組むのか、という選択肢を持たせる。
- 13:08 前後で詳しい解説がされています。
FutureVulsブログ「SSVC Supplier Treeの概要と自動化 | 製造業における脆弱性管理の課題と対応方法」の下記セクションにも詳細を記載しています。

SSVCのデモサイト

Dryad - SSVC Calc App|で赤で囲ったプルダウンを選択して「Show Full Tree」ボタンを押すと木の全体構造を見れます。

3つの具体例による分析 (vSphere / Honeywell / Defender)

1. VMware vSphereのリモートコード実行 (RCE)

脆弱性概要:
- 25:01 前後
- CVE-2022-2972
  VMware vCenter ServerのvSphere Client (HTML5)には、vCenter Serverプラグインにおけるリモートコード実行（RCE）脆弱性が存在します。この脆弱性により、ネットワーク経由でポート443にアクセスできる攻撃者が、基盤となるOSで無制限の権限でコマンドを実行できる可能性があります。
- ネットワークアクセスのみで認証バイパス、root権限を奪取されうる。
- 公開PoCあり（Metasploit等）。ただし“Active Exploit”は確認されていない状態（解析時点）。
Coordinator視点:
- 「PoCあり → 差し迫ったリスクあり」として、最低でもAttendで注意喚起を行うか、場合によってはAct判定になる可能性も。
Supplier (VMware)
- 「PoCが出ているならアウトオブサイクルでパッチを出すべきか？」を判断する。
- 動画では「3月10日段階でActive ExploitはないがPoCはあるので早めに対応が望ましい」としています。
Deployer (利用者)
- 自社環境でvSphereがどれだけ重要なのか（Mission Prevalence）を考慮。
- 自動化攻撃が容易 (Automatable=Yes) なら、被害が広範に及ぶ危険がある。
- ただし実際に攻撃が始まっていないなら、定期メンテナンス内の適用で間に合うかどうか…といった検討をする。
- インターネットに公開さているシステムの場合(Exposure=Open)はインターネットごしに攻撃される可能性がある。

2. Honeywell IPカメラのDoS脆弱性

脆弱性概要:
- 28:40 前後
- 特殊パケットでカメラがクラッシュ → DoS状態。
- PoC公開なし、現状Active Exploit報告もなし。
Coordinator視点:
- RCEではなくDoS、かつPoCもない → 「Track」レベルにとどめられる可能性が高い。
Supplier (Honeywell)
- 大きな影響が見込まれないなら、Scheduled (通常のパッチリリースタイミング) で十分。
- 本Blogの、SSVC Supplier Treeの概要と自動化 | 製造業における脆弱性管理の課題と対応方法で紹介した、デモ: IP CameraのDoSの脆弱性 (Supplier目線)で詳細を記載しています。
Deployer (利用者)
- カメラが止まっても業務に致命的ダメージがないなら、やはり定期メンテでOKと判断するケースが多い。

3. Microsoft DefenderのRCE脆弱性

脆弱性概要:
- 33:02 前後
- 特定のファイルをスキャン時にメモリ破損 → 攻撃者にリモートコード実行を許す。
- Microsoftは既に「Active Exploit」を把握。
Coordinator視点:
- Active Exploit → 緊急度が高い。「Act」の判断で早急に情報周知を行う場合も考えられる。
Supplier (Microsoft)
- パッチをOut-of-cycle で出す可能性大。既に攻撃が発生している以上、待ったなし。
- FutureVuls Blogの、SSVC Supplier Treeの概要と自動化 | 製造業における脆弱性管理の課題と対応方法デモ: Microsoft DefenderのRCE (Supplier目線) でも詳細を記載しています。
Deployer (利用者)
- DefenderはWindowsに標準搭載 → 影響範囲が大きい。
- ただし自動更新が効いている場合、定義ファイルやエンジンが自動で更新されるため「ユーザー側の担当者が残業してすぐ適用する」という必要はない可能性も（動画でそのように言及）。

SSVCを導入する際のステップ

組織のリスク許容度を設定
- 経営者やリスクオーナーが「どれだけ緊急対応にリソースを割けるか」「どんな被害を避けたいか」を明確にする。
- 6:08 前後の解説より。
決定ポイントをロール別に整備
- Supplier: パッチ作成に必要な工数や、リリース手順。
- Deployer: 自社環境内の台数、ミッション重要度、パッチ適用リスク。
- Coordinator: 他組織への周知方法、優先度と公開範囲。
SSVCツリーを自社カスタマイズ
- 公開されているサンプルツリーをベースに、ロールやリスク評価を微調整。
- 重要インフラ関連企業なら「Public Well-being (公共安全)」の評価を厚めにする、など。
実運用とフィードバック
- 導入後は、検知した脆弱性をSSVCで素早く評価→対処→効果検証→ツリー改良 というサイクルを回す。
- 9:49 付近でGitHubへのIssue投稿を奨励。

FutureVulsのSSVC機能

FutureVulsでは、SSVCのフレームワークを活用した脆弱性優先度付け機能を提供しています。これにより、組織全体で統一した意思決定プロセスを簡単に実現し、脆弱性管理を自動化できます。

FutureVulsのSSVC対応の特徴

自動化された意思決定プロセス
- FutureVulsは、CISA/CERT/CCのSSVCをベースに独自の機能を追加しています。
- 各脆弱性に対して自動的にSSVCの決定ポイントを算出し、推奨される優先度を提示。
- たとえば、「State of Exploitation（悪用状況）」や「Automatable（攻撃の自動化可能性）」など、判断が難しい要素をツールがサポートします。
カスタマイズ可能な意思決定ツリー
- 組織固有のリスク許容度や、特定のステークホルダー（例: サプライチェーン、特定のベンダー）に基づいたカスタムツリーを作成可能。
- これにより、一般的なSSVCツリーではカバーできない細かい状況に対応できます。
リアルタイムな脅威情報との連携
- 最新の脆弱性情報や攻撃手法が更新されると、それを元にSSVCスコアも再計算。
- CVSSやEPSSとの統合に加えて、SSVCによる優先度付けが加わることで、トリアージが効率化されます。
可視化された意思決定プロセス
- SSVCの決定木をグラフ化し、どの脆弱性が「Act（緊急対応）」「Attend（注意喚起）」「Track（観察）」に該当するのかがひと目でわかる。
チケット機能との連携
- SSVCの結果に応じて、チケットの「優先度」「対応期限」等を自動設定可能
- セキュリティ部門は、全社横断で「immediateで未対応のままのチケットはないか」などをすぐに確認し対応状況を追跡できる。

FutureVulsでSSVCを導入するメリット

脆弱性対応の意思決定の一貫性:
ロールごとの優先度付けが標準化され、組織全体での認識が統一されます。
時間とリソースの節約:
各担当者が行っていた主観的な判断を自動化・簡略化し、本来注力すべきタスクに集中できます。
信頼性:
CISAやCERT/CCが実運用しているフレームワークを基にしているため、安心して採用できます。
柔軟性:
自社に最適化されたSSVCツリーをFutureVuls上で簡単に設定可能。

FutureVulsは、SSVCの優れた理論を現場で使える形に落とし込んだツールです。「CVSSだけでは足りない」と感じる方は、ぜひ一度お問い合わせください。
詳しくはこちら: FutureVuls公式サイト

まとめ

脆弱性管理を行う上で、「ステークホルダー固有の優先度付け」 という発想は非常に重要です。従来のスコアリング指標に加えて、誰が、いつ、どれだけのリソースをかけて対処すべきかを明確化することで、意思決定のブレや対処遅れを減らすことが期待できます。

今回ご紹介したSSVCは、CISAやCERT/CCが実運用してきたフレームワークだけあって、現場視点の具体例が豊富に盛り込まれています。
「CVSSだけではどうも対策優先度がズレる…」「CVSSでは対応可能な数まで絞り込めない…」と感じているセキュリティ担当者の方は、ぜひYouTube本編をチェックしてみてください。自社に取り入れるヒントがきっと見つかるはずです。

FutureVulsでは
脆弱性情報の自動集約・SSVCによる優先度付けに役立つSaaSを開発・提供しています。SSVCを使った意思決定プロセスを用いて、継続的かつ効率的に脆弱性管理を進めたい方は公式サイトもぜひご覧ください！