CVEとは？脆弱性ニュースの「CVE-◯◯◯◯」「CVSS 9.8」の読み方と、発注者が開発会社に確認する5つのこと

脆弱性（＝システムの安全上の欠陥）のニュースを見ると、「CVE-2026-12345」のような番号や「CVSS 9.8（緊急）」といった数字がよく出てきます。意味が分からないまま「うちは大丈夫だろうか」と不安だけが残った経験のある方も多いのではないでしょうか。

先に結論をお伝えします。CVEは脆弱性につけられた「世界共通の背番号」、CVSSは「深刻さの目安となる点数」です。どちらも、それだけで「自社が危ない」「今すぐ対応が必要」と決まるものではありません。発注者が押さえるべきなのは、番号と点数の意味を知ったうえで、「自社のシステムがその製品を使っているか」「使っているなら、いつ誰が対応するか」を開発会社に確認することです。

この記事では、CVEとは何か、CVSSの点数の読み方、ニュースを見たときの確認の進め方を、チェックリストと開発会社への質問例つきで解説します（内容は執筆時点の公開情報に基づきます）。

CVEとは？脆弱性ごとにつけられる世界共通の識別番号

CVE（Common Vulnerabilities and Exposures、シー・ブイ・イー）は、公開された脆弱性を1件ずつ特定するための、世界共通の識別番号の仕組みです。

📰 出典：CVE Program「Overview」

CVEプログラムの使命は、公開されたサイバーセキュリティ上の脆弱性を識別・定義し、一覧にすることとされています。1つの脆弱性に1つの「CVEレコード」（＝番号と、その脆弱性の説明・影響を受ける製品・参考情報などをまとめた記録）が作られます。

なぜ共通の番号が必要なのか

同じ脆弱性について、製品の開発元、セキュリティ会社、公的機関などがそれぞれ情報を出します。番号がなければ「この会社の注意喚起と、あの機関の発表は同じ話なのか？」が分かりません。共通の番号があることで、異なる組織の情報が同じ脆弱性についてのものだと判断したり、関連づけたりできるようになります。

📰 出典：IPA「共通脆弱性識別子CVE概説」

発注者にとっての実用的な意味は、開発会社やサーバー会社と話すときに、CVE番号を伝えれば「どの脆弱性の話か」が一発で通じることです。「ニュースで見たWordPressの脆弱性」よりも、「CVE-◯◯◯◯-◯◯◯◯」と番号で伝えたほうが、取り違えが起きません。

CVE番号の読み方：「CVE-年-連番」

CVE番号は「CVE-西暦-数字」という形をしています。

部分	意味	注意点
CVE	CVE番号であることを示す接頭辞	—
西暦（例：2026）	番号が予約された年、または脆弱性が公開された年	脆弱性が発見された年ではない
数字（例：12345）	4桁以上の任意の番号	桁数に上限はなく、大きさに深刻さなどの意味はない

📰 出典：CVE Program「Process」

数字の部分は通し番号のようなもので、「番号が大きい＝危ない」「キリのいい番号＝特別」といった意味はありません。

番号は誰がつけている？

CVE番号は、CVEプログラムに参加する世界中の組織が割り当て・公開しています。こうした組織はCNA（CVE Numbering Authority＝CVE番号を割り当てる権限を持つ組織）と呼ばれ、ソフトウェアの開発元やセキュリティ機関などが担っています。日本では、IPAとJPCERT/CCが共同で運営する脆弱性情報サイト「JVN」もCVEの枠組みに参加しています。

CVEレコードは、おおまかに次の流れで公開されます。

1. 誰かが脆弱性を発見する
2. 発見者がCVEプログラムの参加組織に報告する
3. 参加組織がCVE番号を割り当て、予約する（この時点では非公開のことがある）
4. 影響を受ける製品・バージョン、脆弱性の種類、参考情報などの詳細をそろえる
5. 必要な情報がそろったら、CVEレコードとして公開する

つまり、公開されたCVEレコードには、影響を受ける製品やバージョンなど、確認に必要な基本情報がそろっています。ニュースを見たら、まずCVE番号からこの情報をたどるのが近道です。

CVSSとは？脆弱性の深刻さを0〜10点で表す指標

CVEとセットでよく出てくるのが、CVSS（Common Vulnerability Scoring System＝共通脆弱性評価システム）です。脆弱性の深刻さを0.0〜10.0の点数で表す世界共通の評価方法で、FIRST（Forum of Incident Response and Security Teams）という国際団体が仕様を公開しています。

ここで大事なのは、CVEとCVSSは別の仕組みだということです。CVEは「番号」をつけるだけで、深刻さの点数はつけません。点数は、製品の開発元や各国のデータベースなどがCVSSを使って評価します。そのため、同じCVEでも評価する機関によって点数が違うことがあります。

点数と深刻度の目安

CVSS v3.1の仕様では、点数と深刻度の呼び方が次のように対応づけられています。

CVSSの点数	深刻度（英語）	日本語でよく使われる呼び方
0.0	None	なし
0.1〜3.9	Low	注意
4.0〜6.9	Medium	警告
7.0〜8.9	High	重要
9.0〜10.0	Critical	緊急

📰 出典：FIRST「CVSS v3.1 Specification Document」

日本語の呼び方は、IPAの解説で使われているものです。

📰 出典：IPA「共通脆弱性評価システムCVSS v3概説」

2023年11月には新しい版のCVSS v4.0も公開されています。ニュースや発表では、v3.1とv4.0のどちらで評価した点数かが併記されることが多いので、見比べるときは版をそろえて見るようにしましょう。

