CVSSの数値を超えた脆弱性の優先順位付け

共通脆弱性評価システム（CVSS）は長年にわたり、脆弱性の深刻度を評価するための業界標準として機能してきました。サイバーセキュリティの専門家にとって、数少ない「信頼できる情報源」の一つになっています。

そして、お決まりの流れがあります。新しいCVEが公開され、CVSSスコアが付与され、チームは最も大きな数値の項目から急いでパッチを当てます。

それは論理的で、科学的で、さらには客観的にさえ感じられます。しかし実務では、しばしば期待どおりに機能しません。

Equifax、SolarWinds、Log4Shellの事例では、似たパターンが浮かび上がっています。実際の被害は欠陥の技術的な深刻度だけに起因したのではなく、むしろそれらの欠陥が相互接続されたシステムを通じてどのように伝播したかに起因していました。CVSSの高スコアが常に運用上の影響の大きさと相関するわけではありません。低スコアの資産が連鎖的な障害を引き起こしたのです。多くの場合、「中」程度の脆弱性が、その位置や相互作用するシステムによって最も大きな影響を及ぼし得ます。

CVSSスコアは出発点として非常に価値があります。しかし、関係性のダイナミクスは捉えられません。依存関係、共有資格情報、継承された設定を通じて、ある脆弱性の悪用がどのようにリスクを増幅または伝播させ得るかを示しません。

私たちは歴史的に、脆弱性をリスト上の孤立した点として扱ってきました。しかし実際のリスクは、それらのつながりにあります。

なぜCVSSスコアだけでは全体像にならないのか

CVSSの評価体系は、単一資産の特性に焦点を当てています。欠陥がどれほど悪用しやすいか、パッチが存在するか、機密性や可用性への潜在的影響はどれほどか。これは重要で、確かな出発点です。しかし、決定的に欠けているものがあります。それが「文脈」です。

厳重に隔離されたサンドボックス内の脆弱性は9.8を取るかもしれませんが、他に何も影響しないこともあります。一方で、すべてのシステムが信頼する単一サインオン（SSO）サービスの5.2は、被害範囲を増幅する要因になり得ます。スコアだけでは、その欠陥が企業全体にどのように波及するかは何も分かりません。

現実世界では、脆弱性はその場に留まりません。移動します。権限を継承します。パイプラインに便乗します。誰も予想しなかった場所に入り込みます。

リスクは深刻度だけの問題ではありません。伝播の問題です。

脆弱性を別の視点で捉える方法

ここで統合リンケージモデル（ULM）が登場します。「この脆弱性単体はどれほど悪いのか？」ではなく、ULMは「この脆弱性が動き始めたとき、何に影響し得るのか？」と問います。

ULMは3種類の関係性に注目します。

隣接（Adjacency）: 直接のデータ交換がなくても、隣り合って存在し相互に影響し得るシステム。

継承（Inheritance）: 下流へと伝播する欠陥。たとえば、数十のアプリケーションに組み込まれたオープンソースライブラリ内に潜む脆弱性のようなもの。

信頼（Trust）: 互いの完全性に依存するシステム。たとえば、IDプロバイダー、更新サービス、CI/CDツールなど。

これらの関係性をマッピングすると、脆弱性の一覧ではなく、経路のネットワークが見えてきます。すると、一見些細な欠陥が、はるかに大きな物語を明らかにすることがあります。

脆弱性は実際にどう動くのか

現代の開発パイプラインは、脆弱性が気付かれないまま広がることを驚くほど容易にしています。欠陥のあるライブラリがビルドに取り込まれ、Dockerイメージに含まれます。そのイメージが本番へ昇格されます。コンテナは新たな権限を獲得します。そして最終的に、外部エンドポイントがそれをインターネットに露出させます。誰かがCVE通知を目にする頃には、その脆弱性はすでにミッションクリティカルなシステムの内部で生きているかもしれません。

問うべきは単に「スコアはいくつか？」ではなく、「これはどこまで行き得るのか？」です。

リンケージの視点でLog4Shellを捉え直す

Log4Shellが歴史的になったのは、技術的に深刻だったからではありません。毎年、重大（Critical）と評価される脆弱性は何百件もあります。歴史的になったのは、それが至る所に存在したからです。Log4jは入れ子の依存関係を通じて継承され、無数のライブラリに組み込まれ、信頼されないデータを取り込むシステムから信頼されていました。

それは継承、隣接、信頼が重なった完璧な嵐でした。

Log4Shellは、脆弱性の真の危険性が「それが何であるか」だけでなく、「どこに存在するか」にもあることを教えてくれました。

リンケージに基づいてスコアリングすると何が起きるのか？

ULMはCVSSスコアを置き換えるものではありません。強化するものです。深さ、到達範囲、影響力について考えることを私たちに促します。

引退した開発用VMの脆弱性は9.8を取るかもしれません。しかし、何もそれに依存していなければ、現実世界での優先度は低い可能性があります。

一方で、本番ビルドに供給するGitHub runnerの欠陥は、リンケージの観点で評価するとより高くなるかもしれません。信頼されたパイプライン上にあり、資格情報を継承し、下流のシステムに影響を与え得ます。ULMの見方では、その緊急度は急上昇します。

数値だけでは誤解を招きます。物語はリスクを明らかにします。

組織が今日からULMを使い始める方法

大規模な刷新は必要ありません。まずは考え方の転換から始まります。

• どんなシステムが存在するかだけでなく、システムがどうつながっているかをマッピングする。
• 共有コンポーネント、共有ID、共有パイプラインを探す。
• どのシステムが他から信頼され、依存され、継承されているのかを問う。

そして、そのネットワークの中でどこに位置しているかに基づいて脆弱性の優先順位を付けます。特に、IDシステム、CI/CDパイプライン、広く使われる共有サービスの近くにあるものです。これらは静かな増幅器です。

小さく始めましょう。下流への影響力が最も大きいシステムに焦点を当ててください。全体像はすぐに見えてきます。

結論

脆弱性管理は数のゲームではありません。関係性のゲームです。

CVSSは理論上、脆弱性がどれほど深刻かを教えてくれます。ULMは実務上、それがどれほど危険になり得るかを理解する助けになります。そして複雑性、自動化、相互接続システムが加速する世界では、その文脈はもはや任意ではありません。

環境を防御するには、脆弱性を点として見るのをやめなければなりません。それらの間の線を見るようにしなければなりません。

本当のリスクが存在するのはそこです。

この記事はFoundry Expert Contributor Networkの一環として公開されています。
参加したいですか？