脆弱性管理とは？CVSS・SSVCの基本と管理プロセスを解説

脆弱性管理とは、システムやソフトウェアに存在する脆弱性を把握し、リスクを最小化するプロセスです。本記事では、脆弱性管理のプロセスや、リスク評価手法であるCVSS・SSVCの基本、活用ツールなどを解説します。

脆弱性管理における「脆弱性」とは何か

一般的に脆弱性（Vulnerability）は、「セキュリティ上の弱点や欠陥」を意味しますが、特に脆弱性管理の文脈においては、システムやネットワーク上で稼働するOSやソフトウェア、ミドルウェアなどに存在する「既知のセキュリティ上の弱点や欠陥」のことを指します。

これらの脆弱性を悪意ある第三者に悪用されると、不正アクセス・情報漏えい・サービス停止などの被害につながる可能性があります。

脆弱性は、ソフトウェアの複雑化や人為的ミス、設定不備などの要因によって生じるものであり、どのようなシステムにも少なからず存在します。脆弱性を完全に排除することは難しく、継続的な「脆弱性管理」が欠かせません。

脆弱性の識別番号CVE

発見された脆弱性のうち、ソフトウェアやシステム製品に関するものは、CVE（Common Vulnerabilities and Exposures - 共通脆弱性識別子）という識別番号が付与され、MITRE社を中心とした国際的な枠組みのもとで管理・公開されています。

CVEは脆弱性を世界共通の形式で特定するための基盤であり、各ベンダーやセキュリティツールが参照できる「共通のID」として機能します。

CVEの対象として、以下のようなソフトウェアやコンポーネントが含まれます。

• 言語ライブラリ（例：OpenSSL、log4j など）

• OSパッケージ（例：Linux カーネル、glibc など）

• VPNなどの機器で動作するソフトウェア（例：FortiGate、Cisco ASA など）

• ソフトウェア製品（例：Confluence、GitLab、WordPress など）

• そのほか、ソフトウェアとして提供されるツールやモジュール全般

本記事では、「CVE-XXXX」のように識別子が付与される「既知の脆弱性」に対する管理・対応方法について解説しています。

脆弱性管理とは

脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、リスクを最小化するために対応を行うプロセスのことです。

新たな脆弱性は日々発見されており、2024年には年間で4万件強のCVEが報告されています。これは1日あたりに換算すると、およそ110件のペースで新たな脆弱性が公開されている計算です。

すべての脆弱性に対応するのは現実的ではなく、どの脆弱性に優先的に対応すべきかを判断し、組織として管理する仕組みが求められます。

多くの企業や組織では、CVEとして公開された既知の脆弱性情報をもとに、自社環境でどのソフトウェアが影響を受けるかを確認し、修正パッチの適用や代替策の実施を行います。この一連の流れが「脆弱性管理（Vulnerability Management）」です。

脆弱性は時間の経過とともに増加・変化し続けるため、単発の対応ではなく、継続的な運用プロセスとして管理することが重要です。こうした継続的な脆弱性管理こそが、組織のセキュリティ対策におけるリスクマネジメントの基盤となります。

脆弱性管理の4ステップ

脆弱性管理は、次の4つのステップで構成されます。上述した通り、単発の修正対応ではなく、継続的なサイクルとして繰り返す仕組みが重要です。

1. 脆弱性の情報収集

まず、日々新たに発見・公表される脆弱性の情報を継続的に収集します。主な情報源としては、NISTが運営するNational Vulnerability Database（NVD）や、JPCERT/CCと情報処理推進機構（IPA）が共同で管理するJapan Vulnerability Notes（JVN）などの脆弱性データベースが挙げられます。これらの公的情報に加え、IPAやJPCERT/CCといった機関が発信する注意喚起、製品ベンダーが提供するセキュリティアドバイザリも有効な情報源です。

これらの情報をもとに、脆弱性の名称やCVE番号、対象となるソフトウェアや製品、該当するバージョン、脆弱性が発生する条件、そして提供されている対応策や回避策を把握します。

2. 影響範囲の特定

収集した脆弱性情報の中から、自社に影響するものを特定します。同じCVEでも、使用しているソフトウェアのバージョンや構成によって影響の有無は異なります。影響を正しく把握するためには、IT資産とそのバージョンを管理しておくことが不可欠です。

特に近年は、ソフトウェアが複雑な依存関係を持つことから、従来の資産管理だけでは構成を十分に把握できないケースも増えています。そこで有効なのがSBOM（Software Bill of Materials）です。SBOMを利用することで、自社のどのソフトウェアにどのOSSライブラリや依存コンポーネントが含まれているかを可視化でき、より正確な影響範囲の特定が可能になります。

▼ SBOMの詳細は以下の記事で解説しています。
SBOMとは？ソフトウェア部品表の基本と、脆弱性管理における重要性を解説

3. リスク評価と優先順位づけ

膨大な脆弱性の中から、どの脆弱性から優先的に対応すべきかを判断します。

一般的には、CVSS（共通脆弱性評価システム）などのスコアを参考にしながら、自社のシステム構成・業務影響・露出状況などを踏まえてリスクを評価します。近年では、SSVC（Stakeholder-Specific Vulnerability Categorization）のように、「自社の立場や利用状況」に応じて判断を行う手法も注目されています。詳しくは次章で解説します。

その他の脆弱性の評価指標にはEPSSなどがあります。詳細は、IPAがまとめている「脆弱性対応におけるリスク評価手法まとめ」をご参照ください。

4. 修正と再評価

