CVEとは？共通脆弱性識別子の仕組み・読み方・JVN・NVDを使った脆弱性情報の調べ方を解説

セキュリティニュースを読んでいると、「CVE-2024-XXXX」のような番号が頻繁に登場します。「これって何？自社に関係あるの？」と思いながら素通りしてしまっている方も多いのではないでしょうか。

CVE番号が読めるようになると、脆弱性情報の優先度判断や社内での報告がぐっとスムーズになります。この記事では、CVEの仕組みから番号の読み方、NVD・JVNを使った実践的な調べ方まで、現場で使えるレベルで解説します。

CVE（共通脆弱性識別子）とは？

CVE（Common Vulnerabilities and Exposures）は、ソフトウェアやハードウェアに発見されたセキュリティ上の脆弱性に付与される**世界共通の識別子**です。米国の非営利研究機関MITRE Corporationが1999年に制度を立ち上げ、現在は米国国土安全保障省（CISA）の支援を受けて運営されています。

CVEが生まれる以前は、各ベンダーや研究者がそれぞれ独自の名称で脆弱性を呼んでいたため、「同じ脆弱性を別の名前で呼んでいた」「複数の脆弱性を1件として扱っていた」という混乱が日常的に起きていました。CVEの登場によって、脆弱性に「共通の名札」が付くようになり、組織横断での情報共有や対策の足並みを揃えやすくなりました。

CVEと似た用語の整理

・CVE（Common Vulnerabilities and Exposures）: 個々の脆弱性を一意に識別するための番号とその簡潔な説明
・CVSS（Common Vulnerability Scoring System）: CVEに登録された脆弱性の深刻度を0.0～10.0で数値化する評価方式（別の仕組み）
・CWE（Common Weakness Enumeration）: バッファオーバーフローやSQLインジェクションなど、脆弱性の「種別」を分類する体系
・NVD（National Vulnerability Database）: 米国NISTが運営するCVEの拡張データベース。CVSSスコアや影響製品リストを付与して公開
・JVN（Japan Vulnerability Notes）: IPAとJPCERT/CCが共同運営する日本語の脆弱性情報データベース

CVEは「脆弱性に名前をつける仕組み」、NVDやJVNは「その脆弱性について詳しく調べられる場所」と理解すると整理しやすいです。

CVE番号の読み方

CVE番号は次の形式で構成されています。

CVE-2024-12345
 │    │    └─ シーケンス番号（その年の何件目かを表す連番）
 │    └───── 発見・登録年（西暦4桁）
 └──────────── 「CVE」固定プレフィックス

シーケンス番号について

初期は4桁が基本でしたが、脆弱性の報告件数が急増したため、現在は5桁以上になることも珍しくありません。CVE-2021-44228（Log4Shell）のように6桁のものもあります。番号自体に深刻度の情報は含まれていません。番号が大きい＝危険、という意味ではないことに注意してください。

CNA（CVE採番機関）の役割

CVE番号を発行できる組織を「CNA（CVE Numbering Authority）」と呼びます。MITRE本体のほか、Microsoft・Google・Apple・Red Hatなど大手ベンダーもCNAとして認定されており、自社製品の脆弱性には自らCVE番号を付与します。2026年時点で世界中に400以上のCNAが存在します。

脆弱性情報を調べるデータベースの使い方

1. NVD（National Vulnerability Database）

米国NISTが運営するNVDは、CVEエントリの中でも最も詳細な情報が集まる一次情報源です。CVSSスコア（深刻度の数値）、影響を受ける製品とバージョン、参考リンクなどが整理されています。

NVDで確認できる主な項目は以下のとおりです。

・CVSSv3スコア（0.0～10.0）: 深刻度の数値。7.0以上はHigh、9.0以上はCriticalと判断
・CWE分類: この脆弱性がどの種別に属するか（例: CWE-79はXSS）
・影響製品リスト（CPE）: 影響を受けるソフトウェア・バージョンの一覧
・参考リンク: ベンダーのセキュリティアドバイザリやPoC（概念実証コード）へのリンク

NVDは英語のみですが、セキュリティ担当者なら基本的な読み方は身に付けておきたいところです。

2. JVN（Japan Vulnerability Notes）

JVNはIPAとJPCERT/CCが共同で運営する日本語の脆弱性情報データベースです。国内で使われることの多いソフトウェアや、国内ベンダーからの報告を中心に掲載されており、日本語で脆弱性の概要と対策が読めます。

JVNには大きく2種類の掲載形式があります。

・JVN#XXXXXXXX（JVN形式）: JPCERT/CCが調整し、ベンダー確認が取れた製品脆弱性の情報
・JVN iPedia: NVDをはじめ各国の脆弱性データベースを集約した日本語のアーカイブ。CVE番号で検索可能

