【セキュリティ】CVEって結局何なのかを整理してみる

はじめに

対象読者: コンテナのスキャン結果に並ぶ CVE-XXXX-XXXXX を、なんとなく眺めているエンジニア

AWSのECRの基本スキャンでCVE-XXXXが出てきたことが発端で詳しく調べてみました。

参考文献

この記事は、以下の一次情報を読んで整理したものです。

条文の番号は、執筆時点（2026年9月）で最新の CNA Operational Rules 4.2.0（2026年8月25日施行）で確認しています。4.2.0 では設定や悪意あるコードに関する条文の番号がずれたため、それ以前の解説記事とは番号が合わないことがあります。

CVE は脆弱性1件ごとの背番号

CVE は Common Vulnerabilities and Exposures の略です。形式はこうなっています。

年の部分は、脆弱性が最初に公開された年、CVE レコードが最初に公開された年、ID を予約した年のいずれかが入ります（4.2.19）。発見された年とは限りません。通し番号は4桁から19桁で（CVE レコードの形式で決まっている）、番号が大きいから危ないということもありません。

この番号の価値は、全員が同じ名前で呼べることにあります。ニュースでは「Log4Shell」と呼ばれた Apache Log4j の脆弱性も、ベンダーの告知・スキャナーの検出結果・社内のチケットでは CVE-2021-44228 で揃います。名前が揃っていれば、「うちの環境にあの穴はあるか」を機械的に突き合わせられるわけです。

実際の CVE レコードは cve.org で見られます。

上部に「CNA: Apache Software Foundation」とあるのがポイントで、この番号を振ったのは MITRE ではなく Apache 自身です。この話は次の節で触れます。

ここで一度、よく混ざる CVSS との違いを表にしておきます。

	CVE	CVSS
表すもの	どの脆弱性か（ID）	どれくらい危ないか（スコア）
形式	CVE-年-通し番号	0.0〜10.0。v3.x と v4.0 では 9.0 以上が Critical
管理している主体	CVE プログラム（運用は MITRE、ルールは CVE Board が承認）	FIRST

同じ Log4Shell を NVD で開くと、CVSS のスコアが並んでいます。

CVE の番号そのものには深刻度の情報が一切入っていません。深刻度を知りたいなら CVSS を見ます。ただし CVSS の基本値は脆弱性そのものの深刻度で、自分の環境での危なさではありません。対応の順番は、実際に悪用されているか、その部品が外から触れる場所にあるか、なども合わせて決めることになります。

番号を振っているのは誰か

登場人物は3つです。

役割	担当
プログラムの運営	MITRE（米国の非営利団体）。資金は米国の CISA が出している
番号を振る	CNA（CVE Numbering Authority）。Microsoft・Google・Red Hat・Apache など、多くは自社製品の番号を自分で振るベンダー
情報を足す	NVD（NIST のデータベース）。CVSS スコアや影響を受ける製品の情報を付ける

自分は最初、MITRE が全部の番号を振っていると思っていました。実際は「このベンダーはこの範囲の製品なら番号を振ってよい」と認定された CNA が、それぞれ番号を振っています。さっきの Log4Shell の画面に Apache の名前が出ていたのはこのためです。

ちなみに、この仕組みは2025年4月に一度止まりかけています。MITRE と CISA の契約が切れる直前に、CISA が11か月の延長を決めました。2026年1月には CVE Board に「3月に資金が途切れることはない」と伝えられています。世界中が使う番号が、1つの国の1本の契約で回っているのは、改めて考えると結構すごい構造です。

CVE が発行されるもの

OS やライブラリだけではありません。公開されているソフトウェアやハードウェアの脆弱性であれば、種類を問わず番号が付きます。

分類	例
OS	Linux カーネル、Windows、macOS、iOS
OS のパッケージ	openssl、glibc、bash
言語のライブラリ	Log4j（Java）、requests（Python）、npm のパッケージ
アプリ・ミドルウェア	Chrome、Office、Apache HTTP Server、nginx、PostgreSQL
ネットワーク機器・ファームウェア・CPU	ルーター、VPN 装置、CPU（Spectre など）
クラウドサービス・AI	2024年のルール改定で、技術の種類だけを理由に断れなくなった

では、何を基準に番号を振るのか。CNA Operational Rules の条文を自分なりに簡略化すると、4段の目安になりました。

これは必要十分条件ではありません。条文の多くは「すべき（SHOULD）」「してよい（MAY）」で書かれていて、最終的には各 CNA が自分の担当範囲の中で判断します。それでも、スキャン結果を読む側が「これに番号が付くか」を考える目安としては十分使えます。

一番大事なのは最後の段で、条文（4.2.2.2）では次のどちらかに当てはまれば、公開して番号を振るべきとされています。

1. 大きな被害を生む可能性がある
2. CNA やその製品の提供元以外の誰かが、対応やリスクの判断をしないといけない

2つ目が CVE の本質だと自分は受け取りました。アップデートを当てる人や「うちは影響あるのか」を判断する人がよそにいるから、共通の番号で知らせる意味が出てきます。

2024年からクラウドと AI も対象になった

2024年8月に施行された CNA Operational Rules 4.0 で、クラウドの扱いが大きく変わりました。

旧ルール（3.0）には、利用者が管理しないサービス——つまりクラウドサービス——に関する制限がありました。サービスを持っている CNA 自身は、利用者側の対応が必要なときに限って番号を振れました。一方で、サービスを持っていない第三者の CNA が番号を振ることは禁止されていました。研究者がよその SaaS の穴を見つけても、第三者の CNA からは CVE を取れなかったわけです。

