對Java第三方庫使用、更新、風險的實證評估
1.研究介紹
第三方庫（Library）的使用，幫助我們不在重新造輪子，但與此同時也為項目（Project）帶來了異步風險。第三方庫延遲更新、很少更新、包含漏洞代碼等，都會為項目增加可能的攻擊面，同時第三方庫的修復、維護也需要項目開發者及時同步，從而避免不必要的風險。因此本文是從第三方庫的使用、更新、風險三方面出發，進行一個定量、全面的研究，從而為 JAVA 生態做出一些貢獻。本文主要聚焦于以下三個問題，并同時提出了一個原型系統來對問題研究結果進行驗證。
- RQ1：使用分析，Library 的使用強度與時效。
- RQ2：更新分析，Library 的更新強度與延遲。
- RQ3：風險分析，使用和更新過時 Library 的潛在風險。
文章為了更好的展現研究的真實性，通過數學方式定義了多個指標，并且通過其對真實 JAVA 生態情況進行了量化分析。本文主要選用的是 200 stars 以上的 Java 項目（最終 1828 個）
2.使用分析
文章從使用強度、使用過時兩方面來進行研究。
圖 1 跨項目和庫的使用強度分布
使用強度：
經研究發現，74(9.2%) 的項目沒有調用庫的 API，265(32.9%) 的項目調用庫 API 比例不超過 10%，266(33.0%) 和 64(7.9%) 的項目調用庫 API 分別超過 20% 和 40%。由此可見，項目通常對庫的 API 是存在依賴性的，但同時庫的開發人員也可以根據此信息進行 API 的調整。
圖 2 跨項目和庫的使用過時分布
使用過時：
研究表明，82(10.3%) 項目使用的庫平均最多與最新版本相差兩個版本。306(38.0%)、118(14.6%) 和 19(2.4%) 個項目采用的庫分別與最新版本平均相差超過 10、20 和 50 個版本。可以看到幾乎所有的項目使用的都是過時的版本，因此這方面必然會存在功能和安全性的差距。
3.更新分析
文章定義了更新強度、更新延遲兩個概念來進行研究。
圖 3 跨項目和庫的更新強度分布
更新強度：
89(11.0%) 和 329(40.8%) 個項目分別更新了最多 20% 和 50% 的當前聲明的庫依賴項。354(43.9%) 和 101(12.5%) 個項目分別更新了超過 50% 和 80% 的當前聲明的庫依賴項。另一方面，4,414(32.5%) 個庫在所有依賴它們的項目中從未更新過。可以看到項目的更新強度不高，盡管項目維護良好，但更新相當差。
圖 4 跨項目和庫的更新延遲分布
更新延遲：
186(23.1%) 項目最多延遲 30 天更新其庫依賴項。407(50.5%)、256(31.8%) 和 174(21.6%) 個項目的更新延遲分別超過 60、120 和 180 天。13.3% 個項目未包含在圖 5a 中因為其無法計算更新延遲（即，90 個項目從未更新任何庫依賴項；17 個項目更新了庫依賴項，但我們未能抓取發布日期）。項目開發人員對新庫的發布反應遲緩。如此寬的時間窗口可能會增加使用過時庫的風險（例如，安全漏洞），甚至會增加更新到新版本的難度，因為在此時間窗口內將使用更多的庫 API。
4.風險分析
文章定義了使用風險、更新風險兩個概念來進行研究。
圖 5 跨項目和庫版本的使用風險分布
451(56.0%) 個項目采用有缺陷的庫版本。328(40.7%) 個項目采用 1 到 5 個有缺陷的庫版本，128(15.3%)個項目甚至使用超過 5 個有缺陷的庫版本。在 25.7% 項目中，他們使用的有缺陷的庫版本有 1 到 5 個安全漏洞。在 188(23.3%) 項目中，他們使用的 bug 庫版本甚至有超過 10 個安全漏洞。超過一半的項目使用包含安全漏洞的庫版本。三分之二的庫版本包含安全漏洞。安全漏洞的相對普遍存在表明，如果項目開發人員沒有意識到使用庫中的安全漏洞或延遲庫更新，項目將面臨潛在風險。
在采用有 bug 的庫版本的 451 個項目中，有 151(33.5%) 項目沒有在使用過的有 bug 的庫版本中調用 API，181(40.1%) 項目最多調用 20 個 API，82(18.2%) 項目調用超過 40 個 API。此外 4,236(35.3%) 個有缺陷的庫版本在安全版本中刪除了 300 多個 API。API 的使用需要及時關注，可能存在安全風險。開發人員應當及時關注庫 API 的修改情況。
5.個人思考
- 當下 Java 生態或者說其他軟件包供應鏈生態中，往往可能由于代碼量大，研究人員代碼更新等情況而存在大量的未使用第三方庫，這對于軟件工程來說是一個值得研究的問題。
- Java 代碼安全性和漏洞傳播也是值得研究的點（尤其 Java 的反射機制可能會有一些研究價值？）。
- Java 包臃腫問題近些年確實有一些研究，這方面同樣還有一些提升的空間。