情シス担当者が日常業務で使うなら、まずJVN iPediaで対象CVEを検索し、日本語の概要を確認してから、必要に応じてNVDで詳細を見るという流れが現実的です。

3. 各ベンダーのセキュリティアドバイザリ

MicrosoftのPatch Tuesday、CiscoのSecurity Advisories、ApacheのSecurity Vulnerabilitiesなど、製品ベンダー自身が公開するアドバイザリも重要な情報源です。CVE番号と併記されていることが多く、パッチの有無や緊急度、回避策が明記されています。自社が利用するベンダーのアドバイザリRSSを購読しておくだけでも、見落としを大幅に減らせます。

中小企業でも今日からできること

1. 利用ソフトウェアのCVE通知を受け取る設定をする

NVDにはメール通知機能がなく、RSSやAPIを使う必要があります。しかし日本語で手軽に始めるなら、JVN iPediaの「登録製品の脆弱性通知サービス」（MyJVN）が便利です。自社で使っているOSやミドルウェアを登録しておくと、新しいCVEが公開された際にメールで通知が届きます。

2. CVSSスコアを優先度判断の出発点にする

全てのCVEを同じ重みで扱うのは現実的ではありません。一般的な目安として次の優先度で対処を検討するとよいでしょう。

・CVSS 9.0以上（Critical）: 確認次第、最優先で対処。パッチが存在する場合は即適用
・CVSS 7.0～8.9（High）: 1週間以内に対処計画を立てる
・CVSS 4.0～6.9（Medium）: 月次のパッチサイクルで対処
・CVSS 0.1～3.9（Low）: 他の対策と合わせて計画的に対処

ただし、CVSSスコアはあくまで出発点です。インターネット公開サーバーに存在するMediumスコアの脆弱性が、内部にのみ存在するHighスコアより緊急対応が必要になることもあります。自社環境の露出状況や実際の悪用状況（KEV: Known Exploited Vulnerabilities一覧）も合わせて判断してください。

3. 社内報告にCVE番号を使う習慣をつける

「Apache Strutsに危険な脆弱性が見つかった」と報告するより、「CVE-2026-XXXXX（CVSSスコア9.8）が公開されました。当社の本番サーバーで使用しているApache Struts 2.5系に影響があります」と伝えると、経営層・上司への説明が格段にスムーズになります。CVE番号は調査の出典としても機能するため、「どこで確認したか」という説明の手間も省けます。

なお、社内の脆弱性管理フローの整備方法については、脆弱性管理とは？発見・評価・修正・検証の4ステップと中小企業での実践ガイドで詳しく解説しています。パッチ適用の具体的な運用についてはパッチ管理の基礎も合わせてご覧ください。

よくある誤解と注意点

【誤解1】CVEに登録されていない脆弱性は安全？

そうとは限りません。CVEに登録されるまでには、発見・報告・採番・公開というプロセスを経るため、タイムラグがあります。発見されたばかりでまだ番号が振られていない脆弱性（いわゆる「ゼロデイ」）や、報告されないまま攻撃者が悪用している脆弱性も存在します。CVEはあくまで「公開された脆弱性の記録」であり、全ての脅威を網羅しているわけではありません。

【誤解2】CVEが公開されたらすぐ攻撃される？

CVE公開後、実際に悪用されるまでの期間は脆弱性によって大きく異なります。公開から数時間で攻撃コードが出回るケースもあれば、数ヶ月後に悪用が始まるケースもあります。CISAが公開するKEV（Known Exploited Vulnerabilities Catalog）は、実際に悪用が確認されたCVEの一覧です。KEV掲載CVEを優先的に対処する方針は、多くのセキュリティ機関が推奨しています。

【誤解3】CVSSスコアだけで対処優先度が決まる？

前述のとおり、CVSSスコアは脆弱性の本質的な深刻度を示しますが、自社環境での優先度はそれだけでは決まりません。「その脆弱性がある機器がインターネットに公開されているか」「脆弱なバージョンを本当に使っているか」「攻撃コードが広まっているか」などの文脈を加えて判断することが重要です。

【誤解4】パッチを当てればCVEへの対応は完了？

パッチ適用は最も確実な対処法ですが、パッチが存在しない場合や、すぐに適用できない事情がある場合もあります。そのような場合は、脆弱なコンポーネントを外部からアクセスできないよう制限する（ファイアウォールルールの追加、サービスの停止）などの暫定対処（ワークアラウンド）を検討します。ベンダーのアドバイザリには多くの場合ワークアラウンドも記載されています。

本記事のまとめ

CVEは「セキュリティ情報のインフラ」です。番号の読み方を知り、NVD・JVNを使いこなせるようになるだけで、セキュリティ情報の見え方が変わります。まずはMyJVNに自社の主要ソフトウェアを登録して、CVE通知を受け取る環境を整えることから始めてみてください。