優先度に基づいて、パッチ適用や設定変更、無効化などの修正対応を実施します。対応後は修正が正しく反映されているかを再評価することも重要です。必要に応じて運用ルールや監視体制を見直し、より効果的な運用プロセスとなるよう改善を重ねていきます。

こうした脆弱性管理のサイクルを継続的に回すことで、組織全体のセキュリティレベルを高めていきます。

脆弱性の評価方法

脆弱性管理プロセスの中でも、最も判断が難しいのが「リスク評価と優先順位づけ」です。どの脆弱性から対応すべきかを正しく見極めるためには、客観的な評価指標が欠かせません。

ここでは代表的な評価方法として、CVSSとSSVCの2つを紹介します。CVSSは長年にわたり国際的に用いられてきた評価基準であり、SSVCは近年注目される新しい判断モデルです。

CVSS（Common Vulnerability Scoring System）

CVSSには「基本評価基準」「現状評価基準」「環境評価基準」の3つの基準がありますが、多くの企業が採用しているのは「基本評価基準」です。

CVSSの基本評価基準は、10段階のスコアで脆弱性の深刻度を表します。たとえば「9.8＝Critical（非常に深刻）」などと分類されます。業界標準としても浸透しており、「CVSSスコア 8.0以上の脆弱性には対応する」といったような運用ルールを掲げている企業も多く見られます。

一方で、CVSSにはいくつかの課題も指摘されています。

第一に、「自社への影響度合いが反映されにくい」点です。CVSSはあくまで脆弱性そのものの性質を評価する仕組みであり、スコアが高くても自社では影響が限定的なケースもあります。

第二に、「攻撃の現実性を十分に考慮できない」点です。スコアが低くても、すでに攻撃コードが公開されていたり、インターネット上の資産に関連していたりすれば、実際のリスクは高くなります。

つまり、CVSSスコアだけに頼ったトリアージでは、本来優先すべきリスクを見落としたり、逆に過剰対応してしまう可能性があるのです。

SSVC（Stakeholder-Specific Vulnerability Categorization）

SSVCは米カーネギーメロン大学のソフトウェア工学研究所（SEI）が提唱したフレームワークで、米国の政府機関CISAも脆弱性対応判断に活用しています。

CVSSが「脆弱性そのものの性質」を基準に点数を出すのに対し、SSVCは「自社がどの立場でその脆弱性に関わっているか」という意思決定の文脈を重視します。

SSVCでは、次の4つの要素を組み合わせて評価をします。

• Exploitation（攻撃利用の有無）：すでに悪用されているか

• Exposure（露出状況）：自社環境で脆弱性が外部から到達可能か

• Mission Impact（業務影響）：そのシステムが事業にどれだけ重要か

• Safeguards（代替策の有無）：既存の防御で影響を緩和できるか

これらの要素をもとに、「今すぐ対応」「要検討」「経過観察」といった対応レベルを導き出します。SSVCは単なる技術的評価にとどまらず、組織の運用方針や事業優先度を踏まえた意思決定を支援する手法といえます。

CVSSとSSVCはいずれも脆弱性への対応を支援する基準ですが、目的は異なります。CVSSは脆弱性の一般的な危険度を示し、SSVCは組織の状況に応じた優先度判断を可能にします。両者を組み合わせて運用することで、より実践的で効果的な脆弱性管理が実現します。

脆弱性管理を実現する手法・ツール

脆弱性情報の収集から優先順位づけ、修正対応までをすべて手作業で行うのは現実的ではありません。継続的な脆弱性管理を実現するためには、人手による対応だけでなく、専用のツールや仕組みを組み合わせて運用することが有効です。

代表的なアプローチとして「プラットフォーム診断」と「CWPP（Cloud Workload Protection Platform）」を紹介します。

プラットフォーム診断

プラットフォーム診断は、サーバーOS、ミドルウェア、ネットワーク機器、クラウドインフラなど、システムの基盤となるプラットフォーム層におけるセキュリティリスクを検出する診断手法です。

診断では、ポートスキャンや脆弱性スキャナーなどを用いて、既知の脆弱性（CVE）の有無を確認するほか、不要なポート開放などの設定ミスに起因するリスクも検出します。

もともとはオンプレミス環境を中心に実施されてきた手法ですが、現在ではクラウド上の仮想マシンやコンテナ、クラウドサービスの設定なども診断対象となっています。一般的には年1~2回の定期的なタイミングで実施され、システム全体のセキュリティ状態をまとめて可視化するのに適しています。

CWPP（Cloud Workload Protection Platform）

CWPPは、クラウド上で稼働するサーバーや仮想マシン、コンテナなどのワークロードを保護するための包括的なセキュリティプラットフォームです。多くのCWPP製品では脆弱性管理機能を備えており、OSやミドルウェア、アプリケーション、コンテナイメージなどに潜む脆弱性を、CVE情報と照らし合わせて検出します。

プラットフォーム診断が年数回など定期的に実施される「単発の検査」であるのに対し、CWPPによる脆弱性スキャンは日常的にスキャンを行い、常に最新の状態でリスクを可視化できる点が特徴です。

また、CWPPは単体で使うだけでなく、CNAPP（Cloud-Native Application Protection Platform）の一部としてCSPMなどと統合して運用することで、クラウド全体の構成リスクとソフトウェア脆弱性を統合的に把握することも可能です。

Cloudbaseは、誰でもリスクに対応できるCNAPP製品を提供しています。CWPPによる脆弱性管理に加え、SBOMを活用したソフトウェア部品表の管理、CSPMによるクラウド設定の監査を一つのプラットフォームで統合し、クラウド環境におけるリスクの可視化と継続的な改善を支援します。

ご興味がある方は、お気軽にお問い合わせください。