共通脆弱性識別子

MITREのドキュメントでは、CVE識別子（「CVE名」、「CVE番号」、「CVE-ID」、「CVE」とも呼ばれる）を、一般に公開されているソフトウェアパッケージにおける公に知られた情報セキュリティ脆弱性に対する、一意で共通の識別子と定義している。歴史的には、CVE識別子は当初「候補」（「CAN-」）というステータスを持ち、その後エントリ（「CVE-」）に昇格させることができたが、この慣行は2005年に終了し^[6][7]、現在ではすべての識別子がCVEとして割り当てられている。CVE番号の割り当ては、それが公式のCVEエントリになることを保証するものではない（例えば、セキュリティ脆弱性ではない問題に誤ってCVEが割り当てられたり、既存のエントリと重複したりする場合がある）。基準を満たしていないと判断された場合、MITREまたはCVE採番機関（CNA）は即座にそのエントリをREJECTED（拒否）ステータスに置くことができる。

CVEはCVE採番機関（CNA）によって割り当てられる^[8]。一部のベンダーは以前からCNAとして活動していたが、2005年2月1日までこの名称・指定方法は用いられていない^[9]。CVE番号の割り当てには主に4つの種類がある。

1. MITREコーポレーションが編集者および主要なCNAとして機能する
2. 様々なCNAが自社の製品にCVE番号を割り当てる（例：Microsoft、Oracle、HP、Red Hat）
3. CERT Coordination Centerのようなサードパーティのコーディネーターが、他のCNAがカバーしていない製品にCVE番号を割り当てる場合がある
4. あるケースでは、研究者にCNAの役割が付与されている^[10]

脆弱性または潜在的な脆弱性を調査する際、早期にCVE番号を取得することは役立つ。公開が差し止められている問題（CVE番号は割り当てられているが、問題が公にされていない）、またはリソースの問題によりMITREによって調査や記述が行われていないエントリの場合、CVE番号がMITREやNVDのデータベースにしばらく（数日、数週間、数ヶ月、場合によっては数年）表示されないことがある。早期にCVE候補となる利点は、将来のすべての連絡および調整においてCVE番号を参照することで、すべての関係者が同じ脆弱性について言及していることを確実にできる点である。

オープンソースプロジェクトの問題に対するCVE識別子の取得に関する情報は、Red Hat^[11]およびGitHubから入手できる^[12]。

CVEは一般に公開されたソフトウェアを対象としている。これには、広く使用されていればベータ版やその他のプレリリース版も含まれる。商用ソフトウェアも「一般に公開された」カテゴリに含まれるが、配布されないカスタムビルドのソフトウェアには歴史的にCVEが付与されていなかった。プログラムの最初の20年間は、基礎となるソフトウェア製品が一般に配布されていない限り、サービス（例：Webベースのメールプロバイダー）で発見された脆弱性（例：クロスサイトスクリプティング）に対してCVEが割り当てられることはなかった。この変更に関する公式の規則は発表されていないが、MITREを含む一部のCNAは、2000年に遡ってサービスベースの脆弱性にCVEを割り当て始めている^[13]。

CVEデータベースにはいくつかのフィールドが含まれている。

これは問題の標準化されたテキストによる説明である。一般的なエントリの1つは次の通りである。

RESERVED この候補は、新しいセキュリティ問題を発表する際に使用する組織または個人によって予約されている。候補が公表されると、この候補の詳細が提供される。

これは、エントリ番号が問題のためにMITREによって予約されているか、CNAが番号を予約していることを意味する。したがって、CNAが事前にCVE番号のブロックを要求した場合（例：Red Hatは現在500単位のブロックでCVEを要求している）、CNA自身がしばらくCVEを割り当てていなくても、CVE番号は予約済みとしてマークされる。CVEが割り当てられ、MITREがそれを認識し（つまり、差し止め期間が過ぎて問題が公開され）、MITREが問題を調査して説明を記述するまで、エントリは「RESERVED」として表示される。

