近年來開源軟件安全風險快速增長，不久前曝光的XZ后門更是被稱為“核彈級”的開源軟件供應鏈漏洞。雖然XZ后門事件僥幸未釀成災難性后果，但為全球科技界敲響了警鐘：當今數字生態系統極其脆弱，亟需改進開源軟件的使用和安全管控方式。

傳統的漏洞管理側重于已知漏洞，例如常見漏洞和披露列表(CVE)中的漏洞。然而，業界逐漸意識到，已知漏洞是滯后的風險指標。

開放式Web應用安全項目(OWASP)指出，為了更安全地使用開源軟件，人們需要轉變思維方式，更加關注風險的前瞻性指標。這些指標可以幫助我們識別特定開源軟件庫、組件和項目存在的潛在風險，并通過綜合考量這些風險，制定更安全的開源軟件使用策略，降低漏洞被利用的可能性。

為應對包括XZ后門事件在內的諸多新興開源軟件安全風險，幫助用戶更安全地使用和管理開源軟件，近日，OWASP發布了“十大開源軟件風險”TOP10清單，并針對每種風險給出了安全建議，具體如下：

一、已知漏洞

此類風險指存在已知漏洞的開源軟件組件，這些漏洞通常是由軟件開發人員和維護人員在開發過程中無意引入，并隨后由安全研究人員公開披露。

已知漏洞的可利用性取決于其在企業應用程序中的利用場景。雖然看似簡單，但現實情況是，如果不向開發人員提供漏洞利用場景等信息，將導致大量無意義的安全告警，從而增加開發人員的工作量，浪費時間并引發挫敗感。

為了降低已知漏洞風險，企業可采取多種措施，例如：掃描所使用的開源軟件組件查找漏洞;根據漏洞的可利用性、利用可能性、可達性分析(可將誤報率降低80%以上)等因素，對掃描結果進行優先級排序。

此外，業界還開發了一系列平臺方案提高已知漏洞的管理效率，例如CISA的已知被利用的漏洞(KEV)目錄和利用預測評分系統(EPSS)。

二、合法軟件包被入侵

攻擊者已經認識到劫持合法開源軟件包的巨大價值和殺傷力，通過這種方式可大面積影響下游軟件用戶(包括個人和企業)。

攻擊者可以采用多種方法實施此類攻擊，例如劫持開源項目維護人員的賬戶，或利用開源軟件包倉庫中的漏洞。

他們還可以偽裝成維護人員加入項目，伺機植入惡意代碼。例如，最近的XZ后門事件正是如此，攻擊者偽裝成合法貢獻者，經過長時間潛伏后在代碼中植入后門。

為了降低此類風險，企業可以參考微軟發布的(現已捐贈給OpenSSF)安全供應鏈消費框架(S2C2F)等資源和指導方針(業界還有其他一些類似的框架)。

三、名稱混淆攻擊

在名稱混淆攻擊中，攻擊者創建惡意組件，其名稱與合法的開源軟件包或組件相似，希望受害者在不知情的情況下下載并使用這些惡意組件。此類攻擊手法也出現在CNCF軟件供應鏈攻擊目錄中，包括typosquatting(域名typosquatting)和brand-jacking(品牌劫持)等。

一旦這些被入侵的軟件包被引入企業的IT環境，就會危及系統和數據的機密性、完整性和可用性(CIA)。

四、缺少維護

與專有軟件不同，開源軟件面臨的一個嚴峻現實是沒有“供應商”對代碼安全負責。開源軟件主要依靠無償的志愿者進行維護，以“as is”(按原樣)的方式提供軟件，這意味著一些軟件組件可能長期缺少積極的開發和維護，漏洞修復工作也可能無法及時完成。(即使能夠完成，也可能無法滿足軟件用戶對組件更新時間線的需求，也無法提供類似專有軟件供應商的服務水平協議SLA承諾)

Synopsys發布的開源軟件報告指出，在所評估的開源代碼庫中，85%使用了距今超過四年且過去兩年沒有更新的開源軟件組件。

考慮到軟件更新換代速度飛快，根據美國國家漏洞數據庫(NVD)的年度數據，新的漏洞正以創紀錄的速度出現，這對于經常使用未及時更新的開源軟件組件的現代應用程序來說，風險正不斷累積。

造成開源軟件維護風險另一大原因是貢獻者和維護者太少。約25%的開源項目只有一個開發人員貢獻代碼，94%的項目由10名或更少的開發人員維護，正如研究人員ChinmayiSharma在其著作《數字公共產品的悲劇》中所指出的那樣。對于那些希望全面了解挑戰的人來說，這是一本值得推薦的讀物。

維護者過少的風險也被成為“公交車司機因素”，如果一個項目只有一個主要維護者，風險顯而易見。即如果掌舵項目的某個關鍵人物突然去世或離開項目，會造成什么可怕影響?

