CVE・JVNの読み方と脆弱性情報の追い方。採番の仕組みからNVD・ベンダー情報までを整理する

「使っているソフトに重大な脆弱性が見つかったらしい」という話を聞いたとき、その一報がどこから来て、どの情報源を見れば一次情報にたどり着けるのか、すぐに答えられるでしょうか。ニュースサイトやSNSの要約は早いものの、影響範囲やバージョン条件を取り違えていることも珍しくありません。脆弱性対応で慌てないためには、情報がどう生まれ、どこで管理され、誰がどの役割を担っているかという「流通の地図」を持っておくことが土台になります。

この記事では、脆弱性情報の代名詞であるCVEがどう採番されるのか、そしてJVN・JVN iPedia・NVD・ベンダーアドバイザリがそれぞれ何を担っているのかを整理します。そのうえで、自社が使う製品に関係する情報を取りこぼさず追うための実務的な手順まで踏み込みます。難しい用語は出てきますが、原理から噛み砕いて説明するので、脆弱性管理をこれから始める人でも全体像をつかめるはずです。

CVSSスコアの読み解き方そのものは別記事で扱うため、ここでは「どの情報源に、何が、どのタイミングで載るのか」という流通構造に焦点を当てます。深さ優先で一つのデータベースを掘るより、まず全体の見取り図を持つことが、結果として取りこぼしを減らします。

脆弱性情報の早見表#

まず、よく出てくる情報源の役割を一覧で押さえます。それぞれ「何のために存在するか」が違うため、用途に応じて使い分けます。

CVEとは何か。なぜ「共通の住所」が必要なのか#

CVE(Common Vulnerabilities and Exposures)は、公開された脆弱性一つひとつに世界共通の識別子を与える仕組みです。識別子はCVE-西暦-番号という形式で、たとえばCVE-2021-44228のように表されます。前半が採番された年、後半はその年に割り当てられる識別用の番号(4桁以上)で、公開順や深刻度を表すものではありません。

なぜこのような共通IDが必要なのでしょうか。同じ脆弱性でも、ニュース記事、ベンダーの告知、セキュリティ製品の検知ログでそれぞれ別の呼び方をしていたら、「それは同じ問題なのか、別の問題なのか」を突き合わせるだけで膨大な手間がかかります。CVE IDという共通の住所があることで、「うちのスキャナが検知したこの番号と、ベンダーが修正したこの番号は同一だ」と機械的に照合できます。脆弱性管理ツール、データベース、アドバイザリの多くがCVE IDを軸に情報をつないでいるのは、このためです。

注意したいのは、CVE IDが付いていること自体は「危険度」を意味しないという点です。CVEは識別のための番号であり、深刻度を表すものではありません。深刻度の目安はCVSSという別の指標で表されます。CVSSスコアの読み方は

で詳しく扱います。CVE IDと深刻度を混同すると、「CVEが付いた=即座に大騒ぎ」という過剰反応につながりかねないので、両者は分けて考えてください。

CVEはどう採番されるのか。CNAの役割#

CVE IDは、誰でも勝手に発行できるわけではありません。CVEプログラムから認定を受けた組織が採番を担います。この認定組織をCNA(CVE Numbering Authority、CVE採番機関)と呼びます。

CNAには、大きく分けて二つのタイプがあります。一つは、自社製品の脆弱性に自分で番号を割り当てるベンダー(マイクロソフトやレッドハットなど)。もう一つは、特定ベンダーに属さない脆弱性を広く扱う調整役の機関です。日本では、JPCERT/CC(一般社団法人JPCERTコーディネーションセンター)がCNAとして活動しているほか、国内ベンダーもCNAに加わっています。CNAの数は年々増えており、執筆時点では世界で数百組織が参加しています。

採番のおおまかな流れは次のとおりです。発見者が脆弱性を報告し、対象製品のベンダーがCNAであればそのベンダーが、そうでなければ調整役のCNAがCVE IDを割り当てます。割り当て後、修正版の公開などのタイミングで情報が公開され、各データベースに反映されていきます。

NVDの役割。CVEに「分析」を足す#

NVD(National Vulnerability Database)は、米国のNIST(国立標準技術研究所)が運営する公式の脆弱性データベースです。NVDはCVEと別の番号体系を持つわけではなく、CVE IDをそのまま使います。NVDの価値は、CVEの素の情報に対して、機械処理しやすい形で分析情報を付け足す点にあります。

具体的には、CVSSによる深刻度評価、影響を受ける製品やバージョンを表現するCPE(Common Platform Enumeration)、脆弱性の種類を分類するCWE(Common Weakness Enumeration)などが付与されます。たとえば「このCVEは、製品Xのバージョン2.0以上2.5未満が対象」といった情報を、CPEという統一フォーマットで持てれば、脆弱性管理ツールが「自社の資産にこのバージョンが存在するか」を照合する手がかりになります。ただしCPEの付与にはばらつきや欠落があり得るため、CPEは候補の絞り込みに使い、最終的な該当判断はベンダー情報と自社の構成で確認するのが安全です。

実務上の注意として、NVDの分析は人手と機械処理を組み合わせて行われるため、CVE公開からNVDでの分析完了までにタイムラグが生じることがあります。近年は登録される脆弱性件数が増え続けており、分析待ちの状態が一定数たまる場面もあります。

