共通脆弱性識別子
(Common_Vulnerabilities_and_Exposures から転送)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/02/26 08:07 UTC 版)
共通脆弱性識別子（きょうつうぜいじゃくせいしきべつし、英語: Common Vulnerabilities and Exposures、略称:CVE）は一般に公開済みの情報セキュリティの脆弱性や暴露について問い合わせる方法を提供するシステムである[1][2]。正式に一般公開されたのは1999年9月であった[3]。
アメリカ合衆国の国土安全保障システム工学開発研究所（Homeland Security Systems Engineering and Development Institute、略号FFRDC）を統括するMITREコーポレーションは合衆国政府国土安全保障省配下の国家サイバーセキュリティ部門から資金援助を受けて業務を行う[4] 。
旧称は同じ頭字語で「Common Vulnerability Enumeration」を当てていた[2]。
コンテンツセキュリティ自動化プロトコル（Security Content Automation Protocol）はCVEを採用、MITREシステムも、また合衆国が施行する国家脆弱性データベースもその根幹にCVE識別子を採用する[5]。
CVE識別子
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つの種類がある。
- MITREコーポレーションが編集者および主要なCNAとして機能する
- 様々なCNAが自社の製品にCVE番号を割り当てる（例：Microsoft、Oracle、HP、Red Hat）
- CERT Coordination Centerのようなサードパーティのコーディネーターが、他のCNAがカバーしていない製品にCVE番号を割り当てる場合がある
- あるケースでは、研究者に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のデータフィールド
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識別子の検索
CVE データベースを検索するには Mitre 管轄のCVE一覧検索（CVE List Search）に問い合わせ、NVD CVE の場合はCVEおよびCCE脆弱性データベース（CVE and CCE Vulnerability Database）に検索をかける。
CVE 活用
脆弱性の識別に利用することが CVE 識別子の趣旨である。
共通脆弱性識別子（CVE＝Common Vulnerabilities and Exposures）は、公開済みの情報セキュリティ脆弱性共通名称（CVE識別子）をまとめた辞書と位置付けられ、その識別子を使って複数のネットワークセキュリティ・データベースやツール間のデータ共有が容易になること、また組織のセキュリティツールの適用範囲を評価する基準も用意される点が特徴である。CVE識別子がセキュリティツールのレポートに含まれる場合、問題解決にあたって1件以上のCVE互換データベースから迅速かつ正確に修正情報を取得できる[16]。
脆弱性に関する CVE 識別子の割り当てを受けた利用者は、その識別子を必ず関連するセキュリティ報告書や Web ページ、電子メールなどに記載するよう推奨される。
CVE割り当ての問題
CNAルールの第7項によれば、セキュリティ脆弱性についての報告を受けたベンダーは、それに関して完全な裁量権を有している[17]。これにより、ベンダーがそもそもCVE割り当てを拒否することで欠陥にパッチを当てないまま放置しようとする可能性があり、利益相反につながる恐れがある。なお、MITREはこの決定を覆すことはできない。2023年に発表された「!CVE」（not CVE）プロジェクトは、プロジェクトの専門家パネルによって有効と見なされる限り、ベンダーによって拒否された脆弱性を収集することを目的としている[18]。
また、セキュリティ上の影響がない虚偽の問題や問題に対してCVE識別子が授与された事例も存在する[19]。これに対応して、いくつかのオープンソースプロジェクトは、自らのプロジェクトのCVE採番機関（CNA）になるよう自ら申請を行っている[20]。
2025年の資金問題
2025年4月15日、MITREと米合衆国政府が取り交わした契約は翌日に期限切れを迎えると報じられた[21]。報道によると契約満了に伴い、（新規CVEの割り当てを含む）CVEプログラムの運用業務は終了するが、データベースはGitHub経由で引き続きアクセス可能とのこと[22]。
しかし、失効の直前に契約が11ヶ月延長され、プログラムのシャットダウンは回避された[23]。現在の契約は2026年3月16日に満了する予定である。
脚注
- ^ Wu, Xiaoxue; Zheng, Wei; Chen, Xiang; Wang, Fang; Mu, Dejun (2020). “CVE-assisted large-scale security bug report dataset construction method” (英語). Journal of Systems and Software 160. doi:10.1016/j.jss.2019.110456 2022年10月24日閲覧。.
- ^ a b “CVE - Towards a Common Enumeration of Vulnerabilities” (2025年4月18日). 2025年4月18日時点のオリジナルよりアーカイブ。2025年4月29日閲覧。
- ^ “CVE - History”. cve.mitre.org. オリジナルの2020年1月8日時点におけるアーカイブ。 2020年3月25日閲覧。
- ^ “CVE – Common Vulnerabilities and Exposures”. Mitre Corporation (2007年7月3日). 2020年12月19日時点のオリジナルよりアーカイブ。2009年6月18日閲覧。 “CVE is sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security.”
- ^ “CVE - Common Vulnerabilities and Exposures (CVE)”. cve.mitre.org. 2013年4月7日時点のオリジナルよりアーカイブ。2013年4月8日閲覧。
- ^ “CVE - Frequently Asked Questions”. cve.mitre.org. 2018年4月10日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。
- ^ Kouns, Jake (2009年8月13日). “Reviewing(4) CVE”. OSVDB: Everything is Vulnerable. 2021年9月1日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。
- ^ “CVE - CVE Numbering Authorities”. MITRE Corporation (2015年2月1日). 2026年2月26日閲覧。
- ^ “CVE - CVE Blog "Our CVE Story: Ancient History of the CVE Program – Did the Microsoft Security Response Center have Precognition?" (guest author)”. cve.mitre.org. 2026年2月26日閲覧。
- ^ “CVE - CVE Blog "My CVE Story: How I Became the CVE Program's First Vulnerability Researcher CNA" (guest author)” (2021年3月15日). 2021年3月15日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。
- ^ “CVE OpenSource Request HOWTO”. Red Hat Inc. (2016年11月14日). 2026年2月26日閲覧。 “There are several ways to make a request depending on what your requirements are:”
- ^ “About GitHub Security Advisories”. GitHub. 2021年12月23日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。 “GitHub Security Advisories builds upon the foundation of the Common Vulnerabilities and Exposures (CVE) list”
- ^ “CVE - CVE-2000-0081” (2021年12月4日). 2021年12月4日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。
- ^ Christey, Steven M. (2007年1月12日). “CVE - The CVE-10K Problem”. The MITRE Corporation. 2026年2月26日閲覧。
- ^ “CVE - CVE ID Syntax Change”. cve.mitre.org (2016年9月13日). 2026年2月26日閲覧。
- ^ “CVE - About CVE”. cve.mitre.org. 2015年7月28日閲覧。
- ^ CVE Numbering Authority Rules - Assignment Rules (PDF) (Report). The MITRE Corporation. 1 February 2020. pp. 13–15. 2023年12月7日時点のオリジナル (PDF)よりアーカイブ. 2026年2月26日閲覧.
- ^ Edge, Jake (2023年12月5日). “Supplementing CVEs with !CVEs”. lwn.net. 2024年2月21日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。
- ^ Edge, Jake (2023年9月13日). “The bogus CVE problem”. lwn.net. 2026年2月26日閲覧。
- ^ “A turning point for CVE numbers”. LWN.net (2024年2月14日). 2024年2月22日時点のオリジナルよりアーカイブ。2026年2月26日閲覧。
- ^ “CONTRACT to THE MITRE CORPORATION” (英語). www.usaspending.gov. 2025年4月16日時点のオリジナルよりアーカイブ。2025年4月16日閲覧。
- ^ Bradley. “Cybersecurity World On Edge As CVE Program Prepares To Go Dark” (英語). Forbes. 2025年7月17日時点のオリジナルよりアーカイブ。2025年4月16日閲覧。
- ^ Brunfield, Cynthia (2025年4月16日). “CVE program averts swift end after CISA executes 11-month contract extension”. CSO Online (IDG Communications). オリジナルの2025年4月15日時点におけるアーカイブ。 2026年2月26日閲覧。
関連項目
- 共通脆弱性評価システム（CVSS）
- 共通脆弱性タイプ一覧（CWE）
- 共通攻撃パターン一覧（CAPEC）
- アプリケーションセキュリティ静的試験
- 欧州連合脆弱性データベース：European Union Vulnerability Database
- コンピュータセキュリティ
- ソフトウェア構成分析Software composition analysis
外部リンク
- 全米脆弱性データベース（NVD）- National Vulnerability Database
- Common Configuration Enumeration (CCE) NVD配下
- アイ・ビー・ティ「産学連携ソフトウェア工学実践事業」報告書（クラウド・コンピューティング時代のDependabilityの考え方などに関する米国の動向調査）『平成21年度産業技術研究開発委託費』（経済産業省、2010年2月)（経済産業省委託調査報告書）
- vFeed- SQLite データベースと Python API の話題 - 相関および集約された脆弱性データベース
- Cyberwatch Vulnerabilities Database Archived 2018-08-22 at the Wayback Machine. サードパーティまとめ
- 企業は IT セキュリティ監査サービスについて何を知っておくべき？
Common Vulnerabilities and Exposures (CVE)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/27 05:53 UTC 版)
「脆弱性情報データベース」の記事における「Common Vulnerabilities and Exposures (CVE)」の解説
MITRE社が1999年に前述の「セキュリティ脆弱性のデータベースについての研究ワークショップ」で提案し、実現化させた脆弱性情報データベースである。他の脆弱性情報データベースと異なり、内容がベンダ依存でない（業界標準名が用いられている）ことが利点として挙げられる。なお、MITRE社はCVEをデータベースではなく辞書だとしている。その真意は、CVEの目的は「識別可能性の確保＝個々の脆弱性に固有のCVE番号を割り当て、CVE番号によって脆弱性を識別可能とすること」と「命名＝個々の脆弱性に（業界標準的な）名前を付けること」であり、詳細情報は外部サイトや他の脆弱性データベースに任せるというものである。 CVEへの報告はCVE Editorial Boardによって行なわれるが、報告は「過去にCVE Editorial Boardへの報告を行なったことがあるもの」であるか、「過去にCVE Editorial Boardへの報告を行なったことがあるものによる仲介」を必要とする。報告が行なわれると、その情報にはCAN番号（CAN-西暦年-4桁以上の通番）という番号が割り当てられる。その後、報告された脆弱性情報のCVE Editorial Boardによる評価が終わった後、CVE番号（CVE-西暦年-4桁以上の通番）となる。評価の結果、複数のCAN番号が同一の脆弱性を示しているなら同じCVE番号が割り当てられることとなり、逆に、1つのCAN番号に複数の脆弱性が盛り込まれている場合は複数のCVE番号が割り当てられることとなる。 なお、2013年までのCVE番号は、「CVE-西暦年-4桁通番」の形式で振られていたが、報告される脆弱性が増加し、年間で1万件を超えて4桁では足りなくなることが確実となったことから、2014年1月1日からは、通番部分が4桁以上と改定された。 「Common Vulnerabilities and Exposures」も参照
※この「Common Vulnerabilities and Exposures (CVE)」の解説は、「脆弱性情報データベース」の解説の一部です。
「Common Vulnerabilities and Exposures (CVE)」を含む「脆弱性情報データベース」の記事については、「脆弱性情報データベース」の概要を参照ください。
- Common_Vulnerabilities_and_Exposuresのページへのリンク
