Overview
CVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）とは、公開されたソフトウェアやハードウェアのセキュリティ脆弱性に対して一意の識別番号を付与する国際的な標準規格です。MITRE社が管理・運営しており、「CVE-年号-連番」という形式（例：CVE-2024-12345）で各脆弱性を一意に識別します。セキュリティ業界全体で共通言語として機能しています。
CVEの最大の目的は、セキュリティ脆弱性に関する情報の共有と管理を標準化することです。CVE番号がなければ、同じ脆弱性に対して各ベンダーが異なる名前や識別子を使用し、情報の照合が困難になります。CVEにより、セキュリティ研究者、ベンダー、管理者が同じ脆弱性について正確にコミュニケーションを取ることが可能になります。
CVEはCNA（CVE Numbering Authority：CVE採番機関）と呼ばれる認定組織によって採番されます。Microsoft、Google、Red Hatなどの主要ベンダーはCNAとして認定されており、自社製品の脆弱性に対してCVE番号を直接発行できます。現在、世界中で400以上のCNAが活動しており、年間数万件のCVEが発行されています。
Details
CVE番号の構成と採番プロセス
CVE番号は「CVE-YYYY-NNNNN」の形式で構成されます。YYYYは脆弱性が報告または公開された年、NNNNNは連番（4桁以上の可変長）です。2014年以降は5桁以上の連番が使用可能になり、増加する脆弱性報告に対応しています。
採番プロセスは、脆弱性の発見者またはベンダーがCNAに報告することから始まります。CNAは脆弱性の妥当性を確認し、CVE番号を予約（Reserve）します。その後、脆弱性情報が公開される際にCVEレコードが正式に公開（Publish）されます。このプロセスにより、パッチ提供前に脆弱性情報が漏洩することを防ぎます。
NVD（National Vulnerability Database）との関係
NVD（米国国立脆弱性データベース）は、NIST（米国国立標準技術研究所）が運営するCVEの補完データベースです。CVEが脆弱性の識別と基本情報の提供に特化しているのに対し、NVDはCVSSスコア、影響を受ける製品情報（CPE）、修正パッチへのリンクなど、より詳細な分析情報を提供します。
NVDはCVEが公開された後に分析を追加するため、CVE公開からNVDへの反映にはタイムラグが生じます。近年、CVEの急増によりNVDの分析が追いつかず、未分析のCVEが蓄積する問題が顕在化しています。
CVEの状態遷移（ライフサイクル）
CVEレコードには複数の状態があります。Reserved（予約済み）はCVE番号が割り当てられたが詳細が未公開の状態、Published（公開済み）は脆弱性情報が正式に公開された状態、Rejected（却下）は脆弱性として認められなかったか重複と判断された状態です。
ReservedからPublishedへの移行には数日から数か月かかることがあり、この間は脆弱性の存在は知られていても詳細は非公開です。セキュリティチームは、Reserved状態のCVEについてもベンダーアドバイザリを確認し、早期の対応を検討する必要があります。
CVEの限界と課題
CVEシステムにはいくつかの課題があります。まず、すべての脆弱性にCVE番号が付与されるわけではなく、特にオープンソースソフトウェアや小規模プロジェクトの脆弱性は採番されないケースがあります。また、CVE番号の発行から詳細情報の公開までに時間差があり、その間の対応が困難です。
さらに、CVEは脆弱性の深刻度を直接示しません。深刻度の評価にはCVSS（共通脆弱性評価システム）が別途使用されます。CVEとCVSSを組み合わせて初めて、脆弱性の優先度判断が可能になります。近年はCVE件数の爆発的増加により、運用負荷の増大も深刻な課題となっています。
Security Measures
- 01CVE情報の継続的なモニタリング体制を構築：NVD、JVN（Japan Vulnerability Notes）、各ベンダーのセキュリティアドバイザリを定期的に監視し、自組織が使用するソフトウェアに関連するCVEを迅速に把握できる体制を整えましょう。自動化ツールの活用も有効です。
- 02ソフトウェア資産の可視化とSBOMの活用：自組織で使用しているソフトウェアとそのバージョンを正確に把握し、SBOM（ソフトウェア部品表）として管理することで、新しいCVEが公開された際に影響範囲を即座に特定できるようにしてください。
- 03CVSSスコアに基づく優先度判断：公開されたCVEに対してCVSSスコアを確認し、深刻度に応じた対応の優先順位を決定してください。ただし、CVSSスコアだけでなく、自組織の環境における実際の影響度や悪用可能性も考慮した総合的な判断が重要です。
- 04脆弱性対応のSLA（サービスレベル目標）を設定：CVSSスコアのレベルに応じて、パッチ適用までの目標期間を定めましょう。例えば、Critical（9.0以上）は48時間以内、High（7.0-8.9）は1週間以内など、具体的な基準を設けて対応速度を管理します。
- 05脆弱性スキャナーによる定期的な検査：脆弱性スキャナーを使用して、既知のCVEに対する自組織のシステムの影響を定期的に検査してください。スキャン結果とCVE情報を照合し、未対応の脆弱性を確実に管理します。
- 06CVE情報を活用したインシデント対応計画の策定：過去のCVEにおける攻撃手法や影響範囲を分析し、類似の脆弱性が発見された際の対応手順を事前に策定しておきましょう。特に、ゼロデイ脆弱性が公開された場合の緊急対応フローを整備することが重要です。
Incidents
📋 Apache Log4j（CVE-2021-44228 / Log4Shell）の世界的影響（2021年）
2021年12月、Javaのログライブラリ「Apache Log4j」に深刻なリモートコード実行の脆弱性（CVE-2021-44228）が公開されました。CVSSスコア10.0（最高値）と評価され、「Log4Shell」と呼ばれるこの脆弱性は、特別に細工された文字列をログに記録させるだけで任意のコードを実行できるものでした。
Log4jはJavaエコシステムで広く使用されており、Amazon、Apple、Cloudflare、Steamなど数百万のシステムに影響しました。公開直後から世界中で大規模な悪用が確認され、多くの組織が緊急パッチの適用に追われました。この事件は、ソフトウェアサプライチェーンにおけるCVE管理の重要性を世界に示しました。
📋 Microsoft Exchange Server脆弱性（ProxyLogon / CVE-2021-26855）（2021年）
2021年3月、Microsoft Exchange Serverに複数の重大な脆弱性が公開されました。中でもCVE-2021-26855（ProxyLogon）は、認証なしでExchange Serverにアクセスし、メールの窃取やWebシェルの設置が可能な深刻な脆弱性でした。中国の攻撃グループ「Hafnium」による悪用が確認されました。
この脆弱性は世界中で少なくとも25万台のExchange Serverに影響を与え、多数の政府機関や企業が被害を受けました。CVE公開後もパッチ未適用のサーバーが大量に残り、ランサムウェア攻撃にも悪用されました。迅速なCVE対応の重要性を示す典型的な事例です。
📋 MOVEit Transfer脆弱性（CVE-2023-34362）による大規模データ漏洩（2023年）
2023年5月、ファイル転送ソフトウェア「MOVEit Transfer」にSQLインジェクションの脆弱性（CVE-2023-34362）が発見されました。ランサムウェアグループ「Cl0p」がこの脆弱性をゼロデイ攻撃として悪用し、CVE公開前から大規模なデータ窃取を実行していました。
被害は2,700以上の組織、約9,500万人の個人情報に及びました。政府機関、金融機関、医療機関、教育機関など幅広い分野が影響を受け、史上最大規模のサプライチェーン攻撃の一つとなりました。この事件は、CVE公開前のゼロデイ攻撃への備えの重要性を改めて示しました。