Beyond CVE：複数のデータソース／自動化ツール／人間の専門知識を統合する戦略とは？

Beyond CVE: Building a Complete Vulnerability Intelligence Strategy

2025/07/09 DeepakGupta — 従来からの CVE 追跡には、膨大な数の重大な脆弱性を見逃す可能性がある。つまり、CVE データベースのみに依存するセキュリティ・チームは、危険な盲点に直面する。このガイドは、現実世界の脅威から組織を保護するための、包括的な脆弱性インテリジェンス戦略の構築方法を説明するものだ。

あるチームが、本番システム上で重大な脆弱性を発見した。CVE データベースを調査しても情報が得られず、ベンダーのアドバイザリを確認しても見つからなかった。それから３週間後に、研究者が把握したのは、その脆弱性は数か月前に GitHub アドバイザリで公開されていたが、CVE 番号が付与されていなかったという事実である。

このような状況は、多くのセキュリティ専門家が認識している以上に発生している。CVE システムは基盤的な仕組みではあるが、現代のセキュリティ・チームにとって必要な、脆弱性インテリジェンスのごく一部しか提供できない。

CVE Foundation について

Common Vulnerabilities and Exposures (CVE) システムは、脆弱性を追跡する上での基盤を構成するものだ。このデータベースを管理する MITRE Corporation が、それぞれの脆弱性に対して、一意の識別子を割り当てる。その CVE 番号は、セキュリティ欠陥に対する社会保障番号のようなものであり、さまざまなツールやチームが、同一の脆弱性について議論するための、普遍的な参照システムを構築する。

CVE エントリに含まれるものには、一意識別子／簡易な説明／追加情報源への参照などの基本情報がある。ただし、CVE エントリには、リスク評価に必要な深刻度スコアや、悪用のおける難易度、修復ガイダンスなどの重要な情報が欠けている。

この制約を踏まえて、脆弱性インテリジェンスにおける次のレベルへと進む必要がある。

国家による脆弱性データベース：コンテキストの追加

National Institute of Standards and Technology (NIST) が運営するものに、National Vulnerability Database (NVD) がある。この NVD は CVE エントリを収集し、Common Vulnerability Scoring System (CVSS) スコアに加えて、攻撃ベクター分析や影響評価などの実用的なデータの追加により、この仕組みを強化する。

CVSS スコアは、セキュリティ・チームが対応活動の優先順位を判断する際に役立つ。たとえば、CVSS スコアが 9.8 の脆弱性は即時対応が求められるが、スコアが 3.1 のものは次回メンテナンス時まで延期できるだろう。NVD が提供する情報には、攻撃の複雑さ／必要権限／機密性／整合性／可用性に対する、潜在的な影響に関する情報もある。

しかし、このように充実した情報を備える NVD にも欠落がある。CVE の割り当てプロセスには、数週間から数か月を要する場合があり、その期間には、脆弱性は存在するが、公式ドキュメントは存在しないという、危険なタイムラグが発生する。

商用の情報源

こうしたギャップを埋めるために、CVE 番号が付与されない脆弱性を追跡する、複数の商用データベースが存在する。Risk Based Security の VulnDB には 20万件以上の脆弱性が取り込まれているが、上記の CVE データベースには約 18万件しか登録されていない。その差が示唆するのは、従来の CVE 追跡で見逃されていた、数多くのセキュリティ欠陥の存在である。

VulnDB が重視するのは、即時性と網羅性である。また、Mobile アプリ／Webアプリ／特殊な産業システムといった、従来の CVE では無視されてきた製品の脆弱性も追跡している。さらに、各種の公式チャネルよりも迅速に通知を提供し、CVE の割り当てと比べて、数週間も早く通知することもある。

Offensive Security は、別の目的を持つ Exploit Database も管理している。CVE は脆弱性の存在を通知するものだが、その脆弱性を攻撃者が悪用する方法を、正確に示すものが Exploit Database である。このデータベースに取り込まれるのは、PoC エクスプロイト・コードと、悪用の手法に関する詳細な情報であり、現実世界のリスクに対するセキュリティ・チームの理解をサポートする。

オープンソースとベンダー固有の情報源

GitHub セキュリティ・アドバイザリは、脆弱性に関する情報開示の増加トレンドを象徴する存在である。セキュリティ問題を発見した、それぞれのオープンソース・プロジェクトは、GitHub に直接にアドバイザリを公開する。この手法により、開示サイクルは迅速化されるが、それらの情報は無数のリポジトリに分散してしまう。