これはエントリが作成された日付である。MITREが直接割り当てたCVEの場合、これはMITREがCVEエントリを作成した日付である。CNA（例：Microsoft、Oracle、HP、Red Hat）によって割り当てられたCVEの場合も、これはCNAではなくMITREによって作成された日付となる。CNAが事前にCVE番号のブロックを要求した場合（例：Red Hatは現在500のブロックでCVEを要求している）、そのCVEがCNAに割り当てられたエントリ日となる。

以下のフィールドは以前CVEレコードで使用されていたが、現在は使用されていない。

• フェーズ：CVEが現在あるフェーズ（例：CAN、CVE）。
• 投票：以前は、CANを受け入れてCVEにするかどうかについて、ボードメンバーが賛成または反対の投票を行っていた。
• コメント：問題に対するコメント。
• 提案日：問題が最初に提案された日時。

CVE-YEAR-9999を超えるCVE IDをサポートするため（「CVE10k問題」として知られる問題^[14]）、2014年にCVE構文に変更が加えられ、2015年1月13日に発効した^[15]。

新しいCVE-ID構文は可変長であり、以下のとおり。

CVEプレフィックス + 年 + 任意の数字

可変長の任意の数字は固定の4桁から始まり、暦年内に必要な場合にのみ任意の数字で拡張される。例えば、CVE-YYYY-NNNN、必要に応じてCVE-YYYY-NNNNN、CVE-YYYY-NNNNNNといった具合である。このスキーマは以前に割り当てられたすべてのCVE-IDと互換性があり、それらもすべて最低4桁を含んでいる。

CVE データベースを検索するには Mitre 管轄のCVE一覧検索（CVE List Search）に問い合わせ、NVD CVE の場合はCVEおよびCCE脆弱性データベース（CVE and CCE Vulnerability Database）に検索をかける。

脆弱性の識別に利用することが CVE 識別子の趣旨である。

共通脆弱性識別子（CVE＝Common Vulnerabilities and Exposures）は、公開済みの情報セキュリティ脆弱性共通名称（CVE識別子）をまとめた辞書と位置付けられ、その識別子を使って複数のネットワークセキュリティ・データベースやツール間のデータ共有が容易になること、また組織のセキュリティツールの適用範囲を評価する基準も用意される点が特徴である。CVE識別子がセキュリティツールのレポートに含まれる場合、問題解決にあたって1件以上のCVE互換データベースから迅速かつ正確に修正情報を取得できる^[16]。

脆弱性に関する CVE 識別子の割り当てを受けた利用者は、その識別子を必ず関連するセキュリティ報告書や Web ページ、電子メールなどに記載するよう推奨される。

CNAルールの第7項によれば、セキュリティ脆弱性についての報告を受けたベンダーは、それに関して完全な裁量権を有している^[17]。これにより、ベンダーがそもそもCVE割り当てを拒否することで欠陥にパッチを当てないまま放置しようとする可能性があり、利益相反につながる恐れがある。なお、MITREはこの決定を覆すことはできない。2023年に発表された「!CVE」（not CVE）プロジェクトは、プロジェクトの専門家パネルによって有効と見なされる限り、ベンダーによって拒否された脆弱性を収集することを目的としている^[18]。

また、セキュリティ上の影響がない虚偽の問題や問題に対してCVE識別子が授与された事例も存在する^[19]。これに対応して、いくつかのオープンソースプロジェクトは、自らのプロジェクトのCVE採番機関（CNA）になるよう自ら申請を行っている^[20]。

2025年4月15日、MITREと米合衆国政府が取り交わした契約は翌日に期限切れを迎えると報じられた^[21]。報道によると契約満了に伴い、（新規CVEの割り当てを含む）CVEプログラムの運用業務は終了するが、データベースはGitHub経由で引き続きアクセス可能とのこと^[22]。

しかし、失効の直前に契約が11ヶ月延長され、プログラムのシャットダウンは回避された^[23]。現在の契約は2026年3月16日に満了する予定である。