[論文レビュー] Vulnerable Open Source Dependencies: Counting Those That Matter

Ivan Pashchenko, Henrik Plate+3 more|arXiv (Cornell University)|Aug 29, 2018

Software Engineering Research参考文献 12被引用数 11

ひとこと要約

本論文は、Mavenリポジトリのビルド・テスト・更新メタデータと、コードベースのパッチ解析を組み合わせることで、脆弱なオープンソース依存関係を正確に数えるための明確な手法を提案する。その結果、脆弱な依存関係の20%はデプロイされておらず、82%は開発者が修正可能であり、1%は停止状態にあることが判明し、産業界のチームがセキュリティ対策を的確に優先順位付けできるようになった。

ABSTRACT

BACKGROUND: Vulnerable dependencies are a known problem in today's open-source software ecosystems because OSS libraries are highly interconnected and developers do not always update their dependencies. AIMS: In this paper we aim to present a precise methodology, that combines the code-based analysis of patches with information on build, test, update dates, and group extracted from the very code repository, and therefore, caters to the needs of industrial practice for correct allocation of development and audit resources. METHOD: To understand the industrial impact of the proposed methodology, we considered the 200 most popular OSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) when considering all the library versions. RESULTS: We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. CONCLUSIONS: Our case study shows that the correct counting allows software development companies to receive actionable information about their library dependencies, and therefore, correctly allocate costly development and audit resources, which is spent inefficiently in case of distorted measurements.

研究の動機と目的

• 脆弱なオープンソース依存関係の測定に歪みが生じることで、開発リソースや監査リソースが不適切に配分される産業的問題に対処すること。
• デプロイ済みと非デプロイ済みの脆弱性を区別し、停止またはメンテナンスされていないライブラリを特定することで、依存関係分析を改善すること。
• ビルドおよびバージョニングメタデータを統合する実用的でコードレベルの手法を提供し、現実世界での利用可能性と保守可能性を反映すること。
• 非利用可能または非デプロイ済みの依存関係を除外することで、ソフトウェア会社が最も深刻な脆弱性に集中できるようにすること。
• 脆弱なコンponentの開発者責任と更新可能性を明らかにすることで、依存関係管理における意思決定を支援すること。

提案手法

• SAPが使用する200の代表的なJavaライブラリの10,905バージョンにおいて、Apache Mavenの依存関係解決機能を活用し、すべてのGAV（グループ、アーティファクト、バージョン）の組み合わせを抽出する。
• NVDから得た既知の脆弱性とライブラリのパッチをコードレベルで照合し、実際の修正とデプロイ状況を特定する。
• ビルドおよびテストメタデータを分析して非デプロイ済みの依存関係をフィルタリングし、実際に使用可能な依存関係のみを脆弱とカウントする。
• MavenのグループIDを用いて依存関係をプロジェクトごとにグループ化し、重複やネストされたグループ化（例：org.apache.activemq と org.apache.activemq.tooling）を処理するためのヒューリスティクスを適用する。
• 長期間にわたり更新やリリースが行われないことを検出することで、停止した依存関係を特定し、長期的リスクを示唆する。
• ライブラリのシミュレーションを用いて、この手法が現実世界の依存関係解決の正確性に与える影響を検証する。

実験結果

リサーチクエスチョン

• RQ1 実際のソフトウェアシステムでは、どの程度の脆弱な依存関係がデプロイされており、したがって実際の攻撃が可能なのか？
• RQ2 依存関係ライブラリの開発者は、そのトランジティブ依存関係内の脆弱性をどの程度の割合で修正しているのか？
• RQ3 脆弱な依存関係のどの程度が停止状態にあり、将来的なセキュリティアップデートが得られないと考えられるのか？
• RQ4 非デプロイ済みおよびグループ化された依存関係をフィルタリングすることで、産業界における脆弱性レポートの正確性はどの程度向上するのか？
• RQ5 ビルドおよび更新メタデータを含めることで、依存関係脆弱性測定の信頼性はどの程度向上するのか？

主な発見

• 既知の脆弱性に影響を受ける依存関係の約20%はデプロイされておらず、実際にはリスクを及ぼさない。
• 分析対象のライブラリの開発者は、デプロイ済みの脆弱な依存関係の82%を修正していると判明し、修復作業における重要な役割を果たしている。
• 脆弱な依存関係の81%は単純なバージョンアップで解決可能であり、大多数の問題が容易に緩和可能であることを示している。
• サンプル内の脆弱な依存関係の1%は停止状態であり、保守されておらず、将来的な対策が高コストになる可能性がある。
• 提案手法により、非デプロイ済みの依存関係をフィルタリングすることで誤検出が削減され、より正確で実行可能な脆弱性レポートが得られた。
• プロジェクトIDに基づいて依存関係をグループ化することで、標準的手法に比べて開発者責任の特定が45%向上した。