「CVSS 9.8」は誰が決める？ 脆弱性発見からCVE公開までの裏側プロセス

はじめに

「🚨緊急：CVSSスコア 9.8の脆弱性が公開されました。直ちに対応してください」

こんな通知が届いて、肝を冷やした経験のあるエンジニアが多いのではないでしょうか。
私たちは普段、この「CVSSスコア（脆弱性評価指標）」や「CVE番号」を当たり前のように参照していますが、ふと疑問に思うことはありませんか？

• この「9.8点」って、具体的に誰が決めてるんだ？
• バグが見つかってから、世界中に公開されるまで、裏側では何が起きているの？

この記事では、脆弱性が発見されてから、手元に情報が届くまでの「指標決定のプロセス」を解説します。
これを知ると、ニュースの見方が少し変わるかもしれません。

1. そもそも誰が決めているのか（登場人物）

まずは、このエコシステムを支える主な登場人物を整理します。

• 🕵️‍♂️ 発見者 (Reporter)
  • セキュリティリサーチャーや、善意のエンジニア
  • 企業公認の「バグバウンティ（報奨金制度）」で活躍するハンターもここに含まれます
• 🏢 ベンダー (Vendor)
  • ソフトウェアを作っている開発元（Microsoft, AWS, OSSメンテナなど）
• 🔑 CNA (CVE Numbering Authority) ※ここが重要
  • CVE番号を採番・割当する権限を持つ組織です
  • MITRE社だけでなく、GoogleやAdobeなどの大手ベンダーも自社製品に対してCNAとして認定されています
• 📚 NVD (National Vulnerability Database)
  • 米国政府が管理する、世界最大級の脆弱性データベース

2. 発見から公開までのタイムライン ⏳

脆弱性が「CVE-202X-XXXX」として世に出るまでには、一般的に以下のフローをたどります。

Step 1: 発見と報告 (Responsible Disclosure)

発見者は、いきなりX（旧Twitter）で「バグ見つけた！」と拡散するのではなく、まずはベンダーにこっそりと報告します。これを 「責任ある開示 (Responsible Disclosure)」 と呼びます。

※いきなり世間に公表してしまうことは「Full Disclosure」と呼ばれ、ベンダーと揉める原因になります。

Step 2: CVE IDの予約 (Reserved)

ベンダーが報告を受け、「確かにこれは脆弱性だ」と認めた段階で、CNAに対して「CVE番号を1つ確保してください」と依頼します。
この時点では、CVEリスト上では Reserved というステータスになり、中身（詳細情報）はまだ空っぽです。

Step 3: スコアリング (CVSSの計算) 🧮

ここが今回の本題です。
ベンダー（またはCNA）は、その脆弱性がどれくらい危険かを CVSS (Common Vulnerability Scoring System) という世界共通の物差しで計算します。

「なんとなくヤバそうだから High」と決めているわけではありません。
8つの評価基準（パラメータ） があり、それぞれを選択することで自動的にスコアが算出されます。

CVSS計算機（FIRST.org）

※ぜひ一度リンクを開いて、ポチポチ押してみてください。

CVSS基本値（Base Score）を決める8つのパラメータは、大きく「攻撃のしやすさ」と「影響の大きさ」に分かれます。

① 攻撃のしやすさ（Exploitability Metrics）

ハッカーにとって、その攻撃を行うハードルがどれだけ低いかを示します。

• AV: 攻撃経路 (Attack Vector)
  • Network (N): インターネット越しに攻撃可能（※一番ヤバい）
  • Adjacent (A): 隣接ネットワーク（Wi-Fi等）からのみ可能
  • Local (L): 端末へのログインや物理アクセスが必要
  • Physical (P): 物理的に触る必要がある（USBを挿す等）
• AC: 攻撃複雑さ (Attack Complexity)
  • Low (L): いつでも簡単に攻撃できる（※ヤバい）
  • High (H): 特定の競争状態など、運やタイミングが必要
• PR: 必要な特権 (Privileges Required)
  • None (N): 権限不要。誰でも攻撃できる（※一番ヤバい）
  • Low (L): 一般ユーザ権限が必要
  • High (H): 管理者権限が必要
• UI: ユーザ関与 (User Interaction)
  • None (N): 何もしなくても勝手に攻撃される（※ヤバい）
  • Required (R): クリックさせたり、ファイルを開かせたりする必要がある

② 影響の及ぶ範囲（Scope）

ここはCVSS v3の鬼門であり、スコアを大きく左右する要素です。

• S: スコープ (Scope)
  • Unchanged (U): 脆弱性のある部品だけで影響が完結する
  • Changed (C): 脆弱性のある部品を超えて、別の安全なはずの部品（管理外のシステム）へ被害が広がる。
    • 例：VM（仮想マシン）の脆弱性を使って、ホストOSを乗っ取る（VM Escape）
    • 例：Webサイトの脆弱性(XSS)を使って、閲覧者のブラウザを操作する
  • ※ここが「Changed」になると、スコアが一気に跳ね上がります。

③ 影響の大きさ（Impact Metrics / CIA）

攻撃が成功した際、守るべき資産がどうなるかを示します。

• C: 機密性 (Confidentiality)
  • 情報が漏れるか？ (High / Low / None)
• I: 完全性 (Integrity)
  • 情報が改ざんされるか？ (High / Low / None)
• A: 可用性 (Availability)
  • システムが停止するか？ (High / Low / None)

---

