深度洞察 |關於JavaScript開源生態中安全漏洞傳播及其演變分析

語言: CN / TW / HK

本文主要介紹Scantist科研團隊近期在軟體工程頂會International Conference on Software Engineering(CSE)2022中接收的一篇關於 JavaScript包管理器NPM生態中軟體安全漏洞的傳播及其演變分析的工作《Demystifying the Vulnerability Propagation and Its Evolution via Dependency Trees in the NPM Ecosystem》。

此工作基於Scantist獨家的開源生態資料做了一個系統化安全分析,希望給開源社群的安全治理提供更多的見解和思路。

一、研究背景及動機

隨著第三方元件在軟體開發過程中的廣泛使用,如何妥善管理第三方元件中引入的安全漏洞所帶來的安全風險,尤其在2021年12月log4j RCE漏洞和2022年3月Spring框架遠端命令執行漏洞事件爆發之後,成為DevSecOps過程中廣受關注的問題之一。其中,關於安全漏洞的影響傳播,特別是在如NPM這種大規模使用第三方元件的軟體生態中,顯得尤為重要。

在已有的相關工作中,研究人員主要通過兩種方式分析依賴中存在的安全漏洞對使用者專案的影響。

  1. 通過直接依賴關係反向追蹤含有漏洞元件的下游使用者
  2. 基於依賴關係進行間接依賴的可達性分析

然而,這兩種依賴關係均忽視了NPM生態中軟體包安裝過程中上下文環境對依賴版本選擇的影響,從而無法精準地得到安全漏洞在生態中真實的影響範圍。

如下圖所示,直接以間接依賴的可達性分析,則存在[email protected]>[email protected]>[email protected]>[email protected]的間接依賴鏈 ,如圖(b)。

而根據NPM的依賴解析規則,由於[email protected]的直接依賴中已經解析並選擇了[email protected],而[email protected]亦滿足[email protected]>D的依賴約束範圍,此時應直接選擇已有的[email protected]而不是重新安裝[email protected]從而引入含有漏洞的[email protected]

二、研究方法

基於此,本文旨在提出一種輕量且能夠對安全漏洞影響儘可能準確分析的方法,對NPM生態中存在的安全漏洞進行經驗研究。

如上圖所示,我們首先設計並實現一整套資料處理平臺,對NPM生態中軟體包元資料、相關漏洞資料等進行收集、整合,並自動生成並更新一個基於neo4j的圖資料庫 (DVGraph)。

下圖為資料收集處理平臺的基本架構:

截止到生成經驗研究所用的資料庫(2019年12月),DVGraph包含114w library,1,094w version,及815個標記好的CVE漏洞,該資料庫的儲存空間超過15GB。

在此基礎上,為了提升依賴解析的速度,我們基於對NPM中軟體安裝過程的分析,提出一個基於DVGraph模擬安裝過程中依賴解析策略的演算法(DTResolver),DTResolver能夠在對任意資料軟體包依賴解析的過程中,識別並找出所有依賴中含有安全漏洞的元件及相應的依賴引入路徑。

此外由於NPM中廣泛使用依賴約束條件(版本範圍)而不是固定版本進行依賴定義,導致依賴安裝結果隨著時間可能發生變化

如下圖中,在[email protected]釋出後,[email protected]的安裝過程中,對B的依賴將解析成新發布的版本而不是原有的[email protected], 圖中[email protected]的釋出亦是如此。因此我們在DTResolver的基礎上進一步增加了時間約束,使其能夠支援在給定專案從其釋出前到DVGraph更新時間內任意時刻的依賴樹模擬解析。

通過在大規模資料集(10w library version)上與現有依賴解析工具(npm-remote-ls)的對比驗證,DTResolver能夠完全正確地解析超過90%的依賴樹,並正確識別98.1%的依賴樹中存在的安全漏洞及92.6%的安全漏洞的引入路徑。

三、經驗研究

我們從以下兩個方面分析NPM中安全漏洞的影響:

  • 安全漏洞是如何通過依賴樹影響並傳播到整個NPM生態的
  • 安全漏洞在依賴樹中的影響是如何隨著時間變化的

(一)安全漏洞影響傳播分析

我們通過對DVGraph中所有的library及其version (超一千萬)的依賴樹進行解析並分析,發現:

  • 24.78%的包版本(271w library version)的依賴樹中至少存在一個含有安全漏洞的元件,這些包版本來自19.96%的第三方元件包 (22.9w library)。
  • 16.17%的第三方元件包(18.6w library)的最新版本的依賴樹中存在至少一個含有安全漏洞的元件。
  • 超過100個含有安全漏洞的元件的最新版本仍然受安全漏洞所影響。
  • 我們發現了25個安全漏洞實際上影響了超過1w個第三方元件包或10w個版本(影響大約1%的生態)。
  • 平均依賴樹中每個安全漏洞會通過8條不同的依賴鏈影響根節點元件。
  • 在受影響的271w個包版本中,超過30%包版本的直接依賴中即存在安全漏洞。
  • 安全漏洞的傳播鏈路大都通過有限的直接依賴影響根節點元件,78.94%的受影響元件(214w)的依賴樹中,安全漏洞僅通過不超過3個直接依賴影響根節點專案。

(二)安全漏洞影響傳播的演進

