不破不立：軟件供應鏈的威脅與方案

近三年來軟件供應鏈安全概念持續升溫，新型威脅仍層出不窮，從Log4j漏洞到node-ipc組件投毒，近年來自軟件供應鏈安全威脅涌現，企業違反GPL許可證的案例也屢見不鮮。

供應鏈安全事件爆發的頻次和影響面都在持續擴大，供應鏈安全已經成為企業開展經營活動不得不面對的一個隱患，也是所有安全廠商致力于要解決的問題。開源是更安全還是更不安全？

王福維：《概念之下的開源軟件供應鏈安全真實威脅》

此前，很多的對源供應鏈問題闡述，都會引入DevOps的流程，以這個模型來作為軟件供應鏈安全模型，我們認為這樣的模型實際上是有所欠缺的。因為它更多的是站在一個開發者的角度看待整個開發過程當中面臨的問題，對于開發流程的上游以及下游缺乏足夠的建模。

對于供應鏈相關方的模型，我們可將其分成三個角色：

①軟件的供應者，其中包括自由軟件基金會、大型的基礎類型項目、獨立開發者。其中，最主要的開源代碼貢獻者屬于獨立開發者；

②軟件的消費者，除終端用戶使用開源軟件的二進制制品外，作為開發者為開發商業項目，不可避免的也會使用到開源代碼，同時，開源工具及容器鏡像的使用者，也在消費者定義之內；

③平臺方，例如各家的云服務提供商，其實也是這樣一個中間的狀態：一方面兒他們是從開源生態中獲取、封裝像K8S這樣的基礎軟件，同時他們又不是這些軟件的直接使用者，而是作為一個軟平臺的基石去向消費者提供托管、服務和鏡像。

這三個角色，并沒有完全絕對的界限。例如騰訊的自有產品和服務的開發者，既是開源代碼的消費者，又是提供服務的平臺方；同時對于自身在業務中根據最佳實踐，向上游開源項目貢獻代碼或者將內部項目反哺到開源生態，又具有生產者角色。

這三個角色的相互作用，形成了軟件供應鏈。而針對供應鏈的威脅，我們認為本質是參與者站在任何一個環節里面，所受到上游威脅的直接和間接影響，以及對下游影響的透傳，這是我們對開源軟件這樣的一個概述。

從技術角度，需要從“漏洞”和“后門”兩個維度，對供應鏈威脅做明確的闡述。這兩個維度，分別代表了開源軟件相關方在供應鏈路中，被動遭遇的問題以及可能受到的主動威脅，這些威脅又各自有不同的復雜度和表現形式，以這兩大類進行抽象，更有助于清晰地認識問題并提煉出根本解法。

首先，我們需要去明確的是，漏洞真實的威脅遠遠不止0day這么簡單。對于漏洞在供應鏈當中所造成的、區別于孤立軟件（如客戶端軟件）的效果，做了三個定義，即供應鏈對于漏洞的增強效應：

• 長尾，影響的軟件和受眾隨著fork和依賴層級延長，漏洞的確認和修復時間無法收斂；
• 放大，對軟件下游的影響隨著依賴鏈路延伸而倍增，遠不僅局限于直接下游；
• 隱藏，在不同開發生態中有各種供應鏈依賴形式，難以統一分析，且存在關注盲區。

這里以一個在案例分析中發現，且首次披露的供應鏈威脅實例，說明這三種效應，以及圍繞著三點的威脅表象。

漏洞之于供應鏈的威脅

某由NGINX的二次開發項目**ngin*

1. 案例分析

該項目在上游NGINX項目基礎上，引入大量增量feature，代碼文件與上游存在普遍差異，無明確基線版本，因此對于上游項目披露的漏洞，進行存在性確認，存在一定的復雜度。

本例中，我們分析發現，該項目截止到2021.12都有活躍的開發維護，因此選取了一個NGINX在2021.03披露的漏洞，判斷其修復狀態。根據原始漏洞patch，很容易發現，該項目所基于的基線代碼受到該漏洞影響，且該CVE漏洞的修復代碼始終并未被移植過來。

進一步，我們注意到，根據shodan的數據分析，該二次開發項目具有極其廣泛的使用者，主機數甚至達到原版NGINX的1/13。然而分析觀察，可能是隨著項目的變動，該開源項目已經失去了有效的維護，項目本身沒有被歸檔，但也未聲明停止安全修復等支持，面對開源社區的詢問，僅表示其開源版本和“內部使用版本”存在斷代。