点数が高い＝自社が危ない、ではない理由

CVSSの点数のうち、ニュースでよく見るのは「基本評価」と呼ばれるものです。CVSS v4.0の仕様では、基本評価は脆弱性そのものの性質にもとづき、さまざまな環境で起こりうる「現実的な最悪のケース」を想定した点数だと説明されています。

📰 出典：FIRST「CVSS v4.0 Specification Document」

同じ仕様では、点数を使う側の組織が、次のような要素を加えて評価し直すことが推奨されています。

• 脅威の状況：攻撃方法が公開されているか、実際に悪用されているか
• 自社の環境：その製品をどう使っているか、ネットに公開しているか、ほかに防御策があるか、止まったときの影響は大きいか

たとえば「CVSS 9.8」の脆弱性でも、自社がその製品を使っていなければ関係ありません。逆に、点数が中程度でも、自社の顧客情報を扱うシステムがインターネットに公開された状態で使っているなら、優先して対応すべきこともあります。点数は「急ぐべきかどうか」を考える材料の1つであって、答えそのものではないと覚えておきましょう。

脆弱性ニュースを見たとき、発注者が確認する流れ

CVE番号とCVSSの意味が分かったら、次の流れで確認を進めます。

ステップ1：どの製品のどのバージョンが対象かを見る

ニュースや発表には、影響を受ける製品名とバージョンが書かれています。日本語で確かめたい場合は、JVN（Japan Vulnerability Notes）でCVE番号を検索すると、対応する日本語の情報が見つかることがあります。JVNの脆弱性レポートには「影響を受けるシステム」「想定される影響」「対策方法」が整理されています。

📰 出典：JVN「脆弱性レポートの読み方」

ステップ2：自社のシステムがその製品を使っているか確認する

ここが一番大事なステップです。ただ、システムの中でどんな製品・部品が使われているかは、発注者には分からないことがほとんどです。開発会社に「このCVE番号の脆弱性は、うちのシステムに関係ありますか？」と聞くのが確実です。

日頃から「どのシステムで、どの製品の、どのバージョンを使っているか」を一覧（IT資産台帳）にしておくと、この確認が早くなります。作り方は次の記事で紹介しています。

ステップ3：対策の内容・時期・費用を開発会社と決める

対象だった場合は、修正版への更新（解決策）や、更新までの一時的な対策（回避策）を開発会社と相談します。JVNでは、パッチ（＝修正プログラム）や更新版で脆弱性そのものを直すものを「解決策」、脆弱性は残るが悪用されたときの影響を小さくするものを「回避策」と呼び分けています。

あわせて、その作業が保守契約の範囲内か、別途費用がかかるかも確認しましょう。誰が更新作業を担当するかがあいまいな場合は、次の記事の役割分担表が参考になります。

やりがちな失敗

やりがちなこと	なぜ困るか	どうすればいいか
CVSSの点数だけで「うちは急がなくていい」と判断する	自社の使い方によっては、点数以上に危ないことがある	点数と、自社での使い方をセットで開発会社に確認する
「緊急」の文字を見て、慌ててシステムを止める	止める必要がない場合でも業務やお客様に影響が出る	まず該当するかを確認し、止めるかどうかは開発会社と相談して決める
製品名だけで問い合わせる	同じ製品に複数の脆弱性があり、どれの話か伝わらない	CVE番号をそのまま伝える
開発会社からの「対応済み」の一言で終わらせる	何をしたのか、残っているリスクがあるのかが分からない	対応内容（更新か回避策か）と実施日を記録してもらう

発注者がやること チェックリスト

• ☐ CVEは「脆弱性の背番号」、CVSSは「深刻さの目安の点数」だと理解した
• ☐ 気になる脆弱性のCVE番号を控え、番号で開発会社に問い合わせるようにした
• ☐ 自社のシステムで使っている主な製品・バージョンの一覧（IT資産台帳）があるか確認した
• ☐ 脆弱性への対応が保守契約に含まれるか、含まれない場合の費用の決め方を確認した
• ☐ 開発会社が脆弱性情報をどう把握し、いつ発注者に連絡するかを確認した
• ☐ 対応した内容（更新・回避策・対象外の判断）と日付を記録してもらうようにした

開発会社への質問例

• 「ニュースで見た CVE-◯◯◯◯-◯◯◯◯ の脆弱性は、当社のシステムに関係ありますか？」
• 「関係がある場合、修正版への更新で対応できますか？更新までの間にできる回避策はありますか？」
• 「この対応は保守契約の範囲内ですか？別途費用がかかる場合、目安を教えてください」
• 「当社のシステムで使っている製品やバージョンの一覧をいただけますか？」
• 「重大な脆弱性が出たとき、どのくらいの期間で当社に連絡をもらえますか？」

まとめ

CVEは、公開された脆弱性を1件ずつ見分けるための世界共通の番号です。番号の年は発見された年ではなく、数字の大きさにも意味はありません。CVSSは深刻さを0〜10点で表す目安で、ニュースでよく見る点数は「最悪のケース」を想定した基本の評価です。

どちらも「自社が危ないかどうか」を直接教えてくれるものではありません。脆弱性のニュースを見たら、CVE番号を控えて開発会社に「うちのシステムに関係あるか」「対応はいつ・誰が・どの契約で行うか」を確認しましょう。日頃からIT資産台帳と連絡の流れを整えておくと、いざというときに慌てずに済みます。

あわせて読みたい関連記事