杜絕XZ後門！OWASP發佈十大開源軟體安全風險清單

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

傳統的漏洞管理側重於已知漏洞，例如常見漏洞和披露列表(CVE)中的漏洞。然而，業界逐漸意識到，已知漏洞是遲緩的風險指標。OWASP指出，為了更安全地使用開源軟體，人們需要轉變思維方式，更加關注風險的前瞻性指標。這些指標可以幫助識別特定開源軟體庫、元件和專案存在的潛在風險，並透過綜合考量這些風險，制定更安全的開源軟體使用策略，降低漏洞被利用的可能性。

OWASP發佈《十大開源軟體風險清單》

一、已知漏洞　Known Vulnerabilities
此類風險指存在已知漏洞的開源軟體元件，這些漏洞通常是由軟體發展人員和維護人員在開發過程中無意引入，並隨後由安全研究人員公開披露。

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

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

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

二、合法套裝軟體被入侵　Compromise of Legitimate Package
攻擊者已經了解劫持合法開源套裝軟體的巨大價值和殺傷力，藉由這種方式可大範圍影響下游軟體使用者，包括個人和企業。攻擊者可以採用多種方法實施此類攻擊，例如劫持開源項目維護人員的帳戶，或利用開源套裝軟體倉庫中的漏洞。

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

為了降低此類風險，企業可以參考如微軟發佈的安全供應鏈消費框架(S2C2F)等資源和指導方針。

三、名稱混淆攻擊　Name Confusion Attacks
在名稱混淆攻擊中，攻擊者建立惡意組件，其名稱與合法的開源套裝軟體或組件相似，希望受害者在不知情的情況下下載並使用這些惡意元件。此類攻擊手法也出現在CNCF軟體供應鏈攻擊目錄中，包括typosquatting(功能變數名稱typosquatting)和brand-jacking(品牌劫持)等。

一旦這些被入侵的套裝軟體被引入企業的IT環境，就會危及系統和資料的機密性、完整性和可用性。

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

Synopsys發佈的開源軟體報告指出，在所評估的開原始程式碼庫中，85%使用了距今超過四年且過去兩年沒有更新的開源軟體元件。

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

造成開源軟體維護風險另一大原因是貢獻者和維護者太少。約25%的開源專案只有一個開發人員貢獻程式碼，94%的專案由10名或更少的開發人員維護。OWASP建議採取以下措施來降低此類風險：檢查項目的活躍度和健康狀況，例如維護者和貢獻者的數量、發佈頻率和漏洞修復的平均時間。

五、組件/依賴項過時　Outdated Software
開源軟體的另一個風險是使用過時的元件版本，儘管這些元件可能存在更新的版本。Synopsys的報告指出，這種情況很普遍，絕大多數程式庫和存儲庫都存在這個問題。

今天，情況變得更加複雜，因為許多現代軟體應用程式和專案都存在錯綜複雜且令人眼花繚亂的依賴關係。Endor Labs發佈的報告顯示，95%的漏洞與傳遞依賴項有關。

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

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

七、許可和監管風險　License Risk
開源許可證監管風險是指開源元件或專案可能缺少許可證，或者許可證可能妨礙下游用戶的使用。

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

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

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

八、成熟度低　Immature Software
並非所有軟體都是生而平等的，成熟度方面也存在差異，部分原因是維護人員參與程度不同。
一些開源項目可能沒有採取安全軟體發展實踐，如NIST安全軟體發展框架SSDF。具體例子包括缺乏文檔、缺乏回歸測試、缺乏審查指南以及許多其他最佳實踐。

還有一個令人不安的現實是，許多開發人員對安全不感興趣。Linux Foundation和哈佛大學創新科學實驗室(LISH)的研究證實，開源軟體開發者只有2.3%的時間用於提高程式碼的安全性。

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

九、未經批准的更改　Unapproved Change
OWASP將「未經批准的更改」定義為：元件在開發人員沒有注意到、審查或批准更改的情況下發生更改的情況。當下載連結發生更改或指向無版本控制的資源，甚至是被篡改的不安全資料傳輸時，可能會發生這種情況，這凸顯了安全傳輸的作用。

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

十、程式碼膨脹和不足　Under/over-sized Dependency
最後，還有一類開源軟體風險是程式碼過於臃腫或簡陋。一些開源元件提供的功能太少，有些則太多，而實際只使用了其中一部分。這通常被稱為「程式碼膨脹」。

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

OWASP建議在這種情況下，盡可能在內部重新開發所需的功能，以降低依賴體積過大或過小的風險。

本文轉載自secrss。