Google の Open Source Vulnerabilities (OSV) データベースは、この分散化を解決しようとするものだ。OSV は複数のオープンソース・エコシステムからの脆弱性情報を集約し、脆弱性をバージョン番号だけでなく、それぞれのコード・コミットにマッピングするものだ。それがもたらす精度の向上により、セキュリティ問題を引き起こしたコードの変更や修正について、開発者たちは正確に情報を把握できる。

その一方で、大手のソフトウェア・ベンダーたちは、独自のセキュリティ・アドバイザリを発行しており、そこに取り込まれる詳細情報が、他所に掲載される情報を上回ることが多い。たとえば、Microsoft Security Response Center／Adobe Security Bulletins／Oracle Critical Patch Updates などは、自社製品の脆弱性に対して、詳細な回避策／修復手順などを提供している。

脆弱性インテリジェンスを再構築する新たなトレンド

いまの脆弱性インテリジェンス分野においては、自動化／人工知能の登場に加えて、新たな攻撃パターンの出現が、急速な変化を生み出している。セキュリティ専門家たちに推奨されるのは、それらのトレンドを理解し、将来の課題に備えることだ。

人間である研究者と比べて、現在の自動化された脆弱性検出ツールは、コード・リポジトリを継続的にスキャンし、素早くセキュリティ欠陥を発見する。この自動化により、機会と課題の両方がもたらされる。セキュリティ・チームは、潜在的な脆弱性について迅速な警告を受け取るが、その一方で、誤検知や優先度の低い発見という情報過多の状況に直面する。

SolarWinds に代表される、サプライチェーンへの攻撃は、依存関係の追跡へと重点を移している。現代のアプリケーションで用いられる、数百件にも及ぶサードパーティ製ライブラリにおいても、それぞれが独自の脆弱性プロファイルを持つという状況にある。その依存関係に取り込まれる脆弱性が、複数の下流アプリケーションに影響を与えるため、従来からの CVE 追跡では、この複雑性に対応することが困難となっている。

現在の機械学習システムは、研究者が脆弱性を発見する前に、それらが存在すると予測される場所を特定できるようになっている。これらのシステムが分析するのは、コードパターン／コミット履歴／開発者の行動などであり、それにより高リスクな領域を特定する。このアプローチは有望ではあるが、無数の予測結果に対する、人間による検証が必要となる。

リスク・スコアリングの進化

CVSS スコアは有用ではあるが、現実世界のリスクを正確に反映しないことがある。理論上の CVSS スコアが 9.0 の脆弱性であっても、悪用ツールが存在せず、影響を受けるシステムのリスクが限定的であれば、実際のリスクは最小限となるだろう。その一方で、CVSS スコアが Medium レベルの脆弱性であっても、活発な悪用キャンペーンの標的とされる場合には、早急な対応が求められるだろう。

脅威インテリジェンス・データを統合する、新しいスコアリング・システムは、このような限界に対処しようとするものだ。Exploit Prediction Scoring System (EPSS) は、対象となる脆弱性が、今後の 30日以内に悪用される確率を推定する。この確率的アプローチに依存するセキュリティ・チームは、理論上のスコアが高い脆弱性ではなく、実際に攻撃者が利用する脆弱性に集中できる。

Stakeholder-Specific Vulnerability Categorization (SSVC) は、意思決定に関する問いを提示するという、異なるアプローチを用いるものだ。それを採用する組織は、 “この脆弱性が悪用される確率は？”、”攻撃者にとっての有用性は？”、”自組織のシステムが危険に直面する可能性は？” といった質問を通じて、リスクに基づいた意思決定を下していく。つまり、数値スコアだけに頼らない、新たな思考回路が形成される。

インテリジェンス戦略の構築

効果的な脆弱性インテリジェンスにとって不可欠なものは、複数のデータソースの連携である。単一のデータベースだけでは、現代の脅威環境を完全には網羅できない。セキュリティ・チームが構築すべき戦略は、従来の CVE データ／商用インテリジェンス／ベンダー・アドバイザリ／脅威インテリジェンス・フィードを組み合わせるものになる。