由於NPM中元件包更新頻繁且依賴複雜,任一元件依賴樹隨著時間的變化也相當頻繁,我們從DTResolver的驗證資料集中抽取了5.4w個包版本,進而分析其從釋出時間開始到2019年底的依賴樹變化,並分析其中安全漏洞影響傳播的變化,我們發現:

  • 隨著時間的發展,越來越多的包版本的依賴樹中逐漸出現安全漏洞,且其中每個包版本依賴樹中安全漏洞的數量也在逐漸增加。
    • 其中19.2%的包版本在其釋出時依賴樹中就已經存在了安全漏洞,而在分析截止時間,該資料變成了33.8%。
    • 在所有依賴樹中曾經出現安全漏洞的包版本中,69.8%的包版本在截止時間的依賴樹中存在的安全漏洞數量超過了釋出時間,而相反情況的只有7.4。
  • 絕大部分依賴樹中引入的安全漏洞(93%)是在安全漏洞被髮布前就已經存在於依賴樹中,而88%的安全漏洞修復版本的釋出也是在漏洞釋出前。
  • 隨著時間的變化,依賴樹中60%的安全漏洞在依賴樹的動態變化過程中可以逐漸被清除,剩餘40%的安全漏洞在實驗截止時仍存在依賴樹中。此外,這些被清除的安全漏洞在依賴樹中仍然存在了371天。
  • 不及時的包版本維護(維護者)及不合理的版本約束範圍(使用者)是導致大部分漏洞無法隨著依賴樹動態變化而自動清除的原因,需要更多的措施和工具來輔助改善生態中不同角色的不合理操作。

(三)應用示例:DTReme

基於我們經驗研究的發現,我們結合DTResolver提出一種遍歷依賴樹解空間從而儘可能修復依賴中存在的安全漏洞的工具DTReme,在DTResolver模擬解析依賴樹的過程中:

  • 向前檢測:在每次解析依賴關係時,只允許解析到安全版本;
  • 向後回溯:在每次發現無法解析到安全版本時,回退到上一個節點重新選擇版本。

基於此,理論上可以遍歷整個依賴樹的解空間並生成包含安全漏洞最少的依賴樹。通過與NPM官方的auditing工具(npm audit fix)對比,我們發現DTReme能夠修復更多的安全漏洞。但同時也證明了,依賴樹中相當一部分的安全漏洞無法通過版本上的調整清除,這也進一步說明了軟體供應鏈中安全漏洞的修復與治理需要生態中各方的共同努力。

四、一些建議

基於以上發現,我們進一步針對供應鏈中不同參與者提出了一些可行的建議:

  • 維護者(Provider):
    • 當安全漏洞出現時,儘可能早地釋出修復版本;
    • 在NPM registry中儘快deprecate含有已知安全漏洞的版本
    • 針對該元件主流使用的依賴約束,儘可能保證滿足這些約束的最高版本是安全的,尤其是在推進到下一個大版本之後;
    • 儘可能頻繁地檢測自己維護元件的依賴中是否存在安全漏洞,以免下游使用者受到影響。
  • 使用者(Consumer):
    • 將依賴鎖(dependency lock, i.e., package-lock.json)和週期性依賴更新相結合,以降低完全不更新依賴帶來的安全風險和頻繁更新帶來的相容性問題;
    • 提高對依賴中存在的安全漏洞的防範意識,尤其是直接依賴中;
    • 採用第三方檢測工具,在開發運維的過程中,時刻監控依賴中的安全漏洞。
  • 第三方檢測機構(Third-party Auditor):
    • 提供更細粒度的依賴中面向安全漏洞的修復方案:現有的主流廠商僅採用粗粒度的修復方案,比如僅通過調整使用者專案的直接依賴來規避依賴樹中的安全漏洞,可採用類似DTReme的方案提升修復能力;
    • 提供更準確的安全漏洞可達性/可觸發性分析:當前基於元件成分分析的漏洞檢測手段中,凡是存在於依賴中的安全漏洞均會被認為存在危害,但這會引入大量的誤報,需進一步過濾出真實引入危害的安全漏洞,可進一步引入動態模糊測試、靜態函式呼叫可達性分析等技術,降低依賴樹中安全漏洞在真實影響上的誤報率。

五、結語

對於資訊保安從業者來說,第三方元件資訊、元件開源合規性以及元件依賴關係已成為安全合規檢測的分析重點,同時可以藉助開源軟體成分分析工具SCA獲得第三方庫列表,快速並準確地識別未知檔案的功能以及元件引入的安全漏洞。若想從根本上理解和解決安全問題,我們還需要對開源生態有更深入的理解。本文就是從JavaScript的開源生態做的一個系統化嘗試和輸出,我們也將通過開發可持續性的差異化產品功能來滿足企業的多樣化需求。

大型專案中經常會出現成百上千的依賴關係(元件所引用的元件)或是元件,在這種情況下,要將風險視覺化並確定問題的根本原因將變得極其困難。Scantist把本文中的開源生態資料用來更準確的分析開源元件的依賴關係,通過建立依賴關係圖(如下圖),把專案中的複雜依賴關係和元件以圖形方式呈現出來,讓分析過程更清晰,讓使用者更加直觀的瞭解專案中的依賴關係及元件。

探方SCA依賴關係圖

如需瞭解更多產品與分析詳情,請點選 http://Scantist.io 或左下方“閱讀原文”,Scantist技術團隊將在第一時間為您答疑解惑。

文章來源:

關於Scantist

Scantist是從新加坡南洋理工大學孵化出來的一個專注於軟體漏洞檢測和管理的網路安全公司。其核心產品是一套全方位軟體安全分析(SaaS)平臺,利用智慧漏洞分析引擎確定程式碼庫中的漏洞資訊,並提供漏洞修復補丁和建議。

備註:Scantist擁有對此文章的修改和解釋權。如欲轉載或傳播此文章,必須保證此文章的完整性,包括版權宣告等全部內容。未經Scantist允許,不得任意修改或者增減此文章內容,不得以任何方式將其用於商業目的。