用語比較
CVEとCVSSの違い
一言でいうと
CVEは脆弱性を共通の番号で識別し、CVSSは技術的な深刻度を評価する。番号があること、点数が高いこと、自社が影響を受けることは別の判断。公式の対象製品・版を照合し、CVSSの版・評価元・ベクター、悪用情報、公開範囲と業務影響をそろえて対応を決める。
CVEは脆弱性の識別子、CVSSは技術的な深刻度を示す評価体系です。0〜10のスコアの目安、v3.1・v4.0の版と評価元、未採点時の確認方法を整理。点数だけでパッチ順を決めず、影響版・悪用情報・自社資産を照合する手順と無料の判断記録で、情シス・開発者の初動を支えます。
- 難易度
- 初級
- 想定読者
- 情シス・開発者・脆弱性管理を始める担当者
- 所要時間
- 約12分
- 最終確認
- 2026-10-30
- 1. 対象を照合する
CVEと公式の製品・版・構成を、自社資産・委託先の範囲と突き合わせる。
- 2. 判断材料をそろえる
CVSSの版・評価元・条件、悪用情報、公開範囲、業務影響を確認する。
- 3. 対応と残件を記録
承認された対処、適用・稼働の結果、調査と未確認範囲を分けて残す。
CVEとは
Common Vulnerabilities and Exposures。公開される脆弱性を識別・追跡する共通のIDとレコードの仕組み。IDの割り当て、詳細の公開、製品の修正は別の状態で、番号だけでは深刻度や自社への影響は分からない。
CVSSとは
Common Vulnerability Scoring System。脆弱性の技術的な深刻度を共通の指標で表す評価体系。0.0〜10.0の点数だけでなく、版、評価元、評価グループとベクターを確認する。自社の被害確率や損失額そのものではない。
違いの比較表
| 比較軸 | CVE | CVSS |
|---|---|---|
| 目的 | どの脆弱性について話しているかをそろえる | 攻撃条件と技術的な影響を共通の尺度で説明する |
| 形式 | CVE IDと、説明・参照情報等を含むレコード | 版、0.0〜10.0の点数、評価グループ、ベクター |
| 対象確認 | ベンダーの対象製品・版・構成と自社資産を照合 | スコアの前提条件が自社の構成にも当てはまるかを確認 |
| 評価元 | CNA等が公開・更新するレコードを参照 | ベンダー等の評価元と日時を残す。複数の評価を混同しない |
| 未確認 | 詳細が未公開でも安全とは判断しない | 未採点・情報不足を0.0点や対象外へ置き換えない |
| 更新 | 対象版・参照先・状態の更新を再確認 | 版や評価条件の変化を再確認。数字だけを比較しない |
| 次の行動 | 影響資産と公式の修正・緩和情報を特定 | KEV等の悪用情報、公開範囲、業務影響を加えて判断 |
違いが分かったら、自社の判断記録へ
版・評価元・自社条件・判断を変える条件と、次の担当を記録する。判断表で不足した条件を、次の記録へ引き継げます。
無料のCVE・CVSS判断記録を開く使い分け
- 脆弱性の連絡を受けたら、CVEで情報を突き合わせ、製品名だけでなく版・機能・導入形態まで確認する。CVEの詳細公開や採点完了を緊急対応の待機条件にしない。
- CVSSの高い順だけで作業を並べず、影響がある資産と悪用情報を確認する。自社で侵害が疑われる場合は、点数比較より報告・封じ込めの判断を優先する。
- 説明や見積では、対象資産、公開範囲、作業の停止影響、確認範囲をそろえる。同じCVEでも導入形態と業務影響が異なれば、作業内容や優先度は変わる。
CVE番号の確認方法：公開と修正完了を分ける
CVE Programのライフサイクルでは、IDを予約するReservedと、必要な情報を含むレコードを公開するPublishedを区別する。Reservedは詳細公開前の調整等に使われる状態であり、危険性がないという判定ではない。Publishedも、利用中の製品へ修正が適用されたことを意味しない。
確認するのはID、公式の対象製品と版、影響する機能・構成、修正版・緩和策、更新日時。自社資産はクラウド・委託先・依存関係も含めて照合し、未確認の環境を対象外にまとめない。番号が同じでも、古い転載と更新後の公式情報を同じ根拠として扱わない。
CVEがない設定不備・運用上の弱点も管理する。番号やCVSSがまだなくても、ベンダーの案内や自社の兆候から対応が必要になる。社内台帳には暫定の管理番号と根拠を残し、公式情報の追加・更新を追跡する。
CVSSスコアの目安とv3.1・v4.0の違い
FIRSTのCVSS v4.0の区分は、Noneが0.0、Lowが0.1〜3.9、Mediumが4.0〜6.9、Highが7.0〜8.9、Criticalが9.0〜10.0。9.8と10.0はどちらもCriticalだが、同じ対応期限や同じ影響を意味しない。点差だけで対応を後回しにしない。
記録は「版・評価元・評価日時・点数・評価グループ・ベクター」を一組にする。v4.0にはBase、Threat、Environmental、Supplementalの4グループがあり、Supplementalの値は最終スコアを変えない。Threat・Environmentalの条件も含め、自社の判断へ何を用いたかを明示する。
v3.1とv4.0の点数を、同じ条件で測った値のように混ぜて順位付けしない。評価元で異なる場合も点数だけを選び直さず、条件と理由を比較する。サイト内のCVSS計算機はv3.1専用の学習ツールであり、v4.0や自社のリスク評価を代行するものではない。
パッチの優先順位：高得点・未採点でも同じ手順で確認
編集部の判断順は、①影響する資産・版があるか、②実際の悪用情報や自社の兆候があるか、③到達性・業務影響と修正方法は何か、の3点。確認は必要に応じて並行し、侵害疑いの報告や保護を台帳完成まで待たない。
KEV掲載やベンダーの悪用情報があり、自社で対象版を公開しているなら、緊急の変更・制限を責任者へ相談する。一方、対象版がないと確認できた資産は、根拠と確認日を残す。対象か不明な資産を、未採点や低得点を理由に安全へ分類しない。
FIRSTはCVSS Baseだけをリスクやパッチ優先順位としないよう説明している。EPSSとの単純な掛け算を、損失額や自社の被害確率と呼ばない。対応期限は社内規程、契約・適用要件、公式の対処と自社条件を照合して決める。
判断記録と対応完了：見積・引き継ぎで残す項目
記録の最小例は、対象IDと資産、公式URLと確認日時、版・構成の一致、採点の根拠、悪用情報と公開範囲、決めた対処・承認者、実施結果・未確認範囲。これは編集部の記録例であり、すべての組織へ同じ様式を要求する規格ではない。
見積依頼は、対象台数・導入形態・停止可能時間・作業範囲・適用後の確認をそろえて比較する。診断・パッチ作業・侵害調査を同一サービスと扱わず、価格だけで依頼先を選ばない。実在する契約や見積を確認していないため、固定の費用相場は示さない。
更新の配布成功だけで完了とせず、稼働中の版・対象範囲・業務動作と、必要な調査の残件を確認する。比較表を読んだ後は無料の判断記録へ進み、確認した事実と次の担当を残す。社内の構成情報や認証情報をCyberLensへ入力する必要はない。
よくある誤解
- CVE番号は深刻度・修正済み・自社の侵害を示す番号ではない。
- CVSS未採点は0点ではない。低い点数も対象外や放置の根拠にはならない。
- 技術的な深刻度と、悪用の観測・予測・自社の業務リスクを別の材料として扱う。
よくある質問
CVE番号があれば、自社も影響を受けますか？
番号だけでは判断できません。公式の対象製品・版・機能・導入形態と自社資産を照合します。未確認の資産を対象外にせず、レコードの公開と修正適用の完了も分けます。
CVSS 9.8と10.0では、対応順を変えるべきですか？
どちらもCriticalの9.0〜10.0です。点差だけで決めず、版・評価元・評価条件、悪用情報、公開範囲と業務影響を照合します。自社の侵害が疑われる場合は報告・封じ込めの判断を優先します。
CVSSが未採点なら、点数が出るまで待ってよいですか？
未採点を0点や安全とは扱いません。公式の影響範囲、修正・緩和情報と自社条件を確認し、必要な保護・報告を採点待ちにしません。判断記録へ不明点と次の担当を残します。
編集・確認情報
CVE Programの公開プロセス、FIRSTのCVSS v4.0仕様・FAQ、CISAのKEV利用案内を照合し、版・未採点・自社影響・対応記録を改訂しました。個別CVEの最新値、実資産の診断や修正試験、個別監修は行っていません。 最終確認日は 2026-10-30 です。
参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。
新しい解説を見逃さない
CVE・KEVの初動対応や実務チェックリストは随時追加しています。使いやすい方法で更新を受け取れます。