まずは、テクノロジー・スタックと、関連するデータソースの、マッピングから開始すべきだ。主に商用ソフトウェアを使用する場合には、ベンダー・アドバイザリおよび従来の CVE ソースに重点を置くべきである。オープンソース・コンポーネントへの依存度が高い場合には、GitHub セキュリティ・アドバイザリおよび、OSV データを優先する必要がある。クラウド・ネイティブ環境では、従来のオンプレミス・インフラと異なるソースの参照が求められる。

データソースの拡張に伴い、自動化の導入が不可欠となる。複数のデータベース間において脆弱性データを手動で相関させる作業は、スケールが拡大するにつれて現実的でなくなる。セキュリティ・オーケストレーション・プラットフォームであれば、複数のソースからデータを集約し、重複を排除し、統合的なリスク評価を提供できる。

統合の課題と解決策

現代の脆弱性インテリジェンスにおける最大の課題は、異なる情報源間の統合にある。それぞれのデータベースごとに、形式／更新頻度／識別スキームは、異なるものとなる。さらに、１つの脆弱性に対して、CVE 番号／GitHub アドバイザリ ID／ベンダー独自のセキュリティ情報番号／商用データベースのエントリなどが関連付けられる場合がある。

脆弱性データへの標準化されたアクセス手段を提供する API が、この統合の課題を解決するだろう。CVE プログラムで導入されたのは、個々の CVE データへのプログラム的アクセスを可能にする CVE Services である。GitHub においてもセキュリティ・アドバイザリ用の API が提供され、大半の商用ベンダーも同様のインターフェイスを備えている。

セキュリティ・チームが優先すべきは、複数のデータ形式を処理し、異なる識別スキーム間で脆弱性を相関させる機能を備えたツールの導入である。それぞれの専門的なデータベースに、それぞれの脆弱性インテリジェンスが分散する現在において、この種の相関機能は不可欠な存在である。

人的要素

脆弱性インテリジェンスにおいて、自動化が存在感を示す一方で、依然として人間の持つ専門知識は不可欠である。データ収集および基本的な相関処理に優れる自動化システムだが、コンテキストやニュアンスの理解には限界がある。今後においてもセキュリティ専門家たちが担うべきは、脅威インテリジェンスの解釈／ビジネスへの影響評価に加えて、アルゴリズムでは代替できないリスクに基づく意思決定である。

効果的な脆弱性インテリジェンス・プログラムとは、自動データ収集と人的分析を組み合わせるものである。マシンがデータの集約と初期フィルタリングを担い、人間が戦略的な意思決定と複雑なリスク評価に集中する構成が望ましい。

実践的な次のステップ

セキュリティ専門家が行うべきは、自組織の脆弱性インテリジェンス・ソースの監査と、ギャップの特定である。数多くのチームが、従来からの CVE ソースだけに依存し、脆弱性の重要な部分を見逃している。手始めとして推奨されるのは、テクノロジー・スタックと関連するデータベースのマッピングであり、定期的な監視プロセスの確立である。

続いて検討すべきは、複数のソースからデータを集約し、統合的なリスク評価を可能とする、脅威インテリジェンス・プラットフォームの導入である。それらのプラットフォームは、数十種類におよぶデータベースやアドバイザリを監視するための、手作業を削減してくれる。

セキュリティ研究者やベンダーのセキュリティチームとの、良好な関係の構築も重要である。これらの関係性により、新たな脆弱性が公開される以前の段階で、早期警告を取得するという結果が生じる場合もある。セキュリティ・コミュニティは協力的であり、数多くの研究者たちが、非公式チャネルを経由して情報を共有している。

新たな脅威の出現や攻撃パターンの変化に応じて、脆弱性インテリジェンス分野は進化を続けている。複数のデータソースを理解し、それに応じて、戦略を柔軟に調整できるセキュリティ専門家は、複雑化する脅威環境においても、より効果的に組織を保護し得る。

ここでの重要な洞察は、技術的スキルと戦略的思考の双方を要する分野へと、脆弱性インテリジェンスが変化している点である。CVE フィードを、単に監視するだけの時代は終わりを告げた。現代のセキュリティ・チームが、進化する脅威に先行するために必要とするのは、複数のデータソース／自動化ツールに対して、人間の専門知識を統合する、包括的なインテリジェンス戦略である。

脆弱性を検出／修正する上で、CVE だけに頼るのでは、もはや不十分だという視点が述べられています。GitHub／商用データベース／ベンダーの情報などの、さまざまな情報源を組み合わせて現実的なリスクに対応すべきだと、この記事は指摘しています。よろしければ、カテゴリ Literacy も、ご参照ください。