【セキュリティ対策|実務向け】CVSS v4.0の重要変更点と実務における正しい運用指針

1. 導入:なぜCVSS v4.0への理解が重要なのか

多くの企業が脆弱性管理に利用しているCVSS(Common Vulnerability Scoring System)が、2023年11月に4年ぶりのメジャーアップデートとなる「v4.0」へ移行しました。
これまで「CVSSのスコアだけで優先順位を決めてしまい、本当に対応すべき脆弱性を見失う」という課題が多くの現場で指摘されてきました。CVSS v4.0は、この「スコアの独り歩き」を防ぎ、より現実に即したリスク判断を支援するために大幅な見直しが行われています。本記事では、実務者が押さえるべき変更点と、現場での活用法を解説します。

2. 基礎知識:CVSS v4.0の構造を理解する

CVSS v4.0では、スコアを算出する際「どの指標まで考慮したか」を明確にするために、以下の命名規則が導入されました。

CVSS-B:基本評価基準(脆弱性そのものの特性)
CVSS-BT:基本+脅威評価基準(悪用コードの存在状況など)
CVSS-BTE:基本+脅威+環境評価基準(自社環境への影響度)

重要なのは、CVSS-Bだけでリスクを判断すべきではないという点です。ベンダーが公開するスコア(CVSS-B)は「合理的な最悪のケース」を想定しているため、高スコアになりがちです。これに「自社環境では攻撃可能か」「攻撃コードは出回っているか」という要素(BTやE)を掛け合わせることで、より現実的な優先度が見えてきます。

3. 実装/解決策:現場で役立つ評価の考え方

実務で特に注目すべき変更点は以下の3点です。

・「スコープ(S)」の廃止:これまで概念が難解だった「スコープ」が廃止され、脆弱なシステムと後続システム(影響を受ける周辺システム)へ個別に影響を与える評価が可能になりました。
・補足評価基準の追加:「安全性(Safety)」や「リカバリー(Recovery)」など、スコアには直接影響しないものの、対応優先度を判断する上で極めて重要な付加情報が提供されるようになりました。
・脅威評価基準の簡素化:利用可能な対策レベルなどが廃止され、よりシンプルに「攻撃コードが実在するか」という事実に焦点を当てた評価が可能となりました。

4. サンプルプログラム:Pythonによる簡易的な脆弱性優先度判定

CVSSスコアを基に、独自の優先度を計算するロジック例です。スコアだけでなく、脅威情報を加味する重要性を示しています。

脆弱性の優先度を判定する簡単なサンプル
def calculate_priority(cvss_base_score, is_exploit_available):
“””
CVSS基本値に、攻撃コードの有無(脅威評価)を掛け合わせた優先度判定
“””
# 攻撃コードが公開されている場合、リスクを増幅させる
threat_multiplier = 1.2 if is_exploit_available else 1.0

adjusted_score = cvss_base_score threat_multiplier

if adjusted_score >= 9.0:
return “緊急(即時対応)”
elif adjusted_score >= 7.0:
return “高(優先対応)”
else:
return “中/低(スケジュール対応)”

例:CVSS基本値8.5の脆弱性で、攻撃コードが存在する場合
score = 8.5
exploit = True
priority = calculate_priority(score, exploit)

print(f”調整後スコア: {score (1.2 if exploit else 1.0)}”)
print(f”優先度判定: {priority}”)
このように、基本値だけでなく脅威状況を考慮するのがCVSS v4.0の考え方です

5. 応用・注意点:現場での陥りやすいバグと回避策

最後に、現場でよくある失敗と対策をまとめます。

・「スコアが高い=即対応」の罠
CVSS-Bの値が高いからといって、自社環境で攻撃が成立しないケース(攻撃経路がない、特定の構成でない等)は多々あります。必ず環境評価基準(E)を適用し、自社にとっての意味あるスコアを算出してください。
・補足評価基準を無視しない
「スコアに影響しないから」と補足評価基準を無視するのはもったいないです。例えば、DoS攻撃でサービス停止しても「数秒で自動復旧する」という特性があれば、緊急度は下げられます。この判断を自動化・可視化できるツールやプロセスを構築することが、脆弱性管理の成熟度を高める鍵です。

CVSS v4.0は、単なる数値計算から「ビジネス・技術両面でのリスク判断」へと舵を切りました。ぜひ、自社の脆弱性管理プロセスにこの考え方を取り入れてみてください。

コメント

タイトルとURLをコピーしました