2.案例延伸

對該案例進一步分析，可體現前述的放大效應。

長尾效應：隨開發維護、fork鏈路延伸，下游失去上游背書，可維護性減弱。考慮到NGINX的商業版和開源版本，到該項目的內部與開源版本，逐級傳遞下，安全修復和支持逐步喪失，而再下游的fork項目則完全失去了得到安全修復的機會。

放大效應：fork二次開發項目，新增功能模塊的實現存在對原有代碼的平移，潛在保留了漏洞克隆風險。例如本例中，在額外引入的另一套SSL套件代碼中，存在仿照OpenSSL功能模塊，克隆得到的國密相關密碼和協議代碼，這部分保留有源頭代碼的未修復漏洞；在這些新增代碼中，漏洞的存在不斷得以復制。

隱藏效應：由上游開源項目做二次開發的實踐形式，混淆了對應基線版本，功能backport行為雜糅了多版本，較難分辨出文件和代碼塊的來源版本和漏洞存在性。

3.核心問題與潛在解法

漏洞之于供應鏈的威脅核心問題，從治理角度觸發，可期望通過開源代碼使用感知和統一管理，盡可能消除已知威脅：

• 完整的依賴關系測繪，解決易忽視的次級依賴鏈路；
• 次生開源依賴質量評估，解決無條件信任的次生開源依賴；
• 動靜態庫模塊化引用依賴，替代源碼形式引用包含依賴代碼；
• 細粒度代碼成分相似度判定，規避開發中粘貼不可信來源碼引入的威脅；
• 使用有更新管理的軟件版本，而非長期使用一個工作即可的陳舊版本；
• 使用EPEL等源，或對編譯制品專項維護，取代自行編譯的軟件版本在鏡像中長期使用；
• 構建類似OSS-fuzz的開源分析與共享平臺，扭轉被動依賴漏洞相關信息披露的狀態。

后門之于供應鏈的威脅實例披露

相比于漏洞，后門的威脅更多來源于主動攻擊，近年來眾多的軟件上游投毒事件，證明了對DevOps全鏈路均有可能實現后門的植入，但過于零散的事件，可能讓人忽視問題的關鍵，即后門最大的風險總來源于無條件信任形成的盲區。以下通過對DevOps中最信任的基礎設施——Git的一個實驗，說明這種信任的脆弱。

1. Git“歷史篡改”：

Git一直被認為具備數據可靠性，關鍵是其存儲的鏈式歷史結構與去中心化。但近年Git倉庫憑證泄漏事件頻發，真的只有泄密風險，而不存在篡改和后門植入的可能嗎？

這里我們借助開源工具BFG repo-cleaner，一定程度上實現了盡量“無感知”的git歷史篡改。BFG通過對git歷史commit中，敏感信息的全量修改，并強制覆蓋遠端分支數據，來實現保留歷史提交信息不變的數據變更。借助這一能力，我們的實驗中，在一個fork出來的bash項目中，針對一個歷史commit修復的高危CVE漏洞，篡改commit內容，并保證該篡改在后續歷史中得以保留，從而實現了無新增commit、無歷史痕跡的歷史漏洞（后門）的植入。

2.案例延伸

雖然這個實驗中，git歷史的篡改是“有條件”的，即篡改的遠端分支，與該項目其它參與開發者的本地存儲有數據沖突，可能被發現；但結合一些當下的特殊場景，這種攻擊還是完全可以被用于構造真實的供應鏈后門攻擊。

例如，在時下流行的云原生生態，一個熱門的開發模式是圍繞WebIDE展開的云端開發，該模式下實際沒有了開發者的本地開發環境，那么對于篡改的git歷史也就沒有發現的機會。又比如在開源生態中，有各種git鏡像的倉庫，包括原本非git托管的項目在GitHub上同步的鏡像，以及類似gitee這種鏡像站；這些倉庫是否與原本項目是否完全一致，作為使用者往往不會有意識地做額外的哈希校驗。

3.后門之于供應鏈的威脅：核心問題與潛在解法

核心問題：①破除一切無條件信任；②具備對“意圖”的感知；③解決規模化問題。

