「深刻な脆弱性が見つかったので、急いで対策したい」。現場からこう報告されても、事業責任者はすぐに承認できるとは限りません。費用はいくらか、作業をすると何が止まるか、進行中の案件への影響はどれほどか。対応を遅らせた場合の被害と合わせて、個別に判断することになります。
そこで役立つのが、脆弱性の深刻度を共通の点数で表す「CVSS」です。ただ、「8点です」と言われるだけでは、その数字の重さも、自社でどれだけ急ぐ話なのかも分かりません。
脆弱性対応の優先順位は、CVSSで技術的な深刻度を共有し、実際の悪用状況、自社で攻撃が成立する条件、事業への影響を重ねて考えられます。 現場のアラートを事業判断につなげるために、まず点数の読み方から整理します。
CVSSとは？脆弱性の深刻度を現場と共有するための点数
脆弱性は、ソフトウェアや機器の設計・実装などにある、攻撃に悪用され得る弱点です。CVSS（Common Vulnerability Scoring System、共通脆弱性評価システム）は、その技術的な深刻度を0～10の点数で示す仕組みです。脆弱性診断の報告書や、メーカーのセキュリティ情報で使われています。
CVSS8点はどれだけ深刻？7.0～8.9は「高」の区分
CVSS v3.1では、点数を次の区分に対応させています。v4.0でも同じ点数区分です。
| 点数 | 公式の深刻度区分 | 読み取れること |
|---|---|---|
| 0.0 | None（なし） | CVSS上の深刻度が0 |
| 0.1～3.9 | Low（低） | 共通の尺度で低い深刻度 |
| 4.0～6.9 | Medium（中） | 共通の尺度で中程度の深刻度 |
| 7.0～8.9 | High（高） | 共通の尺度で高い深刻度 |
| 9.0～10.0 | Critical（最も深刻な区分） | 共通の尺度で最上位の深刻度 |
8点は、5段階のうち上から2番目の「高」に当たります。 担当者が独自に「重大」と呼んでいるのではなく、共通の評価方法で高い深刻度になっている、と理解できます。
一方、「8点なら1日でサービスが破壊される」「被害確率が80％」という意味ではありません。9.0点から公式に即日対応が義務になるわけでもありません。深刻度の区分と、自社の対応期限は分けて考えるものです。
点数の理由は「攻撃の条件」と「起こり得る被害」に分ける
よく公表されるCVSS基本点には、外部のネットワークから攻撃できるか、事前の権限が必要か、利用者の操作が必要か、といった攻撃条件が反映されます。加えて、情報を読まれる、書き換えられる、システムが使えなくなる、といった影響も評価します。
つまりCVSSは、被害の大きさだけを採点したものでもありません。ただし、攻撃条件の評価を含むことと、現実に攻撃される確率を予測することは異なります。
責任者への説明では、計算式よりも次の二つが役立ちます。
- 何をされるのか：顧客情報の閲覧、注文データの改ざん、サービス停止など。
- どんな条件で成立するのか：外部からログインなしで攻撃できるのか、既に管理権限を持つ人の操作が前提なのか。
「8点＝高」に、この説明が加わると、数字と具体的な被害がつながります。同じ点数台でも、攻撃条件と影響の組み合わせは同じとは限りません。
CVSSの点数を、自社の事業リスクへ読み替える
例えば「顧客情報を読み取られる」という技術的な影響が分かっても、それがテスト用の架空データなのか、取引先から預かった実データなのかで、事業上の重さは変わります。停止の影響も、月に一度使う社内ツールと、受注を受け付ける本番システムでは異なります。
CVSSの基本点は、このような自社固有の事情まで織り込んだ数字ではありません。FIRSTの公式ガイドも、基本点だけでリスクを評価せず、脅威や利用環境の情報で補うことを説明しています。
現場に確認してもらうのは、対象・攻撃条件・業務への影響
| 確認する内容 | 責任者が知りたい答え |
|---|---|
| 自社が該当するか | どの機器・ソフトウェアの、どのバージョンが対象か |
| 攻撃が成立する条件 | 対象機能を使っているか。外部から到達できるか。既存の対策で条件を遮断できているか |
| 技術的な被害 | 情報閲覧、改ざん、権限取得、停止など、何が起こり得るか |
| 事業への影響 | どの業務・顧客・取引先に影響するか。復旧や代替運用は可能か |
ここは、経営者が自分で機器を調べるという話ではありません。現場や保守会社の調査結果を、判断できる形で受け取るための整理です。
対象製品を使っているかの確認には、バージョンや担当者まで分かる資産情報が役立ちます。台帳の作り方は、中小企業のIT資産台帳の作り方で整理しています。
KEVとは？既に悪用されている脆弱性を知る材料
KEV（Known Exploited Vulnerabilities）は、米国のサイバーセキュリティ機関CISAが公開する、実際の攻撃で悪用されたことが確認されている脆弱性の一覧です。
CVSSが技術的な深刻度の説明に使えるのに対し、KEV掲載は「この弱点を使った攻撃は、既に起きている」という事実を示します。自社で悪用可能な状態なら、対応を前倒しする根拠が一つ増えます。
| 情報 | 分かること | 責任者の判断との関係 |
|---|---|---|
| CVSSの基本点 | 共通基準での技術的な深刻度 | 「重大」という説明の尺度を共有できる |
| KEVへの掲載 | 実際の悪用が確認されている | 自社も該当するなら、先送りの妥当性を再検討する材料になる |
| 自社環境の調査 | 対象製品・機能・攻撃経路の有無 | 一般的な警報を、自社の問題として判断できる |
KEVに載っていないことは、安全の証明ではありません。まだ確認・掲載されていない攻撃や、新しく公表された弱点もあるためです。また、KEVにある対応期限を、日本の民間企業に一律の義務や「そこまでは安全な期間」として当てはめることもできません。
一覧の検索や製品との照合は専門担当者に任せ、責任者は「悪用実績があるか」「自社で同じ攻撃が成立するか」を説明に含めてもらう形が現実的です。
脆弱性対応の優先順位を決める報告は、点数と対策案をセットにする
「深刻度が高い」と分かっても、対策費用も停止時間も不明なら、承認の判断は進みません。技術的な説明と、対策した場合・しない場合の事業への影響を、一つの報告にまとめると検討しやすくなります。
「8点なので急いでほしい」を、比較できる説明に変える
以下は、報告の組み立て方を示す架空の例です。費用・時間は相場や標準期限ではありません。
| 項目 | 説明例 |
|---|---|
| 共通の深刻度 | CVSS基本点は8点台で、「高」の区分です。版・出典を報告書に添付しています |
| 点数の理由 | 外部から攻撃でき、悪用されると保存情報を読み取られるおそれがあります |
| 現実の脅威・自社の該当 | 実際の悪用が確認されています。当社の本番システムも対象で、攻撃に必要な条件が成立しています |
| 対策しない場合 | 顧客情報が対象になります。漏えい時には調査・顧客対応・取引先への説明が発生します |
| 更新する案 | 作業費用20万円、受注システムの停止2時間。担当者が対応するため、別案件の検証が半日遅れます |
| 暫定策を使う案 | 対象機能を制限し、更新までの攻撃経路を減らします。ただし、利用できなくなる機能と残るリスクがあります |
| 現場の推奨 | メーカーの対策情報と稼働状況を踏まえ、本日暫定策を行い、夜間に更新する案を提案します |
責任者が比べるのは、8点という数字と20万円だけではありません。 更新に伴う停止・案件の遅れと、先送りによって残る顧客・取引上のリスクを比べます。現場の推奨と理由があれば、責任者が対策案を一から組み立てる負担も減らせます。
暫定策は、対象の弱点に対して有効かを現場が確認したうえでの選択肢です。「ファイアウォールがあるから待てる」といった一般論だけでは、代替策の説明になりません。
対策費用の捉え方を整理したい場合は、セキュリティはコストか投資かも参考になります。
毎回の判断を軽くするには、脆弱性対応の承認範囲を揃える
共通の尺度を知っていても、小さな更新まですべて責任者に上がる体制では、確認の手間が増えます。現場で進められる対応と、事業責任者に判断を求める対応を分けることも、指標を活用する方法です。
例えば、通常の保守契約に含まれ、業務停止もない更新は現場で実施する。一方、追加費用、顧客向けサービスの停止、重要案件の遅延が伴う場合は、比較できる報告で承認を求める、という運用が考えられます。
| 対応の場面 | 社内基準の考え方の例 |
|---|---|
| 通常の保守範囲で対応できる | 現場の裁量で実施し、対応結果を記録する |
| 深刻度が高く、自社への影響を確認する段階 | 担当者と確認期限を決め、判明した事実を共有する |
| 悪用が確認され、自社で攻撃が成立し得る | 通常の定例会を待たず、対応案と事業影響を責任者へ共有する |
| 更新に停止や大きな追加費用が伴う | 更新案・暫定策・先送りの影響を比較して判断する |
これは運用例であり、CVSSの公式ルールではありません。具体的な対応期限は、メーカーの勧告、悪用状況、対象業務、契約や取引先の要求などを踏まえて会社で設定します。新しい攻撃情報が出たときに、点数が低いという理由で報告から外れない仕組みも重要になります。
延期する場合も、「何となく後で対応」ではなく、暫定策、担当者、次の判断日を残すと、リスクを抱えたまま忘れる事態を減らせます。
CVSS・KEVと脆弱性対応のFAQ
CVSSが9点以上なら、必ず即日更新するのですか？
9.0～10.0はCriticalの区分ですが、その点数自体が即日更新の義務を定めるわけではありません。自社への該当と攻撃条件を速やかに確認し、メーカーの対策情報などを踏まえて対応を検討します。更新前に有効な暫定策を取れる場合もあります。
管理者がCVSSの計算式を覚える必要はありますか？
通常の承認判断では、計算式よりも点数区分と評価内容を理解することが役立ちます。どこから攻撃でき、何をされるとその点数になるのか、現場に具体的な説明を求める形で使えます。版・基本点か環境を反映した点数かも、報告に添えてもらうと比較しやすくなります。
点数が違う報告書は、どちらを信じればよいですか？
同じ弱点でも、CVSSの版、製品のバージョンや構成、評価者の前提、基本点か環境評価を含む点数かによって数字が違う場合があります。平均を取るより、現場に出典と評価条件の違いを確認してもらうと、自社に合う説明につながります。
KEVにない脆弱性は、定期更新まで待てますか？
未掲載だけでは待てると判断できません。メーカーが緊急対応を求めているか、別の悪用情報があるか、自社で攻撃が成立するかも判断材料になります。KEVは対応を急ぐ根拠を補う一覧で、未掲載の弱点を安全と認定するものではありません。
共通の点数を、責任者が判断できる報告へ
現場の「危険です」と責任者の「どれくらい深刻なのか」がかみ合わないと、そのたびに説明と確認が繰り返されます。CVSSは、技術的な深刻度を同じ尺度で理解する助けになります。
そこに悪用状況、自社での攻撃条件、顧客や業務への影響を加え、費用・停止時間・代替策と並べる。こうした報告があれば、責任者は技術的な評価を一からやり直さず、事業として何を選ぶかに時間を使いやすくなります。
脆弱性対応の優先順位を揃える価値は、判断を点数に任せることよりも、現場の専門的な評価を、責任者が比較できる材料として受け取れることにあります。
参考資料
- FIRST：CVSS v3.1 Specification Document — 第2章の評価項目、第5章の点数区分、第6章の評価内容の表記。
- FIRST：CVSS v4.0 User Guide — 基本点とリスクの違い、脅威・環境情報で補う考え方。
- IPA：共通脆弱性評価システムCVSS v3概説 — 日本語での基本・現状・環境評価の説明。
- CISA：Known Exploited Vulnerabilities Catalog — 悪用確認済み脆弱性の一覧。個別製品への照合に利用できます。
- 京都大学情報環境機構：脆弱性対応の原点回帰 — 資産把握、CVSS、KEVを使う優先順位付けの解説。
- ISOG-J：トリアージで決めるべきこと — 資産の重要度と脆弱性の危険度を組み合わせる考え方。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント