[論文レビュー] On The Lag of Library Vulnerability Updates: An Investigation into the Repackage and Delivery of Security Fixes Within The npm JavaScript Ecosystem

Bodin Chinthanet, Raula Gaikovina Kula+3 more|arXiv (Cornell University)|Jul 8, 2019

Software Engineering Research被引用数 4

ひとこと要約

本研究は、npm JavaScriptエコシステムにおける脆弱性修正の更新遅延を調査し、2つの主要な遅延を特定した。1つ目は、関連しない変更と併せて修正をバンドルすることによるリパackaging遅延（83.33%のコミットが関連しない変更を含む）、もう1つは、クライアントがパッチ更新よりもマイナーアップデートを好むことによる配信遅延である。研究結果は、深刻度と下流の依存関係が修正の採用に影響を与えるが、パッケージの新鮮さは影響しないことを示しており、ソフトウェアエコシステムにおける修正の広がりを改善するための知見を提供する。

ABSTRACT

Vulnerabilities in third-party libraries is a growing concern for the software developer, as it poses risks not only to the software client itself but to the entire software ecosystem. To mitigate these risks, developers are strongly recommended to update their dependencies. Recent studies show that affected developers are not likely to respond to the vulnerability threat. However, another reason for the lag of vulnerability updates is due to slow repackaging (i.e., package the vulnerability fix into a new version) and delivery (i.e., affected client adopt the new version) of the fix. To understand these lags of updates, we use both qualitative and quantitative approaches to conduct an empirical study on how 188 fixes were repackaged and delivered across over eight hundred thousand releases of npm software clients hosted on GitHub. We report two lags: (1) lags in repackaging occur as vulnerability fixes are more likely to be bundled with other non-related updates (i.e., about 83.33\% of commits are not related to the fix) and (2) lags in the delivery are caused by clients that are more likely to adopt the minor fix than adopt the patch fix. Furthermore, other factors such as downstream dependencies and severity do have an impact. We also find that freshness of packages does not impact the amount of lags. The identification of these two lags opens up different avenues on how to facilitate faster fix delivery throughout a library ecosystem.

研究の動機と目的

• npm JavaScriptエコシステムにおける脆弱性修正の更新が遅れる根本的原因を調査すること。
• 脆弱性の公開と、その修正が新しいライブラリバージョンに再パackagedされるまでの時間的遅延を分析すること。
• 特にパッチ更新とマイナーバージョン更新の違いに注目し、クライアント側での脆弱性修正の採用パターンを検討すること。
• 深刻度、下流の依存関係、パッケージの新鮮さといった要因が更新タイミングに与える影響を評価すること。
• ソフトウェアライブラリにおける脆弱性修正の配信パイプラインにおけるシステム的ブottleneckを特定すること。

提案手法

• GitHubにホストされた80万件を超えるnpmクライアントリリースを対象に、188件の脆弱性修正に関する実証的調査を実施した。
• バージョンコントロール分析を用いて、脆弱性の公開と、その修正が新しいライブラリバージョンに再パックされるまでの時間的遅延を測定した。
• 修正リリース後のパッチ更新とマイナーバージョン更新の頻度を比較することで、クライアントの採用率を追跡した。
• 定性的および定量的分析を適用し、コミット内容を分類し、修正が関連しない変更と併せてバンドルされているかどうかを特定した。
• 深刻度レベルと下流の依存関係チェーンが更新タイミングに与える影響を評価した。
• パッケージの新鮮さ（初回リリースからの経過時間）が、リパックージングおよび配信遅延に与える影響を測定した。

実験結果

リサーチクエスチョン

• RQ1 脆弱性修正が公開された後、通常どれくらいの時間が経ってからその修正が新しいライブラリバージョンに再パックされるか？
• RQ2 リパックージングの過程で、脆弱性修正が関連しない変更とどれくらいの割合でバンドルされているか？
• RQ3 なぜクライアントは同じ修正についてパッチバージョン更新よりもマイナーバージョン更新を好むのか？
• RQ4 深刻度レベルと下流の依存関係は、修正の採用速度にどのように影響するか？
• RQ5 パッケージの新鮮さが、リパックージングまたは配信の遅延の大きさに影響を与えるか？

主な発見

• 脆弱性修正を含むコミットの約83.33%が、関連しない変更も含んでおり、セキュリティ修正のリパックージングが著しく遅延している。
• クライアントは、同じ脆弱性修正について、パッチバージョン更新よりもマイナーバージョン更新を2倍以上採用していることが判明し、非マイナーバージョンの採用が好まれていることが示された。
• 脆弱性の深刻度は、修正の配信速度に測定可能な影響を与えており、深刻度が高い問題はより速やかに採用されている。
• 下流の依存関係が更新タイミングに影響を与え、依存プロジェクトの数が多いライブラリは、より高い注目度のおかげで修正の採用が速やかに進んでいる。
• パッケージの新鮮さは、リパックージングまたは配信遅延の大きさに顕著な影響を及ぼさないことが判明し、新規パッケージが必然的に速やかに更新されるわけではないことが示された。
• 本研究は、2つの明確な遅延、すなわちリパックージング遅延と配信遅延を特定し、これらがnpmエコシステムにおける脆弱性への長期間の露出を引き起こしていることを明らかにした。