[论文解读] 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生态系统中漏洞修复更新的延迟问题，识别出两个关键延迟：由于将修复与无关更改捆绑在一起导致的重新打包延迟（83.33%的提交包含无关更改），以及客户端更倾向于采用小版本更新而非补丁版本更新的交付延迟。研究发现，严重程度和下游依赖关系会影响修复的采纳，但包的新鲜度不会，为改善软件生态系统中修复传播提供了洞见。

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生态系统中漏洞修复更新延迟的根本原因。
• 分析从漏洞披露到修复被重新打包进新库版本之间的时间延迟。
• 检查客户端对漏洞修复的采纳模式，特别是补丁版本与小版本更新之间的差异。
• 评估严重程度、下游依赖关系和包新鲜度等因素对更新时间的影响。
• 识别软件库漏洞修复交付流程中的系统性瓶颈。

提出的方法

• 对托管在GitHub上的800,000多个npm客户端发布版本中的188个漏洞修复进行了实证研究。
• 通过版本控制分析，测量从漏洞披露到修复被重新打包进新库版本之间的时间延迟。
• 通过比较修复发布后补丁版本与小版本更新的频率，追踪客户端采纳率。
• 采用定性和定量分析对提交内容进行分类，确定修复是否与无关更改捆绑在一起。
• 评估严重程度等级和下游依赖链对更新时间的影响。
• 测量包新鲜度（即首次发布以来的时间）对重新打包和交付延迟的影响。

实验结果

研究问题

• RQ1 漏洞修复在披露后，通常需要多长时间才能被重新打包进新版本的库中？
• RQ2 在重新打包过程中，漏洞修复与无关更改捆绑的程度有多大？
• RQ3 为何客户端更倾向于采用小版本更新而非相同修复的补丁版本更新？
• RQ4 严重程度和下游依赖关系如何影响修复采纳的速度？
• RQ5 包的新鲜度是否会影响漏洞修复的重新打包或交付速度？

主要发现

• 约83.33%包含漏洞修复的提交还包含无关更改，显著延迟了安全修复的重新打包。
• 客户端采纳小版本更新的可能性是采纳补丁版本更新的两倍以上，表明其更偏好非补丁更新。
• 漏洞的严重程度对修复交付速度有可测量的影响，严重程度越高，修复被采纳得越快。
• 下游依赖关系会影响更新时间，因为依赖项目更多的库会因受到更多关注而更快采纳修复。
• 包的新鲜度对重新打包或交付延迟的大小无显著影响，表明新发布的包并不会因此更新得更快。
• 本研究识别出两个独立的延迟——重新打包延迟和交付延迟——二者共同导致npm生态系统中漏洞暴露时间延长。