CVE/CVSSの読み方
（リテラシー・担当者向け）
「CVEの通知が来たけど、結局“今すぐ対応すべきか”が分からない」
「CVSSが高い＝緊急と思って全部赤にしたら、現場が回らない」
「OEMに“影響有無と根拠”を期限内に出せと言われて焦る」
Tier2〜Tier4の現場で起きているのは、技術力不足というより “読み方の型がない” ことによる混乱です。
この記事では、セキュリティ専任がいなくても回るように、CVE/CVSSを5分で読む順番と、トリアージ（対応必須/要確認/対応不要）へ落とす実務手順をまとめます。
この記事でわかること
- CVEとCVSSの違い（何を表している指標か）
- CVSSを読む“順番”（先に見るべき項目）
- CVSSスコアのよくある誤解（高い＝今すぐ、ではない）
- 3段階トリアージへ落とす判断の型
- OEMに通る「結論→根拠→対応方針」の作り方（最小）
まず整理：CVEとCVSSは役割が違う
CVE ＝「脆弱性の番号（識別子）」
CVEは「何の脆弱性の話か」を指すための番号です。
CVE自体は“優先度”ではありません。
CVSS ＝「脆弱性そのものの深刻度（スコア）」
CVSSは、その脆弱性が一般論としてどれだけ深刻かを数値化します。
ただしCVSSだけで“自社で今すぐやるべきか”は決まりません。
（自社製品に入っていない／到達できない／機能が無効、などで優先度は変わるからです）
CVSSスコアの目安（“赤い数字”に振り回されない）
一般的な目安として、CVSS v3系では以下のレンジが使われます。
- 0.0 None
- 0.1–3.9 Low
- 4.0–6.9 Medium
- 7.0–8.9 High
- 9.0–10.0 Critical
ここで重要なのは、9点台＝即対応ではなく、「“条件が揃えば”深刻」くらいの扱いにすることです。
本当に知りたいのは次の問いです。
その条件は、うちの製品で揃うのか？（＝到達性・実装・使い方）
5分で読む：CVE/CVSSの“見る順番”（これだけでOK）
CVE詳細ページやNVD/JVNの記述を、全部読む必要はありません。まずは以下の順で見てください。
① 影響対象（Affected Product / Version）
- その脆弱性が どの製品・どのバージョン に当たるのか
- “自社の該当製品・該当版数”に当たるか（SBOM/部品表/構成表で確認）
ここが一致しなければ、優先度は一気に下がります（ただし誤マッチもあるので「要確認」で残すのはアリ）。
② 攻撃経路（AV：Attack Vector）
CVSSの中で、現場が最初に見るべきはAVです。ざっくり言うと「外から届くか？」です。
- AV:N（Network）：ネットワーク越しに攻撃可能（外部IFがあると危険度が上がる）
- AV:A（Adjacent）：同一セグメント等の近い範囲
- AV:L（Local）：ローカル実行が必要
- AV:P（Physical）：物理アクセスが必要
自動車部品では、外部IF（Bluetooth/Wi-Fi/USB/Ethernet/OTAなど）の有無で現実の優先度が大きく変わります。
③ 必要権限（PR）＋ ユーザー操作（UI）
- PR（Privileges Required）が低い（None/Low）ほど危険
- UI（User Interaction）が不要（None）ほど危険
逆に、ユーザー操作が必要・高権限が必要なら、現場の優先度は下がることがあります。
④ 影響（C/I/A：機密性/完全性/可用性）
- 可用性（A）が高い → 監査やOEM照会で注目されやすい
- 完全性（I）が高い → 制御・改ざん系に繋がる
- 機密性（C）が高い → 情報漏えい系
ここは「どんな事故になり得るか」を一言で説明する材料になります。
⑤ “自社文脈”での到達性（最重要：CVSSには入らないことが多い）
最後に、ここを必ず確認します。
- 当該機能は製品で有効か（設定で無効化していないか）
- 外部からその入力経路は本当に届くか（境界、ゲートウェイ、閉域など）
- そのコードは実行経路に乗るか（使っていない機能ではないか）
この確認ができると、「影響なし」や「要確認」の強固な根拠が作れます。
“高CVSS＝即対応”にしないための超簡易トリアージ（3段階）
兼務体制で回すなら、まずは3段階で十分です。
対応必須（Critical）
- 対象製品・対象版数に当たる可能性が高い
- AVがNetwork寄りで、PR/UIも厳しくない
- 影響（C/I/A）が大きい、またはOEMから照会が来ている
要確認
- 対象製品に当たりそうだが、到達性や実行経路が未確認
- “影響なし”と断定する根拠がまだない
→ この段階で「調査中＋次回更新日」を返すと炎上が減ります
対応不要（ただし根拠付き）
- そもそもコンポーネントが入っていない
- 脆弱コードが実行経路にない／攻撃者が制御できない
- 機能が無効・外部IFがない等、成立条件が揃わない
→ “影響なし”の根拠を一言で残すのが必須です
豆知識：VEX（影響判定）の考え方を入れると“説明が強くなる”
CVE/CVSSの読み方が分かった次に詰まるのが、OEMへの説明です。ここで役立つのが VEX（影響判定の表明） の考え方です。
- 「影響あり／なし／調査中」を“ラベル化”できる
- 「影響なし」の根拠（例：実行経路にない、到達できない）を型で残せる
- 監査や追加質問に耐えやすくなる
すぐ使える：社内共有用「1枚まとめ」テンプレ（コピペOK）
社内で設計・品質・情シスに投げるとき、これだけ埋めれば会話が前に進みます。
CVSS（Base）：__（Critical/High/Medium/Low）
まず見る指標：AV=__ / PR=__ / UI=__
対象製品：（版数：）
自社の到達性：外部IF（有/無）、入力経路（____）
一次判断：対応必須／要確認／対応不要
根拠（1行）：____
次回更新日（要確認のとき）：____
証跡（リンク/フォルダ）：____
CVE/CVSSを“自社の製品構成・外部IF・OEM要求”に合わせて、
トリアージ基準として整理したい方はご相談ください。
FAQ：CVE/CVSSの読み方について
CVEは脆弱性の識別番号、CVSSは脆弱性の一般的な深刻度を示すスコアです。CVE＝番号、CVSS＝深刻度の目安、と分けると混乱が減ります。
即対応とは限りません。自社製品に当たるか、外部から到達できるか、実行経路に乗るかで優先度は変わります。まずAV（攻撃経路）と対象版数を確認してください。
現場では AV（Attack Vector）→PR/UI→対象版数 の順が分かりやすいです。「外から届くか」「権限や操作が必要か」を先に見ると、判断が速くなります。
「影響なし」だけだと弱いので、根拠を一言で残します（例：コンポーネントが入っていない／実行経路にない／到達できない／機能が無効）。必要ならVEXの考え方で型にします。
一次回答として「調査中」と「次回更新日」を返すのが現実解です。黙るより、状態と更新予定を示す方が信頼を落としにくいです。
英語の脆弱性情報と格闘する時間をゼロにしませんか？
Auto PSIRT Cloudなら、毎日のCVE情報をAIが日本語で要約し、自社のSBOMと自動で突合。「対応必須か、無視してよいか」のトリアージまで全自動で行います。