NVDの見方：何を信じて、何を捨てるか
（CVEトリアージで迷わない読み順）
NVD（脆弱性データベース）を見ているのに、現場が楽にならない理由はシンプルです。
NVDには情報が多すぎて、「重要な根拠」と「ノイズ」が混ざっているからです。
- CVSSが高い → でも自社製品に関係ない
- CPEに載っている → でも実際は該当しない（表記ゆれ・版数範囲の罠）
- 参考リンクが山ほど → でも信頼できる一次情報が埋もれる
- 文章が強い → でも“成立条件”が自社環境では揃わない
この記事では、Tier2〜Tier4の兼務担当でも迷わないように、NVDの情報を 「信じる（根拠として使う）」／「捨てる（優先度判断に使わない）」 に分けて、読む順番（手順）としてまとめます。
結論：NVDは「辞書」であって「結論」ではない
最初に結論を置きます。NVDは「入口」です。自社のSBOM/部品表と結びついた瞬間に価値が出る、という前提で読みます。
NVDで信じるべきもの
- CVEの“同一性”を示す情報（ID、要約、参照リンク）
- CVSSベクトルの“条件”（AV/PR/UI など、成立条件を読む材料）
- 更新履歴（いつ何が変わったか）
- 一次情報への導線（ベンダー公告、パッチ情報、上流コミット等）
NVDで捨てるべきもの
※そのまま意思決定に使わない
- CVSSスコア“だけ”で優先度を決めること
- CPEに載っている＝該当、と即断すること
- 参考リンクの“量”で重要度を判断すること
- 説明文の強さ（表現が強い＝自社で危険、とは限らない）
まず見る場所はここ：NVDの“読む順番” 7ステップ
Step1：CVEの要約を読む（ただし“鵜呑み”にしない）
最初に「何が起きる脆弱性か」を把握します。ここでやるのは“理解”であって“結論”ではありません。
- 何ができてしまうのか（情報漏えい／改ざん／停止 等）
- どの機能・コンポーネントに関係しそうか（キーワード拾い）
要約の文章は一般化されており、成立条件が省略されがちです。“怖い文章”だけで社内を赤信号にしないこと。
Step2：更新日時を見る（Last Modifiedが新しい＝揺れている）
NVDは後から情報が足されます。更新が入っているものは、「まだ確定していない（変わりうる）」前提で扱うと事故が減ります。
- 初動は「一次回答（調査中＋次回更新日）」を使う
- 「最終回答」は、参照先（一次情報）が揃ってから固める
Step3：CVSSは“点数”ではなく“条件（ベクトル）”を読む
CVSSは「点数」だけを見ると破綻します。読むべきは、成立条件がどれだけ厳しいかです。見る順番はこれでOKです。
- AV (Attack Vector): 外から届くか（Network/Local/Physical）
- PR (Privileges Required): 高権限が必要か
- UI (User Interaction): ユーザー操作が必要か
- C/I/A: 何が壊れるか（機密性/完全性/可用性）
AV/PR/UIは、OEM説明の根拠にも使えます（例：「外部到達性が必要な脆弱性だが、当製品は閉域網のため影響なし」）。
「9点台＝即対応」の短絡。自社の接続形態・機能無効化・境界（閉域/ゲートウェイ）で優先度は変わります。
Step4：CPE（対象製品・版数）は“候補リスト”として扱う
CPEは便利ですが、ここが一番誤判定を生みます。
⚠️ よくある罠
- 同名製品でもエディション/ビルドが違う
- “製品”のCPEと“パッケージ”の名称が不一致
- 版数範囲が広めに付く／逆に抜けがある
- 自社SBOMの表記（OSS名）と一致しない
「該当しそうな候補を拾う」ための材料。
SBOM/部品表側に“当たりを付ける”用途。
CPEにあるから該当、と即断する。
CPEにないから非該当、と即断する。
Step5：References（参照リンク）は“質で選別”する
NVDの参照リンクは玉石混交です。優先して読む順番はこれです（上から優先）。
- ベンダーのセキュリティアドバイザリ／パッチ情報
- 上流プロジェクト（OSS）の公式アナウンス／修正コミット
- 再現条件・PoCの技術解説（信頼できる発信元）
- 二次まとめサイト（最後でOK）
ベンダー/上流の一次情報は「対象版数」「修正有無」の強固な根拠になります。
「リンクが多い＝重要」という判断。“量”ではなく“出どころ”で選別します。
Step6：自社文脈（到達性・実行経路）で“最後に”絞る
ここが、NVD単体では決まらない領域です。
- 当該機能は自社製品で有効か
- 入力経路は外部から届くか（IF、境界、権限）
- 脆弱コードは実行経路に乗るか（使っていない機能ではないか）
この確認ができると、「影響なし（根拠付き）」が作れます。できない場合は、迷わず 「要確認（調査中＋更新日）」で止めるのが正解です。
Step7：トリアージ結果を“台帳に残す”（ここで初めて運用になる）
読んで終わると毎回ゼロからになります。最低限これだけ台帳に残せば、運用が回ります。
- CVE
- 対象製品・版数（暫定→確定の履歴）
- 一次トリアージ（対応必須／要確認／対応不要）
- 根拠（AV/PR/UI＋自社到達性の一言）
- 次回更新日
- 証跡参照先（フォルダ/チケットID）
すぐ使える：NVD読み取りテンプレ（コピペ用）
以下をそのまま台帳やチケットのコメント欄に貼って使えます。
NVD更新日：____（更新あり/なし）
要約（1行）：____
CVSS：スコア__ ／ AV=__ PR=__ UI=__（←点数よりここ）
CPE（候補）：____（※候補、確定ではない）
一次情報（読む順で）：ベンダー____ ／ 上流____
自社対象：対象製品____ ／ 版数____（暫定/確定）
自社到達性（1行）：外部IF____、入力経路____、実行経路____
一次判断：対応必須 ／ 要確認 ／ 対応不要
次回更新日：____
証跡：フォルダ____ ／ チケットID____
トリアージの手順や判断基準を、自社の環境に合わせて整理したい方はご相談ください。
【無料】オンライン相談を予約するよくある誤解（NVDで迷うポイント）
-
誤解1：CVSSが高い＝自社でも緊急
→ ベクトル（条件）と自社到達性で決まる -
誤解2：CPEにある＝該当
→ 候補。SBOM/構成で確定する -
誤解3：リンクが多い＝重要
→ 一次情報を優先する -
誤解4：NVDだけ読めば結論が出る
→ 最後は自社文脈（到達性・実行経路）と結びつける
FAQ：NVDの見方について
「CVEの入口として情報を集め、一次情報に辿り着き、成立条件（CVSSベクトル）と対象候補（CPE）を拾う」ために見ます。NVD単体で優先度を決め切るのは危険です。
スコア“だけ”は信じない方が安全です。点数より、AV/PR/UIなどの条件（ベクトル）を読み、自社の接続形態・到達性と合わせて判断します。
即断は避けてください。CPEは抜けや表記差が起きます。SBOM/構成表側での突合を優先し、判断がつかない場合は「要確認（調査中＋更新日）」が現実的です。
全部は不要です。ベンダー公告・上流の公式情報など一次情報を優先し、二次まとめは最後で十分です。
NVDの読み込みと翻訳、AIに任せませんか？
Auto PSIRT Cloudなら、NVDの英語情報をAIが自動で読み込み、「何が起きるか」「自社環境での成立条件は何か」を日本語で要約します。
SBOMとの突合からトリアージまでの流れを、実際のデモ画面で確認してみませんか？