文 | 局長
出品 | OSC開源社區（ID：oschina2013）
來自 Google Open Source Insights Team 的安全研究人員通過調查 Maven Central 中所有軟體包的所有版本，以更好地了解最近曝出的 Log4j 漏洞對整個 JVM 語言生態系統的影響，同時還跟蹤了正在進行的緩解受影響軟體包的作業，
研究人員發現，截至 2021 年 12 月 16 日，來自 Maven Central 的 35,863 個可用軟體包依賴于存在漏洞的 log4j 代碼，這意味著 Maven Central 上超過 8% 的軟體包至少有一個版本受漏洞影響（此數字不包括所有 Java 軟體包，例如直接分發的二進制檔案）
就生態系統影響而言，8% 是相當巨大的數字，因為對 Maven Central 生態的平均影響數值為 2%，中位數則低于 0.1%，
如記錄漏洞的 CVE 所述，大多數受影響的軟體包來自間接依賴項（即自身依賴項的依賴項），也就是說它們沒有將 log4j 明確定義為依賴項，而是作為傳遞依賴項被引入進來，
這正是 JVM 生態整體上修復此漏洞例外困難的原因，安全研究人員稱，在撰寫文章時，只修復了近五千個受影響的軟體包，還有 30000 多個軟體包會受到漏洞的影響，
簡單來說就是，漏洞在依賴關系鏈中嵌套得越深，修復漏洞所需的步驟就越多，下圖顯示了受影響的 log4j 包（核心或 api）首次出現在依賴圖中的深度的直方圖，對于超過 80% 的軟體包，該漏洞的深度超過一級，其中大多數受影響的級別下降了 5 個級別（有些甚至下降了 9 個級別），這些包將需要在依賴樹的所有部分進行修復，而且首先從最深處的依賴關系開始，
修復漏洞的另一個困難之處由決議演算法 (resolution algorithm) 和需求規范約定中生態系統層級的選擇引起，
在 Java 生態中，開發者通常的做法是指定軟體版本方面的“軟”要求——假設沒有其它版本的相同包出現在依賴關系圖中，決議演算法會使用指定的明確版本，對于此類修復，通常需要維護者采取更加明確的行動，以將依賴需求更新為修補后的版本，這種做法與其它生態形成了鮮明的對比，例如在 npm 軟體包中，開發者通常會為依賴項指定開放范圍，開放范圍允許決議演算法選擇滿足依賴性要求的最近發布的版本，從而引入新的修復，
最后，對于整個生態需要耗費多少時間來完成漏洞修復，目前也很難評估，在查看了所有公開披露的受影響 Maven 軟體包中，安全人員發現只有不到一半（48%）得到了修復，
參考：https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.勁爆！Java 協程要來了，，，
3.玩大了！Log4j 2.x 再爆雷，，，
4.Spring Boot 2.6 正式發布，一大波新特性，，
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/394920.html
標籤：Java