60-80%的現代代碼庫由開源軟件組成，我們的數字生態系統中很大一部分，甚至是最關鍵的系統，都運行在缺乏維護和支持的開源軟件上，這構成了重大且亟待解決的系統性風險。

OWASP建議采取以下措施來降低此類風險：檢查項目的活躍度和健康狀況，例如維護者和貢獻者的數量、發布頻率和漏洞修復的平均時間(MTTR)。

五、組件/依賴項過時

開源軟件的另一個風險是使用過時的組件版本(盡管這些組件可能存在更新的版本)。Synopsys的報告指出，這種情況實際上很普遍，發生在絕大多數代碼庫和存儲庫中。

今天，情況變得更加復雜，因為許多現代軟件應用程序和項目都存在錯綜復雜且令人眼花繚亂的依賴關系。Sonatype和Endor Labs發布報告也強調了這個問題。后者發布了“依賴管理現狀”報告，顯示95%的漏洞與傳遞依賴項有關。

六、未跟蹤依賴項

這種情況是指開發人員/企業根本沒有意識到他們使用了特定的依賴項或組件。這可能是由于企業沒有使用軟件成分分析(SCA)等工具來了解其開源軟件的成分和使用情況，或者沒有使用軟件物料清單(SBOM)等工具提高對所使用或分發的軟件組件的可視性。

未跟蹤依賴項風險正推動SBOM和軟件供應鏈安全工具快速發展，正如業界通過SolarWinds和Log4j等事件所認識到的那樣，SBOM能幫助企業掌握其組件庫存，緩解相關風險。但是，盡管SBOM多年來一直是SANS/CIS的關鍵控制措施，但大多數企業仍然缺乏對組件/庫級別的全面軟件資產清單。

七、許可和監管風險

開源許可證監管風險是指開源組件或項目可能缺少許可證，或者許可證可能妨礙下游用戶的使用。

OWASP指出，企業需要確保其使用的開源軟件組件符合其適用許可條款，否則可能會導致許可或版權侵權，甚至導致法律訴訟。

隨著越來越多的企業在其專有產品、服務和產品中更廣泛地使用開源軟件組件，開源許可證風險還可能會影響企業的業務目標、并購活動等。

企業可以通過以下措施來降低這些風險：識別其軟件中使用的組件的適用許可證及其預期用途。OWASP建議企業避免使用完全沒有許可證的開源組件，并識別具有多個或沖突許可證的組件。

八、成熟度低

并非所有軟件都是生而平等的，成熟度方面也存在差異，部分原因是維護人員參與程度不同。

一些開源項目可能沒有應用安全的軟件開發實踐(例如NIST安全軟件開發框架SSDF)。具體示例可能包括缺乏文檔、缺乏回歸測試、缺乏審查指南以及許多其他最佳實踐。

還有一個令人不安的現實是，許多開發人員對安全不感興趣。Linux Foundation和哈佛大學創新科學實驗室(LISH)的研究證實了這一點，他們發現開源軟件開發人員只有2.3%的時間用于提高其代碼的安全性。

業界正在努力提升開源軟件的安全成熟度，并提供了相關工具，例如OpenSSF的Scorecard，它為Github上的開源項目提供了一套強大的檢查標準，例如分支保護的存在、貢獻者/組織數量、CI測試、模糊測試、維護、許可等。另一個類似的標準是CISA和OpenSSF提出的“軟件包存儲庫安全原則”。

九、未經批準的更改

OWASP將“未經批準的更改”定義為：組件在開發人員沒有注意到、審查或批準更改的情況下發生更改的情況。當下載鏈接發生更改或指向無版本控制的資源，甚至是被篡改的不安全數據傳輸時，可能會發生這種情況，這凸顯了安全傳輸的作用。

建議的操作和緩解措施包括：使用資源標識符確保一致性并指向相同的不可變工件。用戶還可以在實際安裝和使用組件之前驗證組件的簽名和摘要。此外，為了降低組件在傳輸過程中被篡改的風險，應使用安全傳輸協議。

十、代碼膨脹和代碼不足

最后，還有一類開源軟件風險是“代碼過于臃腫或簡陋”。一些開源組件提供的功能太少，有些則太多，而實際只使用了其中一部分。這通常被稱為“代碼膨脹”。

在代碼不足的依賴項案例中，由于代碼量太少，組件變得更加依賴于上游項目的安全。另一方面，如果用戶遇到代碼膨脹或指數級代碼行數，最終會帶來更大的攻擊面和潛在的可利用代碼/依賴項，盡管這些代碼/依賴項實際上不需要或未使用。

OWASP建議在這種情況下，盡可能在內部重新開發所需的功能，以降低依賴體積過大或過小的風險。在云原生容器化環境中，安全基礎鏡像正被積極推廣，例如Chainguard等領導者所倡導的，這些鏡像是經過最小化加固的基礎鏡像，漏洞數量極少甚至為零。