このHelp Net Securityのインタビューで、Tharros副ディレクターのArt Manionは、リポジトリ全体の脆弱性データがなぜ一貫性を欠き、信頼しにくいままなのかを検討しています。
問題は、そのようなデータを収集・管理するために設計されていないシステムから始まります。最小限の実行可能な脆弱性列挙(MVVE)という概念を導入しています。これは、2つのシステムが同じ脆弱性を説明していることを確認するために必要なアサーションの最小セットですが、真の最小値は存在しないことが判明しています。アサーションはケースごとに異なり、時間とともに変化します。新しい仕様を書いたり新しいツールを構築したりする前に、コミュニティは共有される用語と原則が必要であると主張しています。CVSSスコアなどのメトリクスは、文脈に基づいた実際のリスク評価という、より困難な作業からの注意をそらすことがよくあります。
2つのリポジトリがパッチが脆弱性を修正するかどうかについて意見が異なる場合、それはデータ品質の問題、ガバナンスの問題、または定義上の問題ですか？そして、この区別は修正方法にとって重要ですか？
これはおそらく3つすべての問題の組み合わせであり、ある程度の重複があります。脆弱で修正されたソフトウェア製品とバージョンのセットは不正確または不完全な場合があります。ガバナンスはそのような不正確さを十分に検出および解決しない可能性があります。定義、語彙、および文法は十分に厳密でもなく、広く共有されてもいません。提案している原則の1つは、脆弱性レコードの品質はデータの問題である前に、アーキテクチャの問題であるということです。最初の場所で収集、管理、および伝達するために設計されていないシステムから高品質なデータを期待すべきではありません。
脆弱性情報の生産者と消費者は、さまざまなスキル、経験、および知識を持っています。おそらくより重要なのは、生産者と消費者の両方が情報へのアクセスが不均等であり、情報とそれへのアクセスの両方が時間とともに変化することです。もう1つの原則は、脆弱性レコードは時間をかけて管理される必要があるということです。システムは適応し、さらには変更を促進することで、私たちの理解とともに適応および進化する必要があります。不完全な情報と正当な意見の相違が風景の永続的な特徴であることを受け入れ、それに応じてレコードを管理する必要があります。
どちらのシステムも相手の権限を信頼する必要なく、2つの独立したシステムが同じ脆弱性について話していることを確認できるようにする、アサーションの最小セットは何ですか？
この最小限のセット(MVVE)を定義することを目指しましたが、そのような最小値は存在しない可能性があることが判明しました。影響を受けた(ソフトウェア)製品を指定すること、および悪用が成功する条件と1つ以上の侵害されたセキュリティプロパティを識別することなど、共有要素があります。それ以上に、脆弱性を重複排除および曖昧さを取り除くために必要なアサーションの数と種類は異なります。
時間をかけて、リポジトリ内および全体にわたって、可変的なアサーションのセットが必要です。しかし、アサーションのリストとタイプを整理することは二次的です。脆弱性データの問題を調査してきた結果、最初に共有用語および概念の基礎をより良くし、その後、適切なアサーションの規則を構築できることが判明しました。
重大度スコア、アドバイザリー文、CWEアサインメント、および影響を受けた製品リストを除去した場合、何が残りますか？残されたものはリポジトリ間の重複排除を定着させるのに十分か、それともそれを取り除くことで空白を露呈しますか？
既存のレコード形式には改善の余地があることは間違いありません。「何を持っていますか？」から始めるのではなく、「何が必要ですか？」と尋ねました。これは「脆弱性レコードはどの脆弱性管理タスクと決定をサポートしていますか？」に至りました。最も重要な初期タスクの1つは、影響を受けたソフトウェア製品の識別です。最近の研究では、「公式のNVDデータベース内のCPEで使用されているベンダー名の50.18%で命名の矛盾が識別されました。」影響を受けた製品を正確に特定できない場合、他には何も重要ではありません。（CPEはこの障害モードで独特ではなく、他のソフトウェア識別システムも同様に苦しんでいます）。
CPEアサーションのような何かの品質を測定する際の1つの課題は、人間には完全に妥当に見えるかもしれませんが、特に自動化とマシンの使いやすさの面で、ソフトウェアを適切に識別するのに失敗することです。識別子とソフトウェア製品の違いを見分けるには、かなりの手作業が必要です。その手作業を削減または排除することは、識別システムとそのアサーションのアーキテクチャと設計から始まります。
正しいレベルの詳細を取得するために設計したら、情報を信頼する能力に焦点を当てる必要があります。もう1つの原則は、今後議論します：「レコード内のすべてのアサーションは、それ自体に答えることができる必要があります。」したがって、アサーションを記録するときは、簡潔、正確、観察可能、有用であり、出所を含める必要があります。新しい脆弱性レコードは、時間とともに成長(および変更)し、脆弱性識別子にバインドされ、マシンが使用可能なアサーションの集合です。これらのアサーションは脆弱性を説明し、識別、重複排除、および脆弱性管理を可能にします。これらは独立して検証および反論可能である必要があります。
メトリクス駆動型のインセンティブ、レスポンス時間、カバレッジ数、またはCVSSスループットであるかどうかにかかわらず、レコード品質に歪みの影響を与えます。最も頻繁に観察される特定の歪みは何ですか、そしてそれらのいずれかは、それらを生成している人に見えませんか？
量は品質ではありません。カバレッジとカウントが役に立たないわけではありませんが、たとえば、脆弱性レコードにCVSSベーススコアまたはCWE IDを持つことは、その情報が正確、正確、または有用であることを意味しません。測定しているため、測定している事柄に焦点を当てる傾向があります。測定値そのものが目標になることができます。
CVSSを考えてみてください。脆弱性リポジトリは通常、CVSSベーススコアとベクトルを提供し、近接した技術的重大度を伝えることを目的としています。これに表面的に間違ったことはありません。リポジトリは、リスク評価に必要なローカルでコンテキスト依存の情報を消費者に簡単に提供することはできません。消費者はこのコンテキストを提供する必要があり、これはおそらく近接した技術的重大度より重要です。しかし、比較的安価なCVSSベーススコア（「注意、9.8！」）に費やされた注意は、文脈を決定し、より全体的にリスクを評価する作業から注意をそらします。CVSSスコアを持つ脆弱性レコードをカウントしたり、CVSSベーススコアの分布を測定したりすることは可能ですが、それは役に立ちますか？
異なる言語ゲーム、定義、および過度に抽象的なメトリクスも歪みにつながります。同じ脆弱性情報を見ている2つの異なるが同様に適格なアナリストは、異なるCWE IDまたはCVSS Attack Complexity ベクトルでどうやって来ることができますか？今日使用している共通のアサーションの多くは、原子性と観察可能性のテストに失敗します。異なる意見は自然に発生し、これらのアサーションに基づくメトリクスは歪みます。
セキュリティコミュニティは、選別的に採用され、一貫性なく実装される優れた仕様を生成することの長い歴史があります。その結果を防ぐために、この提案について何が異なっていますか？
結果を保証することはできませんが、現在の実践の状態は持続不可能です。私たちは新しい仕様、優雅であるかどうかを起案しようとしていません。新しい形式、仕様、またはいくつかのフィールドは、私たちが直面している基礎的および哲学的な問題を解決するつもりはありません。私たちの仕事の前提は、まずより良い脆弱性リポジトリを設計および構築するための一連の原則と要件を開発する必要があるということです。おそらくその後、仕様を書くこと、新しいリポジトリを構築すること、または既存のリポジトリに変更を加えることの時間がきます。しかし、最初に堅い基礎が必要です。
翻訳元: https://www.helpnetsecurity.com/2026/04/13/art-manion-tharros-vulnerability-data-quality/
