技術サマリー：ARVO – オープンソースソフトウェアのための再現可能な脆弱性アトラス

1. 問題提起

本論文は、脆弱性データセットにおける決定的な「三方向のトレードオフ」を特定している。それは、再現性、量、および多様性である。歴史的に、量と多様性を高めることは、再現性の犠牲の上に成り立ってきた。GoogleのOSS-Fuzzやその派生であるOSS-Fuzz-OSVといった既存の大規模なデータセットは、深刻な再現性の失敗に直面している。

特定された主な問題は以下の通りである：

• ビルドの失敗： 比較評価において、OSS-Fuzzの過去の脆弱なバージョンは、依存関係のドリフト、ビルドシステムのビットロット（腐敗）、およびリソースの欠落により、63%がビルドに失敗した。
• 低い再現率： OSS-Fuzzに基づく既存の自動化技術（例：OSS-Fuzz-OSV）は、脆弱性の約37%しか再現できていない。
• データの不正確さ： 既存のデータセットのメタデータにはエラーが含まれていることが多い。著者らは、OSS-Fuzzの10,440件のレコードのうち、1,518件の誤った脆弱性データ（例：クラッシュや修正に関するもの）を発見した（14.5%のエラー率）。
• グラウンドトゥルース（正解）の欠如： 再現可能な環境とトリガーとなる入力がなければ、ダウンストリームのセキュリティ研究（自動パッチ生成や動的解析など）は妨げられる。研究者は、パッチが実際にバグを修正したのか、あるいは脆弱性が本当に存在しているのかを検証することができない。

2. メソドロジー

著者らは、大規模かつ再現可能で多様な脆弱性データセットを生成するために設計されたフレームワークであるARVO（Atlas of Reproducible Vulnerabilities in Open-source software）を提案している。ARVOは、そのReproducer（リプロデューサー）とPatch Locator（パッチロケーター）コンポーネントに実装された3つのコア戦略を通じて、歴史的なソフトウェアバージョンの復活という課題に対処する。

2.1. Reproducer（リプロデューサー）

リプロデューサーは、アップストリームのメタデータ（OSS-Fuzzから取得）を受け取り、ソースからソフトウェアの脆弱なバージョンと修正済みのバージョンの両方を再構築しようと試みる。ビルドの失敗を克服するために、ARVOは以下を採用している：

• 最小限の侵襲的なビルド・インストルメンテーション： ビルド環境が準備された後にコンテナの外でソースコードを入れ替えるOSS-Fuzzとは異なり、ARVOはビルドプロセス中にリソースダウンロードコマンドをフックする。これにより、自然なビルドフローを維持し、依存関係が正しく取得されることを保証する。
• 包括的なリビジョン管理： ARVOは、メインプロジェクトだけでなく、すべての依存関係に対してバージョン管理を強制する。特定のメインコンポーネントのコミット時点における最も新しい互換性のある依存関係バージョンを選択するために、コミットタイムスタンプを使用し、APIのミスマッチを防ぐ。
• 欠落リソースの修正： ARVOは「ビットロット」に対する検出・修正ループを維持している。欠落しているリソースをコア（コンパイルに必要）または非コア（例：ファジング用のシード）に分類する。ARVOは、非コアリソースをスキップするようにコマンドを自動的に修正し、コアリソースを修正（例：移行されたリポジトリからの壊れたURLの更新）するための再利用可能なルールを適用する。

2.2. Patch Locator（パッチロケーター）

脆弱性が再現可能になると、ARVOはそれを修正する正確な開発者パッチを自動的に特定する：

• コミット二分探索（Bisection）： ARVOは、脆弱性の発見と修正の検証の間のコミット範囲に対してバイナリサーチ（二分探索）を実行する。
• 依存関係を考慮した二分探索： 二分探索中、ARVOはタイムスタンプを使用して、各候補コミットに対して互換性のある依存関係バージョンを動的に選択する。中間地点が依存関係の問題でビルドに失敗した場合、検索を継続するために隣接するコミットへステップを進める。
• フォールバックメカニズム： ビルド失敗が多すぎて二分探索が停滞した場合、線形探索へとフォールバックする。ただし、これは計算コストが高くなる。

