
オープンソースプロジェクトからのVulnerability Exploitability eXchange(VEX)ドキュメントを集約します。自動セキュリティツール統合のためにPURLで整理します。

VEX Hubは、さまざまなオープンソースソフトウェアプロジェクトから Vulnerability Exploitability eXchange(VEX) ドキュメントを収集・管理する集中リポジトリです。 脆弱性情報の包括的なリソースとして機能し、ユーザーやセキュリティツールが複数のプロジェクトやエコシステムにわたってVEXデータへ効率的にアクセス・活用できるようにします。
VEX Hubは、登録されたプロジェクトのソースリポジトリからVEXドキュメントを自動的に取得します。 登録された Package URL(PURL) からソースリポジトリを特定することで、VEX HubはVEXドキュメントをコピーして整理し、広範なコミュニティが簡単にアクセスできるようにします。
これだけです! VEX Hubが自動的にVEXドキュメントを取得して処理します。
VEX Hub Crawler は、登録されたパッケージのVEXドキュメントを定期的にクロールし、VEX Hubで管理します。 登録パッケージは、PURL のリストとして ファイル に定義されており、誰でもPull Requestを通じて更新できます。
PURLの登録、対応エコシステム、具体的な要件の詳細については、VEX Hub Crawler を参照してください。
packagesファイルはクロール対象パッケージのPURLのみを指定し、VEX Hub CrawlerがVEXファイルが置かれているソースコードリポジトリを自動的に特定します。 ソースリポジトリの特定方法はエコシステムによって異なります。さまざまなパッケージタイプについてソースリポジトリがどのように特定・クロールされるかの詳細は、vex-crawlerのドキュメント を参照してください。
ソースコードリポジトリを特定した後、VEX Hubはその中のVEXドキュメントを自動的に検出します。検出プロセスには次の重要なポイントがあります。
.vex/ ディレクトリ内で検索されます。*.vex.json、*.csaf.json)に一致するファイル名が対象となります。検出プロセス、対応エコシステム、具体的な要件の詳細については、vex-crawlerのドキュメント を参照してください。
VEX Hubは、version、qualifiers、subpath を除いた Package URL(PURL)に基づいて構成されています。
構造は以下のルールに従います。
oci の場合は、代わりに repository_url 修飾子が使用されます。products フィールド内で指定する必要があります。ディレクトリ構造の形成例:
pkg:npm/express → /npm/express/pkg:golang/github.com/gorilla/mux → /golang/github.com/gorilla/mux/pkg:maven/org.apache.xmlgraphics/batik-anim → /maven/org.apache.xmlgraphics/batik-anim/pkg:oci/trivy?repository_url=ghcr.io/aquasecurity/trivy → /oci/ghcr.io/aquasecurity/trivy/特殊文字エンコーディングの例:
pkg:npm/@angular/core → /npm/%40angular/core/VEX Hubは VEX Repository Specification に準拠しています。vex_repository.json および index.json ファイルを使用すると、VEX Hub内のVEXドキュメントにプログラムからアクセスできます。
VEX Hubは、ソースリポジトリから一致するすべてのVEXドキュメントをコピーするため、単一のPURLに対して複数のVEXドキュメントを格納できます。 ただし、VEX Repository Specificationでは、PURLごとに1つのVEXドキュメントのみが許可されます。 この仕様に準拠するため、VEX Hubは次の配布戦略を実装しています。
index.json に書き込みます。混乱を防ぎ一貫性を確保するため、同じPURLに対するVEXステートメントを複数のファイルに分割することは推奨されません。VEX HubはPURLごとに1つのVEXファイルのみを配布するためです。
推奨される方法は次のとおりです。
シナリオ例:
GoモジュールとOCIイメージの2つの製品を管理するソースリポジトリ https://github.com/org/repo を考えます。
1つ目の方法は、両方の製品のVEXステートメントを含む単一のVEXファイル vex.json を作成することです。
openvex.json: 両方の製品向け。PURLは pkg:golang/github.com/org/repo、pkg:oci/repo?repository_url=docker.io/org/repo、pkg:oci/repo?repository_url=ghcr.io/org/repo2つ目の方法は、製品ごとに個別のVEXファイルを作成することです。
golang.vex: Goモジュール向け。PURLは pkg:golang/github.com/org/repooci.vex: OCIイメージ向け。PURLは pkg:oci/repo?repository_url=docker.io/org/repo および pkg:oci/repo?repository_url=ghcr.io/org/repo次の構造は推奨されません。
v1.vex: Goモジュール向け。PURLは pkg:golang/github.com/org/[email protected]v2.vex: Goモジュール向け。PURLは pkg:golang/github.com/org/[email protected]この例では、配布用に v1.vex が選択され、v2.vex は無視されます。
これらは、複数のバージョンとqualifiersを持つ単一のVEXファイル golang.vex に結合する必要があります。
VEX Hub(および一般にVEX)はセキュリティスキャン結果を補強する可能性があるため、利用するVEXドキュメントの正確性を吟味することは正当な姿勢です。他の脆弱性交換フィードやVEX対応のセキュリティアドバイザリフィードとは異なり、VEX HubはVEXステートメントのデータ ソース ではありません。VEX Hubは既存のVEXドキュメントを集約し、中央の便利なリポジトリに整理するだけです。
VEX Hubに掲載されるためには、まずVEXドキュメントをメインパッケージのソースコードリポジトリにコミットする必要があります。このアプローチは、ユーザーとして、使用するパッケージとそのメンテナー、ガバナンス、そして彼らが採用するプロセスをすでに信頼しているという事実に基づいています。各プロジェクトには独自のガバナンスシステムと、ソースコードリポジトリへコミットするための独自のプロセスがあります。あなたの目にパッケージコードを信頼できるものとしているそのシステムとプロセスは、VEXドキュメントをあなたにとって信頼できるものにするのと同じシステムとプロセスです。 VEX Hubを、あなたが使うことにしたパッケージ以上に信頼すべきではありません。
VEX Hubは、保持するVEXドキュメントやそれらが記述するパッケージの内容について、一切の責任や知識を持ちません。VEX HubのメンテナーはVEXドキュメントの内容をレビューまたは精査しません。情報の正確性と正当性に関する責任は、元のパッケージメンテナーにあります。ユーザーは、他の脆弱性と同様に、抑制された脆弱性を手動でトリアージすることをお勧めします。
登録されたPURLのソースリポジトリ内のVEXドキュメントがVEX Hubで適切に更新されない場合は、以下を確認してください。
.vex/ ディレクトリ)に配置されていることを確認します。これらの点を確認しても問題が解決しない場合は、VEX Hubリポジトリにissueを開いてサポートを依頼してください。
VEX Hubを改善するためのコントリビューションを歓迎します! パッケージリストと関連コードは VEX Hub Crawlerリポジトリ で管理されていることに注意してください。 このリポジトリにVEXドキュメントを直接追加するPull Requestは推奨されません。 このプロジェクトと参加者は全員、Aqua Security Code of Conduct に従います。