Log4j2漏洞背后是全球軟件供應鏈風險面臨失控
前言
Log4j2作為java代碼項目中廣泛使用的開源日志組件，它的一個嚴重安全漏洞對于全球的軟件供應鏈生態來講不亞于一場新冠病毒的影響，任何企業的代碼項目沾上它都有可能給企業帶來致命的安全風險。
全球新一輪的產業數字化升級對開源軟件的依賴日益提升，從而催生開源生態的蓬勃發展，而開源軟件的全球化和開放共享的特性使得任何一個非常底層和基礎的開源組件的漏洞都有可能像一個新冠病毒一樣快速傳播，對全球的數字化產業帶來無法估量的影響。而這種影響的持續時間可能是3～5年，甚至更長。
比新冠病毒更可怕的是，像Log4j2這樣的基礎組件其實還有很多，它們出現安全漏洞的概率可遠遠要比新冠病毒的概率要高的多。我們來看一組數據：
- Log4j2的依賴血緣：我們統計了1～4層的依賴血緣關系，直接和間接Log4j2的開源組件總計有17萬個，也就是說有至少17萬個開源組件是受Log4j2漏洞影響。
- GitHub作為全球最大的開源代碼托管平臺，抽樣分析發現至少5.8%的java開源項目受該漏洞影響。
- 截止目前，距離官方第一次發布修復版本已近一周時間，GitHub上還有89%的受影響項目仍然沒有修復。
- 在java語言的開源組件流行度排行中，Log4j2列第13位，也就意味著至少存在幾十個這樣的高影響度組件，一旦爆發漏洞，實際帶來的影響都是類似的。
這樣一組數據背后意味的是什么？是失控。這樣的失控讓我們不禁要思考，全球開源軟件供應鏈生態風險控制體系是嚴重缺失的，開源軟件蓬勃發展的背后似乎潛藏著巨大的危機，從軟件供應鏈的生產商、分發平臺、企業應用方其實都缺乏足夠的風險意識和控制能力，這無疑會給企業和企業用戶的信息安全帶來非常大的潛在風險。
一、關于Log4j2漏洞對開源生態的影響分析
01其他開源組件的依賴
我們對log4j2的1～4層依賴關系進行了統計分析，可以發現直接依賴log4j2的組件有6921個，第二層依賴有超過3萬個，第三層有超過9萬個，第四層有超過16萬個，總共有超過173104個組件。
將其繪制成圖的形式進行展現，可以直觀地發現右上黑色點的log4j2不光自身影響的組件多，還間接影響到了很多其他的熱門組件，例如中間黃色點的elasticsearch和綠色點的druid，以及左上紫色點jedis、左下紅色點mybatis均被大量引用。
02java應用項目的影響
通過對GitHub和Gitee中的應用級項目依賴進行統計，我們發現約有5.8%的java項目直接使用了log4j2。篩選star大于1000的「高星」項目，其中約有13.3%直接使用了log4j2。
在GitHub中有人創建了項目來展現本次漏洞對企業和項目的影響（https://github.com/YfryTchsGD/Log4jAttackSurface），其公開的列表中包括許多知名的公司和軟件，如：
- Apple
- VMWare
03修復方案的選擇
通過在GitHub中針對本次漏洞主要存在的三種修復方案進行統計發現：
- 絕大部分的開發者選擇通過升級新版本進行漏洞修復
- 少部分項目通過將formatMsgNoLookups設置為False修復
- 極少項目選擇了將jar包中的JndiLookup類移除
04修復的時效性
通過對GitHub上的受影響項目統計，截止當前仍有89.4%的開源項目未修復。作為頂級基金會，也是本次漏洞的「當事人」，Apache基金會管理了超過1000個java項目，其中仍有33.4%未修復。
二、 全球開源軟件生態的健康發展亟需加強安全建設
作為整個開源軟件生態的主要參與者，包括生產方（供應商）、分發方（開源代碼平臺、鏡像托管平臺、云廠商等）、使用方（企業和組織），目前在開源組件的安全控制上都需要加強投入，將開源組件的依賴管理、風險識別、缺陷修復納入整個開源組件的生產、分發和應用的全過程，并且建立突發安全事件的應急處置機制和配套的工具平臺。才能有效的保障一旦這樣存在廣泛影響的組件漏洞出現，能夠及時的控制風險，降低對整個供應鏈上下游所帶來的影響。
- 從生產方來講，大規模被使用的開源組件應該建立漏洞應急處置的標準和要求，出現漏洞后及時發布修復補丁，且應該建立有效的觸達受影響用戶的渠道，及時通知用戶進行修復，而此次事件的主角Log4j2組件僅僅只是三個開發者業余時間維護的項目。
- 從分發方的角度，以開源代碼托管平臺為例，在出現如此大的通用組件漏洞的情況下，應該具備更好的管控機制，及時有效的幫助開發者快速修復漏洞，并且在漏洞沒有修復之前提示開發者謹慎下載相關有風險的開源項目代碼。對于新發布到托管平臺的項目應該進行風險的校驗，降低有缺陷的開源組件發布，有效降低風險擴散。
- 從使用方的角度，企業和組織應該加入在組件引入、使用、上線的全過程管控，做好內部軟件供應鏈的資產管理，做到全過程可追蹤，風險能夠及時響應和處置。
很顯然從Log4j2漏洞事件的爆發和目前的影響來看，這些方面此次事件的官方項目組和國際主流的開源代碼分發平臺做的并不夠好，反觀這一次國內的官方組織、安全研究人員、企業、安全廠商卻在此次事件中發揮了非常積極主動的作用，紛紛給出預警和漏洞檢查工具。
三、 作為企業應該如何有效控制所使用的軟件供應鏈存在的安全風險
墨菲安全認為，可以從以下四個方面著手：
- 建立有效的管理機制：第三方軟件供應鏈資產和風險管理本身可以做到很高的標準化，如同項目代碼的bug率管理一樣，企業應該將三方軟件供應鏈的缺陷管理納入研發的日常管理指標，同時提供配套的安全工具給予支撐。
- 供應鏈資產的識別和管理：從引入第三方供應鏈軟件開始，建立持續的軟件供應鏈資產管理平臺，對企業辦公及生產環境所有使用的軟件供應鏈資產做到實時和動態的管理，資產要和具體的軟件項目、員工做好關聯，并建立配套的安全管理制度及配套工具平臺，做到風險的持續量化管理。
- 漏洞缺陷的檢測：針對識別的第三方軟件供應鏈資產，應該在軟件全開發流程中做好漏洞的檢測，及時有效的發現存在的漏洞。特別需要關注的是漏洞和組件的匹配準確度和覆蓋率，因為大多數外部漏洞庫并沒有給出準確的漏洞影響范圍信息，這使得漏洞準確檢測的難度大大提升。
- 高效的修復能力支撐：對于企業來說當前最難的問題應該是如何快速的修復這些漏洞，企業應該考慮如何將安全能力低侵入的融合到企業的開發流程中去。
建議
墨菲安全結合過往近十年的企業安全建設經驗給出幾點建議：
- 第三方組件的風險識別應該從組件引入環節開始做好控制，包括禁止高危組件的引入、將漏洞檢測插件默認集成到開發者的IDE中；
- 需要在軟件構建、測試、部署的全流程中集成三方軟件的檢測和修復能力；
- 持續獲取三方組件最新漏洞情報；
- 盡可能的將安全的修復方案做的足夠簡單，這樣和研發人員一起推進修復的時候才能更高效。