2.3. データセットの構築

ARVOはOSS-Fuzzからデータをインジェストし、セキュリティに関連する問題（Type=Bug-Security, label:Reproducible, status:Verified）をフィルタリングする。出力されるのは以下の通りである：

• Dockerイメージ： 各プロジェクトの脆弱なバージョンと修正済みのバージョンの両方のための、事前構築済みコンテナ。
• トリガリング入力： クラッシュを確実に引き起こすProof-of-Concept（PoC）入力。
• パッチメタデータ： 脆弱性を修正する特定のコミットハッシュ。

3. 主な貢献

1. 新しいデータセットのパラダイム： これまで大規模には達成されていなかった、再現性、量、および多様性の組み合わせを実現するセキュリティデータセットの導入。
2. 再現性のためのソリューション： 大規模なバグ再現における主要な障害、具体的には依存関係のバージョン管理、欠落リソースの処理、および非侵襲的なビルド・インストルメンテーションの特定と緩和。
3. 自動パッチ特定： コミット二分探索を通じて正確な修正コミットを自動的に特定できるシステムであり、これは既存の大規模データセットには欠けている能力である。
4. ARVOデータセット： 311のプロジェクト（C/C++）にわたる6,138件の実世界の脆弱性からなる具体的なデータセットであり、関連するDockerイメージとメタデータが付随している。

4. 結果と評価

• 再現成功率： ARVOは、試行された脆弱性の81%（初期候補8,921件中6,138件）の再現に成功した。これは、最先端技術（OSS-Fuzz-OSVの約37%）と比較して44パーセントポイントの向上である。
• パッチの正確性： 自動的に特定されたパッチは、手動検証において89.4%の精度を達成した。これは、重複するケースにおけるOSS-Fuzz-OSVの82.9%の精度を上回っている。
• アップストリームへの影響： ARVOをアップストリームのデータと照合することで、著者らは、OSS-Fuzzによって修正済みと誤ってマークされていたものの、実際にはパッチが適用されていなかった300件以上の脆弱性、およびアップストリームデータ内の1,519件の偽陽性を特定した。
• スケーラビリティ： ARVOは、従来の手法が失敗した複雑なマルチコンポーネントプロジェクト（例：15以上の依存関係を持つImageMagick）を処理できる。

5. 意義と主張

本論文は、ARVOが静的な脆弱性レポートをインタラクティブで検証可能なアーティファクトへと変貌させると主張している。その意義は以下の点にある：

• ダウンストリーム研究の促進： 自動パッチ生成、脆弱性発見ツール、および機械学習モデル（例：DARPAのAI Cyber Challengeで使用されるもの）のための信頼できる基盤を提供すること。
• アップストリーム品質の向上： 再現性が、アップストリームのデータセット（OSS-Fuzzなど）をクリーンアップするためのフィードバックループとして機能し、偽陽性を修正し、未修正の脆弱性を特定できることを実証したこと。
• ギャップの解消： 手動でキュレーションされたデータセット（Magmaなど）の「陳腐化」と、純粋に自動化されたコレクション（OSS-Fuzz-OSVなど）の「信頼性の低さ」の両方を超え、大規模でありながら厳格に再現可能なデータセットを提供すること。

著者らは、ARVOは現在のアップストリームの限界に対する緩和策であるが、その究極の目標は、再現性をセキュリティデータセットの標準的な特性として確立することであり、アップストリームがネイティブにサポートすれば、個別のARVOフレームワークは不要になる可能性があると強調している。フレームワークとデータセットは、さらなる研究を促進するためにオープンソース化されている。