審視一切信任：對所有依賴的上游、使用的平臺工具，以攻擊者視角分析，及至假定面對的是國家對抗力量。

可控可信平臺：打造具備充分的一致性校驗、必要的多因素驗證的平臺、自主CI/CD平臺以及全過程可審計、攻擊可感知。

后門檢測技術：基于一切三方不可信原則，打造源碼、commit級、面向語義多維度的掃描能力以及動態持續測試機制。

開源協作建設：以生態的方法解決生態的問題，在自主可控平臺上打造自主接入、可復制的掃描能力共建，并共享信息。

最后，對于現今生態或者說自由軟件世界的現狀的了解和方案的展望，隨著自由軟件世界的右轉，缺乏成熟的商業化模式。更多的，是聚焦面向問題的技術環節的成熟，希望能夠給行業更多機會和期待。

墨菲安全歐陽強斌：《軟件供應鏈安全威脅與業界解決方案》

隨著軟件行業以及開源生態的發展，開源軟件已經成為了整個數字世界的基石。軟件供應鏈升級使開發過程越來越簡單和低成本，有數據統計從2015年到2019年，開源代碼的使用占比增長了一倍，現在已經到了78%的水位。平均每一個項目可能會引入超過100個開源組件，這其中可能有20%-30%的組件都存在不止一個漏洞，63%的開源項目如果直接拿來商用，會存在許可證侵權的風險。在過去的兩年時間，從軟件的生產到使用各個環節都已經出現了各種各樣的安全事件。

開源技術應用、國際形勢復雜、軟件供應鏈的多樣化，供應鏈各個環節的攻擊急劇上升，已然成為企業主要的安全威脅。從黑客視角來看，針對通用軟件供應鏈的攻擊成本低，攻擊覆蓋效果好，可竊取數據、勒索、挖礦等多種獲利方式。綜合來看，供應鏈安全目前主要面臨如何準確識別資產、風險如何檢測或預防、企業治理低成本落地三大挑戰。

具體來說，第一點是比如怎么去識別用到了什么樣的開源組件，它的復雜性在于整個軟件以及軟件引入的場景，是非常復雜的，它有多種多樣的形式，有不同的場景。

第二點，在風險檢測上比如說投毒的背后其實是非預期行為，那預期和非預期你怎么去劃定一條很清晰的界限呢？這個其實也是比較難的；開源許可證是自然語言描述的一些條款，導致沒法通過機器百分百正確識別，也就導致在識別效果上需要做大量工作。

第三點是大部分企業都非常頭疼的問題，發現了很多問題，怎么讓研發工程師高效地修復。常見的問題會是：發現有很多的漏洞，這些漏洞有直接依賴引入的，也有是間接依賴引入的，那開發者要怎么去修復？這些漏洞這么多，應該先修哪一個？雖然在依賴配置了這個組件，但是代碼中沒有調用，或者沒有調用有問題的函數。這些問題都影響著甲方安全團隊的治理落地。

我們經常會考慮的一個問題是，怎么能保證獲得更全面的漏洞信息，下面這個大概是一個比較理想的模型。首先，是我們需要有足夠多的數據輸入，那會包括像CVE/CNVD這樣的官方漏洞庫，以及包括像GitHub這樣的第三方漏洞庫；同時，還需要有所有開源項目的代碼庫變更、官方發布的公告、漏洞相關的輿情，再加上社區力量貢獻。

從業界來看，huntr、debricked等初創公司推出了創新的產品，openSSF基金會在積極推進sigstore、scoreboard等解決方案，NPM、docker等包管理增強管控機制，CVE、SPDX這些標準也在不斷演進。

總體來說開源軟件供應鏈是處在一個安全風險高、來自攻擊者和國家監管的關注度都很高的狀態。一個好的解決方案，需要完善的工具鏈支持，以及豐富的組件、漏洞等知識數據才能夠實現的。不管是組件還是漏洞，都在走向標準化，在未來可能會做得非常標準化。但是，現實到未來其實還有很長的一段路需要走，在接下來的一段時間，可能類似的一些風險事件還會繼續發生。最后，像其他安全領域一樣，在軟件供應鏈安全這個領域，其實也沒有任何的一個解決方案能夠解決所有的問題，在當前我們仍然需要做大量的非常細致、瑣碎的工作，才能取得一個比較好的效果。