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

傳統(tǒng)的漏洞管理側(cè)重于已知漏洞，例如常見漏洞和披露列表(CVE)中的漏洞。然而，業(yè)界逐漸意識到，已知漏洞是滯后的風(fēng)險指標(biāo)。

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

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

一、已知漏洞

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

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

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

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

二、合法軟件包被入侵

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

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

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

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

三、名稱混淆攻擊

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

一旦這些被入侵的軟件包被引入企業(yè)的IT環(huán)境，就會危及系統(tǒng)和數(shù)據(jù)的機密性、完整性和可用性(CIA)。

四、缺少維護

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

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

考慮到軟件更新?lián)Q代速度飛快，根據(jù)美國國家漏洞數(shù)據(jù)庫(NVD)的年度數(shù)據(jù)，新的漏洞正以創(chuàng)紀(jì)錄的速度出現(xiàn)，這對于經(jīng)常使用未及時更新的開源軟件組件的現(xiàn)代應(yīng)用程序來說，風(fēng)險正不斷累積。

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

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

60-80%的現(xiàn)代代碼庫由開源軟件組成，我們的數(shù)字生態(tài)系統(tǒng)中很大一部分，甚至是最關(guān)鍵的系統(tǒng)，都運行在缺乏維護和支持的開源軟件上，這構(gòu)成了重大且亟待解決的系統(tǒng)性風(fēng)險。

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

五、組件/依賴項過時

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

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

六、未跟蹤依賴項

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

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

七、許可和監(jiān)管風(fēng)險

開源許可證監(jiān)管風(fēng)險是指開源組件或項目可能缺少許可證，或者許可證可能妨礙下游用戶的使用。

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

隨著越來越多的企業(yè)在其專有產(chǎn)品、服務(wù)和產(chǎn)品中更廣泛地使用開源軟件組件，開源許可證風(fēng)險還可能會影響企業(yè)的業(yè)務(wù)目標(biāo)、并購活動等。

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

八、成熟度低

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

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

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

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

九、未經(jīng)批準(zhǔn)的更改

OWASP將“未經(jīng)批準(zhǔn)的更改”定義為：組件在開發(fā)人員沒有注意到、審查或批準(zhǔn)更改的情況下發(fā)生更改的情況。當(dāng)下載鏈接發(fā)生更改或指向無版本控制的資源，甚至是被篡改的不安全數(shù)據(jù)傳輸時，可能會發(fā)生這種情況，這凸顯了安全傳輸?shù)淖饔谩?/p>

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

十、代碼膨脹和代碼不足

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

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

OWASP建議在這種情況下，盡可能在內(nèi)部重新開發(fā)所需的功能，以降低依賴體積過大或過小的風(fēng)險。在云原生容器化環(huán)境中，安全基礎(chǔ)鏡像正被積極推廣，例如Chainguard等領(lǐng)導(dǎo)者所倡導(dǎo)的，這些鏡像是經(jīng)過最小化加固的基礎(chǔ)鏡像，漏洞數(shù)量極少甚至為零。