はじめに
セキュリティ情報を見ていると、こんな表記を見かけることがあります。
- CVSS 9.8
- CVSS v3.1 Base Score
- Critical
- High
- 認証なしでリモートから悪用可能
なんとなく「数字が高いほど危なそう」という雰囲気はあります。
でも、いざ読もうとするとこう思いませんか？
CVSSってそもそも何？
誰が決めてるの？
スコアが高かったら即パッチなの？
なんで脆弱性情報ってずっと出続けるの？
この記事では、CVSSを脆弱性情報を読むためのものさしとして、初心者向けに整理します。
特定の製品や個別の脆弱性ではなく、CVSSや脆弱性情報を読むときの基本的な考え方を扱います。
CVSSとは
CVSSは、Common Vulnerability Scoring Systemの略です。
日本語でざっくり言うと、脆弱性の深刻度を数値で表すための共通ルールです。
スコアは 0.0〜10.0 で表されます。
数字が大きいほど、一般的には深刻度が高いと考えます。
| スコア | 深刻度の目安 |
|---|---|
| 0.0 | None |
| 0.1〜3.9 | Low |
| 4.0〜6.9 | Medium |
| 7.0〜8.9 | High |
| 9.0〜10.0 | Critical |
CVSSの仕様はFIRSTが管理しており、CVSS v4.0ではBase、Threat、Environmental、Supplementalという指標グループで構成されています。Base Scoreは、脆弱性そのものが持つ性質に基づく深刻度を表すものです。
なお、実際の脆弱性情報では CVSS v3.1 と CVSS v4.0 の両方を見かけることがあります。
この記事では、細かなバージョンごとの違いには深入りせず、脆弱性情報を読むための基本的な考え方に絞って説明します。
参考: FIRST - CVSS v4.0 Specification Document
まず大事なこと：CVSSだけで対応優先度は決まらない
CVSSスコアを見ると、ついこう思いがちです。
CVSS 10.0！？やばい！今すぐ全部パッチ！
もちろん、スコアが高い脆弱性は注意が必要です。
ただし、CVSSは 単独で対応期限や対応方法を決めるものではありません。
CVSSはあくまで、
この脆弱性そのものは、一般的に見てどれくらい深刻か
を表すためのものです。
実際にどれくらい急いで対応するかは、自分たちの環境によって変わります。
たとえば、同じCVSS 9.8の脆弱性でも、次の2つでは緊急度が変わります。
ケースA
- インターネットに公開されている
- 本番環境で使っている
- 重要なデータを扱っている
- 認証なしで攻撃できる
- すでに悪用コードが出回っている
これは、かなり急いで確認・対応したい状況です。
ケースB
- 外部から到達できない
- 検証環境でしか使っていない
- 重要データを扱っていない
- 一時的にしか動いていない
この場合も無視してよいわけではありません。
ただし、ケースAと同じ緊急度とは限りません。
つまり、CVSSは判断材料のひとつです。
最終的な優先度は、環境、公開範囲、重要度、攻撃状況などとセットで考えます。
脆弱性情報はどういうサイクルで回っているのか
脆弱性情報は、突然「危険！パッチ！」と降ってくるように見えるかもしれません。
でも裏側では、ざっくり次のような流れで整理されています。
[脆弱性の発見]
↓
[影響範囲の調査]
↓
[CVEなどで識別]
↓
[CVSSなどで深刻度を評価]
↓
[パッチや回避策の公開]
↓
[利用者が自分の環境で優先度を検討]
↓
[適用・監視・再評価]
もう少し噛み砕くと、こうです。
1. 脆弱性が発見される
ソフトウェアやシステムに、セキュリティ上の弱点が見つかります。
発見するのは、セキュリティ研究者、開発者、利用者、診断会社、ベンダー自身などさまざまです。
2. 影響範囲が調査される
次に、どの製品・バージョン・条件で影響するのかを確認します。
ここで大事なのは、脆弱性は単に「ある / ない」だけでは語れないことです。
- どのバージョンが対象か
- どの設定で影響するか
- どの機能を使っていると影響するか
- 攻撃には認証が必要か
- 外部から攻撃できるか
こうした条件を整理します。
3. 必要に応じてCVE番号などで識別される
脆弱性には、CVEのような識別番号が付くことがあります。
CVEは、脆弱性を一意に参照しやすくするための番号です。
イメージとしては、脆弱性に付ける「管理番号」のようなものです。
4. CVSSなどで深刻度が示される
その脆弱性がどれくらい深刻なのかを、CVSSなどの指標で示します。
ここで出てくるのが、CVSS 7.5、CVSS 9.8、Critical、Highといった表記です。
5. パッチや回避策が公開される
製品やソフトウェアを提供している側が、修正パッチや回避策を公開します。
対応方法は、必ずしもパッチだけではありません。
- 修正パッチを適用する
- 設定を変更する
- 一時的に機能を無効化する
- アクセス制限をかける
- 監視を強化する
状況によって、さまざまな対応があります。
6. 利用者が自分の環境で優先度を検討する
ここがとても重要です。
公開された情報を見て、利用者側は自分の環境に照らして考えます。
- 対象製品を使っているか
- 対象バージョンに該当するか
- 外部から到達できるか
- 重要なデータを扱っているか
- すでに攻撃が観測されているか
- パッチ適用による業務影響はあるか
- 回避策で一時対応できるか
CVSSはその判断材料になりますが、CVSSだけで全部が決まるわけではありません。
CVSSスコアはどういう基準で決まるのか
CVSSは「なんとなく危なそう」で点数を付けているわけではありません。
いくつかの観点を組み合わせて、脆弱性の深刻度を評価します。
初心者向けにざっくり見るなら、次のような軸です。
1. どこから攻撃できるか
攻撃者がどこから攻撃できるのか、という観点です。
たとえば、
- インターネット越しに攻撃できる
- 同じネットワーク内から攻撃できる
- 対象マシンにログインしていないと攻撃できない
- 物理的に触れないと攻撃できない
一般的には、遠くから攻撃できるほど深刻度は高くなりやすいです。
イメージとしては、家の鍵に例えるとわかりやすいです。
家の中に入らないと悪用できない弱点
よりも、
外の道路から悪用できる弱点
の方が怖い
ソフトウェアでも同じです。
外部から到達できる場所にある脆弱性は、攻撃される可能性が高くなります。
2. 攻撃は簡単か
攻撃にどれくらい難しい条件が必要か、という観点です。
たとえば、
- 特別な条件なしで攻撃できる
- 特定の設定が必要
- タイミングが難しい
- 複雑な手順が必要
- 特殊な環境でしか成立しない
攻撃が簡単であればあるほど、深刻度は高くなりやすいです。
誰でも簡単に再現できる攻撃
と
かなり特殊な条件でしか成功しない攻撃
では、危険度の見え方が違う
ということです。
3. 認証や権限が必要か
攻撃にログインが必要かどうかも重要です。
たとえば、
- ログインなしで攻撃できる
- 一般ユーザー権限が必要
- 管理者権限が必要
この中では、ログインなしで攻撃できる脆弱性が特に注意されやすいです。
なぜなら、攻撃者がアカウントを持っていなくても攻撃できる可能性があるからです。
セキュリティ情報でよく見る、
remotely exploitable without authentication
という表現は、ざっくり言うと、
認証なしで、ネットワーク越しに悪用される可能性がある
という意味です。
これはかなり注意したい表現です。
4. ユーザー操作が必要か
攻撃にユーザーの操作が必要かどうかも見ます。
たとえば、
- 攻撃者が直接リクエストを送れば成立する
- ユーザーが悪意あるリンクをクリックすると成立する
- ユーザーが添付ファイルを開くと成立する
ユーザー操作が不要な脆弱性は、攻撃者だけで攻撃を進めやすくなります。
一方で、ユーザー操作が必要な場合でも安心とは限りません。
フィッシングメールやチャット、SNSなどでリンクを踏ませる攻撃は現実にあります。
つまり、
ユーザー操作が必要 = 安全
ではありません。
ただし、CVSS上の評価では、攻撃成立までにユーザー操作が必要かどうかは重要な観点になります。
5. 何が起きるか
最後に、攻撃が成功したときの影響を見ます。
代表的なのは次の3つです。
| 観点 | 何が起きるか |
|---|---|
| Confidentiality | 情報が漏れる |
| Integrity | データが改ざんされる |
| Availability | サービスが止まる |
日本語で言うと、
- 機密性
- 完全性
- 可用性
です。
少し堅い言葉なので、ざっくり言い換えるとこうです。
見られたら困る情報が見られる
勝手に書き換えられる
使いたいときに使えなくなる
この影響が大きいほど、スコアは高くなりやすいです。
CVSSをざっくり読むためのチェックリスト
脆弱性情報を見たときは、まず次の順番で眺めると理解しやすいです。
1. スコアはいくつか
2. Critical / High / Medium / Low のどれか
3. ネットワーク越しに攻撃できるか
4. 認証なしで攻撃できるか
5. 攻撃は簡単か
6. ユーザー操作は必要か
7. 情報漏えい・改ざん・停止につながるか
8. 自分の環境で対象になっているか
特に初心者のうちは、次の3つを見るだけでもかなり理解しやすくなります。
外から攻撃できる？
ログインなしで攻撃できる？
成功すると何が起きる？
この3つがそろって危なそうなら、かなり注意した方がよいです。
実務で見るときの注意
実際の対応では、CVSSだけでなく、次のような情報も合わせて確認します。
- ベンダーの公式アドバイザリ
- 対象製品・対象バージョン
- 既知の悪用有無
- 攻撃コードの公開有無
- 回避策の有無
- 自分の環境での公開範囲
- 業務影響
- 組織内のパッチ適用ルール
特に、公式アドバイザリに記載された影響範囲や回避策は重要です。
CVSSは判断材料のひとつとして使い、最終的には自分たちの環境に照らして優先度を決めます。
では、CVSSが高いと必ず緊急対応なのか
ここが少しややこしいところです。
CVSSが高いということは、脆弱性そのものの深刻度が高いという意味です。
ただし、それがそのまま、
自分の環境で今すぐ大事故になる
という意味ではありません。
たとえば、次のような状況では見え方が変わります。
- 対象機能を使っていない
- 外部から到達できない
- 一時的な検証環境でしか使っていない
- 追加のアクセス制御を入れている
- 回避策を適用済み
- 重要データを扱っていない
逆に、CVSSが少し低めでも、次のような条件があると優先度が上がることがあります。
- インターネットに公開されている
- 重要な業務システムで使っている
- 攻撃コードが公開されている
- 実際の攻撃が観測されている
- 認証なしで悪用できる
- 横展開の入口になりそう
つまり、CVSSは大事です。
でも、CVSSだけを見て判断すると危ないです。
CVSSは入口です。
実際の対応優先度は、環境とセットで考えます。
「脆弱性が出続ける製品」は信頼できないのか
ここも初心者が引っかかりやすいポイントです。
長く使われている安定した製品なのに、毎月のように脆弱性情報やパッチが出ると、
そんなに脆弱性があるの？
それって信頼できないのでは？
と思うかもしれません。
でも、脆弱性が出続けることは、必ずしも「信頼できない」という意味ではありません。
理由はいくつかあります。
昔は問題視されていなかったものが、今は危険になる
ソフトウェア自体が大きく変わっていなくても、攻撃手法やセキュリティの基準は変わります。
昔は普通だった実装が、今では危険と判断されることがあります。
たとえば、
- 古い暗号方式が安全ではなくなる
- 入力チェックの考え方が変わる
- 認証や権限管理のベストプラクティスが変わる
- 新しい攻撃手法が登場する
これは、古い建物の耐震基準に少し似ています。
建物が突然ダメになったというより、
新しい知見や基準に照らすと、補強が必要だと分かることがあります。
ソフトウェアも同じで、時間が経つほど安全基準が変わります。
製品本体ではなく、周辺部品に問題が見つかることもある
大きなソフトウェアは、単体で存在しているわけではありません。
多くの場合、次のようなものに依存しています。
- OS
- ライブラリ
- フレームワーク
- ランタイム
- 通信プロトコル
- 管理ツール
- 外部コンポーネント
製品本体のコードが安定していても、依存している部品で脆弱性が見つかることがあります。
その場合、利用者から見ると「その製品に関係するセキュリティ情報」として見えることがあります。
使われ方が変わると、リスクも変わる
昔は社内ネットワークだけで使っていたシステムが、今ではクラウド、API連携、リモートアクセス、外部公開環境で使われることがあります。
同じソフトウェアでも、
社内だけで使う
のと、
インターネットからアクセスできる
のでは、リスクがまったく違います。
製品が変わらなくても、利用環境が変わることで、脆弱性の見え方も変わります。
大事なのは「脆弱性がゼロ」ではなく「対応され続ける」こと
現実的に、脆弱性が一度も出ないソフトウェアを期待するのは難しいです。
むしろ大事なのは、脆弱性が見つかったときに、
- 影響範囲が説明される
- 深刻度が示される
- 修正パッチや回避策が提供される
- 利用者が判断できる情報が出る
- 継続的にメンテナンスされる
ということです。
セキュリティ対応は、一度きりのイベントではありません。
継続的な保守活動です。
CVSSを「危険アラーム」ではなく「翻訳ツール」として見る
CVSSを見ていると、どうしてもこう感じることがあります。
アラート！
危険！
パッチ！
またアラート！
また危険！
またパッチ！
たしかに、ずっと追いかけていると疲れます。
でもCVSSは、単なる「危険アラーム」ではありません。
むしろ、脆弱性情報を読むための翻訳ツールに近いです。
外から攻撃できるのか
ログインが必要なのか
攻撃は簡単なのか
成功すると何が起きるのか
どのくらい深刻なのか
こうした情報を、共通の形式で読みやすくしてくれるものです。
つまりCVSSは、
やばい！急げ！
と叫ぶための数字ではなく、
どこが、どんなふうに、どれくらい危ないのかを考えるための共通言語
です。
まとめ
CVSSは、脆弱性の深刻度を数値で表すための共通指標です。
スコアは0.0〜10.0で表され、数字が大きいほど深刻度が高いと考えます。
ただし、CVSSだけで対応期限や対応方法が決まるわけではありません。
CVSSが示しているのは、主に「その脆弱性自体が一般的にどれくらい深刻か」です。
実際にどう対応するかは、次のような観点とセットで考える必要があります。
- 対象製品・対象バージョンを使っているか
- 外部から到達できるか
- 認証なしで攻撃できるか
- 重要なデータを扱っているか
- 攻撃コードや悪用事例があるか
- パッチ適用による業務影響はあるか
- 回避策や監視で一時対応できるか
CVSSは、怖がるための数字ではありません。
脆弱性情報を冷静に読み、対応優先度を考えるためのものさしです。
セキュリティ情報を見たときに、
CVSSが高いから危ない
で止まるのではなく、
何が危ないのか
どの条件で危ないのか
自分の環境ではどれくらい急ぐべきか
まで見られるようになると、脆弱性情報がかなり読みやすくなります。
本記事は、CVSSや脆弱性情報の読み方を一般的に説明するものです。
特定の製品・サービスに対する公式なセキュリティ対応方針を示すものではありません。
実際の対応では、各製品の公式ドキュメント、セキュリティアドバイザリ、組織内の運用ルールに従ってください。