SSVCは、CVSSやEPSSだけでは決めきれない脆弱性対応を、Track・Attend・Actの判断へ落とす考え方。情シスやSOCが使える優先度付けの手順を解説する。
SSVCは「何点か」ではなく「どう動くか」を決める
新しいCVEが出るたびに、CVSSの点数だけを見て「Criticalだから最優先」「Mediumだから後回し」と決める運用は、現場ではすぐに限界が来る。スコアが高い脆弱性は多く、パッチ検証、メンテナンス枠、委託先確認、停止できない業務システムが同時に乗ってくるからだ。
SSVC（Stakeholder-Specific Vulnerability Categorization）は、脆弱性を単なる点数ではなく、組織としての対応判断へ変換するための考え方だ。CISAはSSVCを使い、脆弱性対応を Track、Track*、Attend、Act という意思決定に分類している。
この記事では、SSVCを日本企業の情シス、SOC、CSIRT、開発組織で使う前提で整理する。攻撃手順や悪用コードは扱わない。目的は、CVE対応の会議で「結局いつ誰が何をするのか」を決められる状態にすることだ。
- SSVCはCVSSを置き換えるものではなく、対応判断を補強する枠組みとして使う。
- CISAのSSVCモデルは米国政府・重要インフラ向けの文脈を含むため、自社の事業影響に合わせて調整する。
- 実際の対応期限は、ベンダー情報、法務、業務停止リスク、社内変更管理と合わせて決める。
CVSS・EPSS・KEVだけでは最後の判断が残る
CVSS は、脆弱性の技術的な深刻度を共通の尺度で示す。攻撃元区分、必要権限、ユーザー操作の有無、機密性・完全性・可用性への影響を読むには今でも有効だ。
EPSS は、公開されたCVEが今後悪用される可能性を見る参考値になる。KEV は、すでに悪用が確認された脆弱性を把握する強いシグナルだ。詳しい使い分けは KEVとは ─ CVSSだけに頼らない脆弱性対応の優先順位 でも整理している。
それでも、最後に残る判断がある。
| 指標 | 分かること | まだ残る判断 |
|---|---|---|
| CVSS | 技術的な深刻度 | 自社で今すぐ止めるべきか |
| EPSS | 悪用される確率の目安 | 自社の公開資産に刺さるか |
| KEV | 悪用確認済みか | 業務停止を伴う変更を承認するか |
| 資産台帳 | 対象が存在するか | 誰が責任者として動くか |
SSVCは、この「まだ残る判断」を扱うための枠組みだ。スコアを並べるだけで終わらせず、Track、Attend、Actのような行動に接続する。
CISA SSVCの判断軸を実務向けに読む
CISAのSSVCでは、脆弱性の悪用状況、技術的影響、自動化可能性、ミッション上の普及度、公共への影響などを見て、対応判断へ落とす。組織によって言葉は変えてよいが、考え方はそのまま使える。
日本企業の運用に置き換えるなら、まず次の5軸で見ると扱いやすい。
| 判断軸 | 現場で確認すること | 判断への効き方 |
|---|---|---|
| 悪用状況 | KEV掲載、ベンダー警告、EDR/SIEM検知、業界内の被害情報 | 既に攻撃が起きているなら優先度を上げる |
| 技術的影響 | 認証不要、RCE、権限昇格、情報漏えい、可用性停止 | 侵害時の被害範囲を見積もる |
| 自動化しやすさ | インターネット経由で再現しやすいか、条件が単純か | 大規模スキャンの対象になりやすいかを見る |
| 自社での普及度 | 同一製品が何台、何拠点、どのサービスで使われているか | 一部例外か、全社対応かを分ける |
| 事業影響 | 顧客データ、認証基盤、決済、製造、医療、行政手続きへの近さ | 経営・法務・広報を巻き込むかを決める |
この5軸は、CVEの技術説明をそのまま経営会議へ持っていかないための翻訳レイヤーでもある。「CVSS 9.8です」ではなく、「外部公開された認証基盤に近く、悪用確認済みなので今日中に入口を閉じたい」と言える状態を作る。
Track、Attend、Actに落とす
SSVCの価値は、判断結果が行動名になることにある。CISAの表現に寄せるなら、Track、Track*、Attend、Actが基本になる。
| 判断 | 現場での意味 | 典型的な対応 |
|---|---|---|
| Track | 標準の更新サイクルで追跡する | 月次パッチ、台帳更新、次回再評価 |
| Track* | 通常より注意して追跡する | 監視強化、ベンダー続報確認、次回会議で再評価 |
| Attend | 管理者・責任者の判断が必要 | 影響調査、変更枠調整、事業部説明、期限設定 |
| Act | リーダー層を巻き込んで即時対応する | 暫定遮断、緊急パッチ、例外承認、対外説明準備 |
たとえば、CVSSがCriticalでも、対象製品が存在しないならTrackで十分だ。一方、CVSSがHighでも、KEV入りし、外部公開された管理画面に該当し、対象が複数拠点にあるならActへ上げる理由がある。
逆に、Actを乱発すると現場は疲弊する。SSVCは「全部急げ」と言うためではなく、「急ぐものと、標準サイクルでよいものを分ける」ために使う。
使い始めるなら、まず1枚の判断メモにする
SSVCを導入するときに、最初から大きなツールを作る必要はない。CVE対応チケットやインシデント管理ツールに、次の項目を追加するだけでも効果がある。
| 項目 | 書く内容 |
|---|---|
| CVE | CVE番号、ベンダーアドバイザリ、対象バージョン |
| 指標 | CVSS、EPSS、KEV掲載有無 |
| 自社影響 | 対象資産の有無、外部露出、事業影響 |
| SSVC判断 | Track / Track* / Attend / Act |
| 次の行動 | 責任者、期限、暫定対策、完了条件 |
| 再評価条件 | ベンダー更新、KEV追加、PoC公開、被害情報、対象資産発見 |
CVE初動対応チェックリスト と合わせると、対象資産の有無、露出範囲、暫定対策、記録の抜けを減らせる。CVEとCVSSの役割が曖昧な場合は、先に CVEとCVSSの違い を確認しておくとよい。
最初の1か月は、すべてのCVEにSSVCを適用しようとしない。KEV掲載、外部公開資産、認証基盤、顧客データに近い製品だけを対象にすると、運用負荷を増やしすぎずに効果を見やすい。
失敗しやすい運用：判断者が決まっていない
SSVCを表にしても、判断者が決まっていないと機能しない。AttendやActになったとき、誰がメンテナンス枠を取り、誰が業務影響を承認し、誰が残リスクを説明するのかが曖昧なままだと、結局「重要そうだが保留」で止まる。
最低限、次の役割を決めておきたい。
- セキュリティ担当: CVE情報、KEV、EPSS、悪用状況を整理する。
- システム担当: 対象資産、バージョン、外部露出、暫定対策を確認する。
- 事業責任者: 停止可否、顧客影響、変更タイミングを判断する。
- インシデント責任者: Act相当のとき、初動と報告を統制する。
- 記録担当: 判断根拠、例外承認、再評価条件を残す。
Incident Commander のような役割を、重大脆弱性対応にも一時的に置くとよい。インシデントほど大げさに見えなくても、悪用済み脆弱性は時間との勝負になることがある。
例外承認をSSVCの外に置かない
実務では、Act相当でもすぐにパッチを当てられない場合がある。古いOS、停止できない業務、ベンダー未対応、検証環境不足、委託先との契約都合があるからだ。
このとき「例外だから別管理」ではなく、SSVC判断の中に残リスクとして残す。
| 例外時に残すこと | 理由 |
|---|---|
| なぜ今すぐ直せないか | 後から判断を追えるようにする |
| 暫定対策 | WAF、ACL、VPN限定、監視強化、機能停止などを明確にする |
| 期限 | 例外が無期限化しないようにする |
| 承認者 | リスクを誰が受け入れたかを残す |
| 再評価条件 | KEV追加、悪用拡大、対象資産増加で判断を変える |
SSVCは、パッチ適用だけの表ではない。対応しない理由、延期する理由、暫定対策で下げたリスクも含めて、組織の判断を残すための枠組みとして使える。
まとめ：SSVCは脆弱性対応の会議を短くする
SSVCを使うと、CVE対応の会議で「危険そう」「スコアが高い」「でも止められない」という抽象的な会話を減らせる。悪用状況、技術影響、自動化しやすさ、自社での普及度、事業影響を見て、Track、Attend、Actのような行動へ落とせるからだ。
最初から完璧なツール化は不要だ。まずはCVE対応チケットにSSVC判断欄を追加し、KEV掲載や外部公開資産から試す。判断に迷った用語は SSVC、KEV、EPSS、CVSS の用語集に戻るとよい。
復習するなら、このテーマをクイズで確認 してから、実務では CVE初動対応チェックリスト を手元に置く。脆弱性管理の基礎から整理したい場合は、脆弱性管理の基礎 へ戻るのが近道だ。