「CVSS 9.8」の正体とは、これら全てのパラメータにおいて 「最も攻撃しやすく(AV:N, AC:L, PR:N, UI:N)」「影響が最大(C:H, I:H, A:H)」 である状態（あるいはScope:Cを含む状態）を指します。

9.8と10.0の壁というものが存在しており、こちらはコラムとして後述に書いときます。

Step 4: 公開と同期 (Publish) 📢

パッチ（修正プログラム）の準備ができるタイミングに合わせて、ベンダーが情報を公開します。
その後、NVD（データベース）に情報が同期され、世界中のセキュリティスキャナやニュースサイトがそれを検知できるようになります。

3. 私たちはどう見るべきか（環境値の話）

CVSSには3つのスコア軸があることをご存知でしょうか？

1. 基本値 (Base Score): 脆弱性そのものの深刻度（ベンダーやNVDが出す）
2. 現状値 (Temporal Score): 攻撃コードが出回っているか？ パッチはあるか？（時間とともに変化）
3. 環境値 (Environmental Score): ⚠️ 実はこれが一番大事です。

ニュースで流れるのは「1. 基本値」だけです。しかし、実際の運用では「3. 環境値」で再計算する必要があります。

思考のシミュレーション

例えば、「CVSS 9.8」の脆弱性が発表されたとします。

世間の反応 😱
「CVSS 9.8だ！ 緊急対応が必要だ！」

冷静な分析（環境値の考慮） 🤔
「でも、この脆弱性の攻撃経路(AV)は『ネットワーク』だけど、うちはこのサーバをインターネットに公開していないし、内部からもアクセス制限している」

結論 ✅
「うちの環境に限っては、緊急度はそこまで高くない（Low〜Medium）。定例パッチで対応しよう」

このように、スコアの数字そのものより「自分の環境で刺さるかどうか」という判断ができるようになります。
AV:N→AV:A、AV:LあるいはAV:P相当とみなして対応を進める。

攻撃経路が変わるならAC、PRも変わるのでは？と思うかもしれませんが、PR（権限）やAC（複雑さ）は変更しません。
ざっくりとした説明になりますが、階層（レイヤー）が違う（NW層 vs アプリ層）と考えてもらえれば

4. まとめ

脆弱性情報は、誰かが鉛筆を転がして決めているわけではなく、CNAによる採番プロセスと厳密な計算式によって運用されています。

次に「CVSS 9.8」というニュースを見たら、単に数字に驚くだけでなく、ぜひ 「なぜ9.8なのか？（ベクトルの内訳）」 を見てみてください。

もし内訳が……

• AV:N （ネットワーク経由で）
• AC:L （攻撃条件が簡単で）
• PR:N （権限不要で攻撃可能）

となっていたら、それは 「今すぐパッチを当てるべき危険なもの」 です。正しく恐れて、正しく対応しましょう。

---

💡 補足：日本の独自ルール「早期警戒パートナーシップ」

※海外は協調的脆弱性開示（CVD）
日本国内のソフトウェアに関しては、IPA（届出）→ JPCERT/CC（調整） というルートが存在します。

これにより、CVE番号だけでなく日本独自の 「JVN番号」 も付与されます。私たちが普段見ている JVN iPedia は、NVDの翻訳だけでなく、この国内独自の調整結果も含まれているのです。

---

参考リンク

• 共通脆弱性評価システムCVSS v3概説 (IPA)
• FIRST CVSS v3.1 Calculator
• 脆弱性関連情報の届出受付 (IPA)

---

コラム：なぜ「10.0」ではなく「9.8」なのか？ 🤔

ニュースでよく見るスコアは「9.8」が多いと思いませんか？
実は、CVSS v3の計算式では、Scope（スコープ） がカギを握っています。

• Scope: Unchanged (変更なし) → 全て最悪でも Max 9.8
• Scope: Changed (変更あり) → 全て最悪なら Max 10.0

一般的なサーバの乗っ取り（RCE）は、「そのサーバ内で完結する」とみなされるため、S:U となり 9.8 でカンストします。
逆に 10.0 が出るのは、「ゲストOSからホストOSへの脱出（VM Escape）」のように、「管理外の領域（別世界）まで破壊しに行く」 という特殊なケースが多いのです。

「9.8」を見たら、「あ、サーバ単体としては即死だな」と判断して差し支えないです。

2025年12月のReactなぜ「10.0」なのか？

通常のReactの脆弱性（XSSなど）と比較すると、違いがわかります。

項目	① 通常のReact脆弱性 (XSS)	② 今回の脆弱性 (RCE)	理由（今回のケース）
場所	ユーザのブラウザ	サーバ本体	攻撃の及ぶ場所が「本丸」である
AV (経路)	Network (N)	Network (N)	インターネット越しに攻撃可能
AC (複雑さ)	Low (L)	Low (L)	特別な条件不要で攻撃可能
PR (権限)	None (N)	None (N)	ログインしていなくても攻撃可能
UI (ユーザ)	Required (R)	None (N) ⚠️	被害者がリンクを踏む必要すらなく、攻撃者が一方的にサーバへ通信するだけで成立する
S (スコープ)	Unchanged (U)	Changed (C) ⚠️	サーバを乗っ取ることで、データベースや他のシステム（管理外の領域）まで破壊可能とみなされた
影響 (CIA)	部分的	High (H) 全部	機密情報、改ざん、停止すべてが「最悪」レベル
結果	6.1 (Medium)	10.0 (Critical)