CVEの基礎と公開の流れ

公開日：2026年8月23日

概要

ソフトウェアの脆弱性はCVE-2026-12345といった番号で報告されてますが、この番号は誰が発行し、どこで管理され、脆弱性が発見されてからどのような流れで公開されるのか整理します。

本記事では、CVEの基本と、その運営に関わるCVEプログラム、CISA、MITRE、CNAの関係を記載します。

CVEについて

CVEは脆弱性を識別するための共通番号を表し、「Common Vulnerabilities and Exposures」の略称です。

公開された脆弱性に世界共通の識別番号を付け、ベンダー、研究者、セキュリティ製品などが同じ脆弱性をやりとりするための仕組みとなります。

例えば、次のような形式で表します。

CVE-2026-12345

CVE：CVE識別子
2026：CVE IDが割り当てられた年
12345：そのCVEを識別する番号

CVEは脆弱性そのものでも、危険度の評価でもありません。脆弱性に付けられた「共通の管理番号」と考えるのが適切です。

公開されたCVEは、CVE.orgとGitHub上の公式CVE Listから確認できます。

CVEプログラムについて

CVEプログラムは、公開された脆弱性を識別・定義し、カタログ化するための国際的な運営制度です。

単一のWebサイトやデータベースだけを指すのではなく、次の要素を含む仕組み全体を意味します。

CVE IDの割り当てルール
CVE Recordのデータ形式
CVE IDを割り当てる組織の認定制度
CVE IDの予約・公開を処理するCVE Services
公開されたCVE Recordを収録するCVE List
重複や誤登録を修正するための手続き

CVEプログラムの目的は、脆弱性の危険度を判定することではなく、異なる組織やツールが同じ脆弱性を同じ番号で参照できるようにすることです。

CVE運営組織

CVEを運営する組織にはCISA、MITRE、CNAというのがあります。
それぞれの位置付けは次のとおりです。

CISA

CISA（Cybersecurity and Infrastructure Security Agency）は、米国国土安全保障省に属するサイバーセキュリティ機関です。CVEプログラムを政府側から支え、現在はその持続性や発展を主導する立場にあります。

CISAはCVE以外にも、実際の攻撃で悪用された脆弱性を収録するKEV（Known Exploited Vulnerabilities）カタログを公開しています。

MITRE

MITREは米国の非営利組織で、CVEを長年運営してきており、CVEの運営実務や仕組みの整備を担うとともに、現在も上位のCNAとして活動しています。

また、適切な担当CNAが存在しない脆弱性を扱う「CNA of Last Resort」という役割も担ってます。

CNA

CNA（CVE Numbering Authority）は、CVEプログラムからCVE IDの割り当てとCVE Recordの公開を認められた組織です。

Microsoft、Google、Red Hatなどの製品ベンダーだけでなく、脆弱性調整機関、セキュリティ研究組織、OSSコミュニティなどもCNAに認定されています。それぞれのCNAには担当範囲があり、原則としてその範囲内の脆弱性だけを扱います。

つまり、CVEプログラムという制度の中で、CISAが政府側から支援・主導し、MITREなどが上位管理や運営を担い、各CNAが実際のCVE IDの割り当てと情報公開を行う、という関係です。

名称	組織	役割
CISA	米国政府のサイバーセキュリティ機関	CVEプログラムの持続性と発展を支援・主導し、KEVカタログも公開する
MITRE	非営利組織、上位CNA	CVEの運営実務や仕組みを整備し、CNA of Last Resortとしても活動する
CNA	CVEプログラムから認定された組織	担当範囲内の脆弱性にCVE IDを割り当て、CVE Recordを公開する

CVE番号管理方法

MicrosoftやRed Hatなどが、自社で自由に通し番号を生成しているわけではなく、認定されたCNAが中央の管理システムであるCVE Servicesを使用し、CVE IDを予約します。

CVE IDを中央で予約するため、複数のCNAが同じ番号を発行することを防げます。また、同じ脆弱性に複数の番号が割り当てられないように、CNAは既存のCVEとの重複も確認します。

CVE Recordには主に次の状態があります。