4.0 ではこの制限が削除され、代わりに次の条文（4.2.3）が入りました。

CNAs MUST NOT consider the type of technology (e.g., cloud, on-premises, artificial intelligence, machine learning) as the sole basis for determining assignment.

「クラウドだから」「AI だから」だけを理由に番号を断ってはいけない、という意味です。

ただし、クラウドの脆弱性に必ず番号が付くようになったわけではありません。クラウドの穴は事業者が裏側で直せば利用者は何もしなくてよいことが多く、その場合はさっきの「よその誰かが対応するか」が「いいえ」になりやすい。種類で門前払いされなくなっただけで、判断の基準はほかの製品と同じです。

CVE が発行されないもの

逆に、番号が付かないものも整理しておきます。

対象	理由	代わりに見る仕組み
社内だけで使っている自作のコード	脆弱性が公開されない。直すのも使うのも自分たちだけなので、共通の番号が要らない	SAST などのコードスキャン
利用者の設定ミス（S3 を自分で公開にした、など）	十分に文書化された設定を、利用者が自分の判断で変えた結果は脆弱性と見なさない（4.1.3.5）	AWS なら Security Hub や Config
脆弱性の「種類」（SQL インジェクションそのもの、など）	CVE は「この製品のこの版のこの穴」という1件ごとの番号	CWE という分類
最初から悪意のあるパッケージ	汎用の悪意あるコードは脆弱性と見なしてはならない（4.1.7）	OSV の MAL- ID、GitHub Advisory Database のマルウェア勧告

1行目は「自作だから」付かないのではありません。自作のコードでも、OSS として公開したり製品として配ったりすれば、使う人がよそにいるので CVE の対象になります。付かないのは、社内に閉じていて脆弱性が公開されず、直す人も自分たちしかいないからです。

この表、私は最初もう少し雑に書いていました。「設定ミスには付かない」「マルウェアには付かない」と一括りにしていたのですが、条文を読むとどちらにも例外があります（実際に踏みました）。

• 設定は、製品の初期設定が危ない場合は脆弱性と見なすべきとされています（4.1.3）。「利用者が変えた設定」は対象外でも、「最初からそうなっていた設定」は対象になります
• 悪意のあるコードも、正規の製品が乗っ取られて悪意を仕込まれた場合は、脆弱性と見なしてよいとされています（4.1.8）。2024年に見つかった xz utils のバックドアには CVE-2024-3094 が付いています

ついでに言うと、この条文番号も一度間違えました。最初は 4.1.0 の PDF を読んでメモしていたのですが、2026年8月に 4.2.0 が施行されていて、設定と悪意あるコードの条文の番号がずれていました。ルールの条文を引くときは、版の日付まで確かめたほうがいいです。

線を引くなら、「最初から悪意の塊として作られたもの」には付かず、「みんなが使っている正規の部品に仕込まれたもの」には付きうる、です。npm の偽パッケージ（名前を似せたタイポスクワッティングなど）は前者なので、CVE ではなく MAL- の ID で管理されます。

CVE・CWE・GHSA・MAL- は何が違うのか

スキャン結果や GitHub の Dependabot を見ていると、似た ID がいくつも出てきます。自分が混乱したので1つの表にまとめました。

ID	表すもの	例	管理しているところ
CVE	製品の脆弱性1件	CVE-2021-44228	CVE プログラム（MITRE・各 CNA）
CWE	脆弱性の種類	CWE-89（SQL インジェクション）	MITRE
CVSS	深刻度のスコア	10.0 CRITICAL	FIRST（仕様）
GHSA	GitHub Advisory Database の勧告 ID。CVE があれば紐づく	GHSA-xxxx-xxxx-xxxx	GitHub
MAL-	OSV 形式の悪意あるパッケージの ID	MAL-年-通し番号	OpenSSF の malicious-packages

CVE と CWE の関係は、「この店のこの日のこの食中毒」と「食中毒の種類」の違いに近いです。1件の CVE には、当てはまる弱点の分類として CWE が紐づきます。複数付くこともあれば、分類しきれずに付かないこともあります。

コンテナイメージのどこまでが CVE で見えるのか

ここまでを ECR のスキャンに当てはめると、見える範囲がはっきりします。

スキャン	見る範囲	タイミング
ECR 基本スキャン	OS のパッケージの CVE	プッシュ時か手動
ECR 拡張スキャン（Amazon Inspector）	OS のパッケージ＋言語のライブラリの脆弱性。既知の悪意あるパッケージ（npm・PyPI）も MAL- ID で検出する	プッシュ時か継続的。新しい脆弱性情報が出ると既存のイメージも再評価する

まとめ

CVE は「みんなが使っている部品の、既に知られている欠陥」に振る番号です。製品の種類は問われず、クラウドや AI も対象になりました。その代わり、社内だけで使うコードや、自分で変えた設定のミスは、この一覧の外にあります。

調べてみて一番効いたのは、スキャン結果の見え方が変わったことでした。0件は安全の証明ではなく、「既知の部品の穴は入っていない」という限定つきの情報です。自作コードは SAST、設定は Security Hub や Config、実行時の挙動は GuardDuty と、見る道具を分けて考えるようになりました。

次は、NVD の画面に出ていた CVSS のベクトル文字列（AV:N/AC:L/...）の読み方を書くつもりです。みなさんのチームでは、スキャン結果の CVE をどこまで追っていますか？ 運用の工夫があれば、コメントで教えてもらえるとうれしいです。