さらに重要な変化として、NISTは2026年4月以降、すべてのCVEにCVSSやCPEなどの付加情報(エンリッチメント)を付ける運用を見直しています。CVE自体はこれまでどおりNVDに登録されますが、付加情報の付与は、CISAのKEV(Known Exploited Vulnerabilities、既知の悪用された脆弱性)カタログ掲載分や米国政府が利用するソフトウェアなどが優先され、それ以外は「優先度が低く、ただちには付与しない」扱いになり得ます。また、採番機関(CNA)が付けたCVSSがある場合、NVD側で重複してスコアを付け直さない方針も示されています。つまり「NVDに行けばどのCVEにもCVSSやCPEが揃っている」という前提はもはや成り立ちません。したがって、「NVDにCVSSが付いていないから深刻度が低い」と早合点せず、採番機関のスコアやベンダーアドバイザリ側の評価も併せて確認することが、これまで以上に重要です。

JVNとJVN iPedia。日本語で追うための情報源#

海外発の情報源だけでは、日本国内で流通する製品や日本語環境の事情が抜け落ちることがあります。これを補うのがJVNとJVN iPediaです。

JVN(Japan Vulnerability Notes)は、JPCERT/CCとIPAが共同で運営する、日本国内向けの脆弱性情報ポータルです。国内で届け出られた製品の脆弱性や、海外製品でも国内利用者に影響の大きいものについて、日本語で注意喚起と対策の概要を提供します。届出を受けて調整したうえで公開される情報が多く、対象製品のベンダーと連携した「対策の出口」がそろっていることが特徴です。

一方、JVN iPediaは、IPAが運営する脆弱性対策情報のデータベースです。JVNで公開された情報に加え、国内外で公表された脆弱性対策情報を幅広く蓄積し、製品名やキーワード、深刻度などで横断的に検索できます。過去にさかのぼって「この製品に関する脆弱性が過去にどれだけあったか」を調べたいときに向いています。

JVN iPediaの登録状況はIPAが四半期ごとに統計を公表しており、登録件数の推移や傾向を確認できます。具体的な件数は時期によって変動するため、最新の統計を直接参照してください。

両者の使い分けはシンプルです。新しい注意喚起や調整済みの対策を日本語で素早く知りたいときはJVN、過去分も含めて条件を指定して検索したいときはJVN iPedia、と覚えておくとよいでしょう。

最初はJVNとJVN iPediaの違いが分からず、同じ情報が二重に存在しているのかと混乱した。役割が「速報・調整窓口」と「蓄積・検索」で分かれていると整理できてから、ようやく使い分けられるようになった。

ベンダーアドバイザリが最終的な一次情報#

データベース類は横断的な把握に役立ちますが、「実際にどう直すか」を確定させる一次情報は、各製品ベンダーが出すアドバイザリ(セキュリティ情報)です。修正版のバージョン番号、回避策(ワークアラウンド)、影響を受ける正確な条件は、最終的にベンダーの公式情報で確認するのが原則です。

なぜベンダー情報が最優先なのでしょうか。データベースの記述は要約であり、対象バージョンの境界や前提条件が簡略化されていることがあります。たとえば「特定の設定が有効な場合のみ影響する」「あるオプション機能を使っていなければ対象外」といった条件は、ベンダーアドバイザリにしか書かれていないことが多いのです。これを読まずに「CVEが付いているから全部対象だ」と判断すると、不要な緊急対応に追われたり、逆に本来対象なのに見逃したりします。

取りこぼさないための実務的な追い方#

情報源の地図を持てたら、次は「自社に関係する情報を継続的に拾う仕組み」を作ります。脆弱性情報は毎日大量に公開されるため、すべてを目視で追うのは現実的ではありません。鍵になるのは、対象を自社資産に絞り込むことです。

この流れの中で、最も効果が大きいのは最初の「資産の棚卸し」です。資産が把握できていないと、どれだけ情報を集めても「自社に関係するか」が判断できず、結局はニュースの大きさに振り回されることになります。逆に資産台帳が整っていれば、大量の情報の中から関係するものを機械的に絞り込めます。

で触れる依存ライブラリの管理(SBOMやSCA)も、この棚卸しと地続きの取り組みです。

よくある誤解と判断基準#

最後に、入門者がつまずきやすい点を整理します。

第一に、「CVE IDが付いた=自社が危険」ではありません。CVEは識別子であり、自社が対象かどうかは対象製品・バージョン・前提条件で決まります。第二に、「データベースに載っていない=安全」でもありません。公開前の脆弱性や、まだ反映されていない情報も存在します。第三に、深刻度スコアが高いことと、自社にとっての緊急度が高いことは必ずしも一致しません。攻撃が実際に出回っているか、インターネットに公開された資産かといった文脈で、優先順位は変わります。

つまり、機械的なスコアだけで判断を完結させず、「自社の文脈に当てはめる」工程を必ず挟むことが、実務での正しい使い方です。情報源の役割を理解したうえで、複数を組み合わせて文脈を補うこと。これが脆弱性情報を追ううえでの基本姿勢になります。

よくある質問#

まとめ#

脆弱性情報の世界は情報源が多く、最初は複雑に見えます。しかし、CVEが「共通の住所」を与え、NVDが「分析」を足し、JVN/JVN iPediaが「日本語での共有」を担い、ベンダーが「直し方」を示す、という役割分担で捉えれば、見通しはずっとよくなります。まずは自社の資産を把握し、関係する一次情報が届く仕組みを整えるところから始めてください。深刻度の読み解き方をさらに知りたい場合は

もあわせてご覧ください。