RESERVED：CVE IDは予約済みだが、脆弱性の詳細はまだ公開されていない
PUBLISHED：説明や参照情報を含むCVE Recordが公開されている
REJECTED：重複、誤登録、取り下げなどにより、そのCVE IDを使用しない

REJECTEDになった番号は、無かったことにして別の脆弱性へ再利用するのではなく、無効な番号であることが分かるよう記録が残されます。

一般発見者の報告先

CVE Servicesは、主に認定されたCNAが利用する管理システムなので、一般の研究者や利用者が直接CVE Servicesを操作してCVE IDを発行できません。

脆弱性を発見した場合は、原則として次の順番で報告先を探します。

対象製品のベンダーや開発元
その製品を担当範囲とするCNA
調整機関や適切なCNA of Last Resort

製品担当となるCNAはCNA一覧から探せます。例えば、Microsoft製品ならMicrosoft、Red Hat製品ならRed Hatが報告先の候補になります。日本国内では、ケースによってJPCERT/CCが脆弱性情報の調整に関わることもあります。

報告時には、脆弱性をいきなり一般公開せず、ベンダーのセキュリティ窓口などへ非公開で連絡するのが一般的です。修正版がない状態で詳細を公開すると、利用者が対策できないまま攻撃方法だけが広まる可能性があるためです。

CVE公開フロー

脆弱性が発見されてからCVEが公開されるまでの流れは次のようになってます。
重要なのは、CVE IDの予約と、CVE Recordの公開は別の処理だという点です。CVE IDは修正準備中に先に確保され、詳細は修正版の提供に合わせて後から公開されることがあります。

ベンダーまたはCNAへ報告
- 再現手順、影響する製品とバージョン、想定される被害、検証結果などを非公開で提出する
ベンダーやCNAは、報告内容を再現し、次のような点を確認
- 本当にセキュリティ上の脆弱性なのか
- 影響する製品とバージョンは何か
- 既存のCVEと重複していないか
- 自組織の担当範囲に含まれるか
- CVE IDを割り当てる条件を満たすか
CVE IDを予約
- CNAがCVE Servicesを通じてCVE IDを確保する
- この段階ではRESERVEDとなっており、番号だけが先に存在して詳細が公開されていない場合がある
修正と公開準備
- ベンダーは、修正パッチ、修正版、回避策、セキュリティアドバイザリなどを準備する
- 発見者とベンダーが公開日を調整することもあり
脆弱性と修正情報を公表
- ベンダーが修正版やアドバイザリを公開する
- CVE Recordを公開するには、通常、脆弱性を説明する公開情報への参照が必要となる
CVE Recordを公開
- CNAが対象製品、影響するバージョン、脆弱性の説明、参照URLなどを登録する
- 必要な情報が公開されると、状態はPUBLISHEDになる

対応優先度の判断

CVEは共通識別子であり、危険度や対応優先度そのものを示しません。実際の脆弱性管理では、ほかの情報と組み合わせて判断します。

CVSS：脆弱性の技術的な深刻度
CISA KEV：実際の攻撃で悪用されたことが確認されているか
EPSS：近い将来に悪用される可能性の予測値
修正版の有無：アップデートによる対応が可能か
利用状況：脆弱な機能やパッケージを実際に使用しているか
公開状況：インターネットから攻撃可能な状態か
環境固有の影響：設定や権限によって攻撃条件を満たすか

また、同じCVEでも、CNA、NVD、OSベンダーなどで評価が異なることがあり、Linuxディストリビューションが修正をバックポートしている場合は、単純なバージョン比較だけでは誤判定する可能性もあります。

まとめ

CVEは、公開された脆弱性を世界共通の番号で識別するための仕組みです。各製品ベンダーが独自に番号を発行するのではなく、CVEプログラムに認定されたCNAが、CVE Servicesを通じて番号を予約し、CVE Recordを公開します。

一方で、CVEの有無やCVSSの値だけでは、実際の対応優先度は決まりません。脆弱性が実際に悪用されているか、修正版があるか、自分の環境で対象機能を使用しているか、外部から到達可能かといった情報まで含めて判断する必要があります。

脆弱性管理では、「どのCVEが存在するか」を把握することが出発点です。そのうえで、「自分の環境に影響するか」「今すぐ対応すべきか」まで絞り込むことが重要になります。