供應鏈污染 惡意開源 惡意軟體 Heartbleed Equifax 漏洞

開源惡意軟體帶來營運風險 傳統掃描工具捉襟見肘難防入侵

鎖定軟體供應鏈攻擊激增 嚴遵十項守則緩解風險

2024-12-18
開源世界時時在改變,快速的創新使得每天可能都會出現新風險,而傳統的掃描工具無法準確、及時地偵測新的潛在惡意軟體,由於多數業者缺乏足夠的安全機制來實施更好的開源元件選擇以及安全更新,導致難以及時進行風險管理。

對企業而言,花在軟體開發上的每一塊錢都需要合理的理由,這使得風險管理變得複雜,當前的狀況是,開源世界時時在改變,快速的創新使得每天可能都會出現新風險,而傳統的掃描工具無法準確、及時地偵測新的潛在惡意軟體,由於多數業者缺乏足夠的安全機制來實施更好的開源元件選擇以及安全更新,導致多數業者都難以及時進行風險管理。

同時,囿於缺乏工具、可用的安全資料見解或隱含之安全流程的主動指導,開發人員在使用開源套件開發軟體時可能缺乏完整的資安思維。此外,開源惡意軟體的驚人成長以及使用開源下載作為惡意軟體分發工具也令人高度關注。在不斷出現的後門、勒索軟體和新出現的威脅中,安全性透過手動監督的方式陷入困境,儘管開發團隊積極檢查主要風險來源,但經常忽視安全問題。

當前軟體供應鏈的五大風險

過去十年中,軟體開發世界已經因開源消費而發生改變,業界看到了前所未有的創新,但也出現新的挑戰,特別是在管理軟體供應鏈的安全性和完整性方面。事實上,開源軟體占現代應用程式程式碼庫的90%,今年全球開源消耗量已飆升至估計6.7兆次下載,當前如npm和PyPI等生態系統正在蓬勃發展,主要是由人工智慧、雲端運算和DevOps等趨勢推動,但是這種成長也帶來風險。針對軟體供應鏈本身的攻擊次數開始上升,從Heartbleed或Equifax漏洞等偶爾發生的事件開始,已升級為複雜且廣泛皆提高的攻擊模式。根據調查,單在今年,就有超過50萬個惡意開源軟體套件被刻意「引入」開源儲存庫,較去年同期成長156%,而這將是未來的新常態。

持續性風險由未修復風險與腐蝕風險組成。(資料來源:sonatype)

另外,一種日益突出的新型攻擊開始出現,稱為「供應鏈污染」,也稱為惡意開源或開源惡意軟體,光是今年就發現512,847個惡意軟體套件(其中65,000個是高嚴重性惡意軟體軟體包),這種惡意軟體會針對從自動化建置環境到開發人員工作站的所有內容展開入侵,開源惡意軟體相當狡猾,原因在於它能無縫地融入合法的開發流程,繞過傳統的防禦偵測,這些攻擊並非假設——它們正在瞄準全球軟體生態系統,其中包括XZ Utils後門攻擊等事件,幾乎影響全球伺服器運作。

面對供應鏈污染,傳統的掃描工具可以有效識別和阻止已知的惡意軟體,但很難應對新的攻擊,尤其是那些嵌入惡意開源套件中的攻擊,雖然這些工具可以捕捉到已知威脅,但它們經常忽略開源元件中的隱藏危險,特別是當惡意程式碼被故意設計為逃避偵測時,使得開源惡意軟體以創新者為目標,利用消費習慣不良的軟體製造商進行入侵。

第三種風險是複雜性風險,光是在JavaScript生態系統(npm)中,今年就有4.5兆個套件請求,年增70%。在人工智慧革命的推動下,Python的生態系統也同樣蓬勃發展,然而這種規模也帶來了複雜性。這種「選擇過多」是造成安全風險的重要因素。在700萬個開源專案中,只有10.5%被積極使用,開發人員經常預設使用熟悉或流行的軟體包,而沒有經過適當的審查。這不是「如果」的問題,而是「何時」這些選擇導致安全漏洞的問題。

第四種是管理的問題,由於管理開源依賴項、修補漏洞和遵守許可條款所需的工作正在占用開發週期,相關管理也開始帶來負擔。平均而言,一般應用程式包含180個開源元件,手動管理這些元件已成為一項不可能的任務;更糟糕的是,在安全研究人員進行更深入的審查後,92%的公開漏洞資料需要更正。這就產生所謂的「管理意外風險」,即開發人員以為自己受到保護,但當發現相反的情況時為時已晚。更不用說國家漏洞資料庫(NVD)中積壓已發布但未處理的漏洞公告,這意味著那些試圖在沒有軟體組合工具的情況下做到這一點的人往往會為自己挖一個更大的坑。

第五種風險是持續性風險,包含未修復風險與腐蝕風險,未修復的風險是指軟體元件中已識別但尚未解決且在許多情況下永遠不會解決的漏洞,它還包含修復所需的時間,這些已知的漏洞構成持續的威脅,使軟體容易被有心人士利用;腐蝕風險影響軟體目前和歷史版本,與未修復風險一樣,腐蝕性風險低估解決這些漏洞所需的時間,使得受到攻擊的機率提升。然而,腐蝕性風險也包括延遲發現舊版本中的漏洞,發現並解決這些問題所需的時間越長,軟體就越容易受到潛在的攻擊,就像腐蝕性會侵蝕金屬一樣,長時間的發現和修復會增加持續風險的腐蝕力,漏洞未被發現和修復的時間越長,它們對軟體的影響就越大,使其越來越容易受到破壞與入侵。

解決方案業者提供的十項建議

至於如何預防?整理多家解決方案業者的經驗,大致上可以分成十項:

1. 安全編碼實務:將安全性納入從開始到部署的軟體開發生命週期(SDLC)。使用靜態和動態程式碼分析工具,培訓開發人員進行威脅建模,並定期執行漏洞評估,以在軟體工程工作流程的早期識別和修復弱點。

2. 依賴關係管理:維護組織內使用的軟體依賴關係和程式碼庫的清單。定期更新和修補這些實體以解決已知的安全漏洞。自動相依性掃描工具可以簡化此過程。

3. 供應商管理:優先考慮具有良好安全記錄的第三方承包商。建立嚴格的供應商評估標準,包括安全標準、合規性要求和事件回應能力。將供應商的歷史DNS記錄與軟體供應鏈攻擊和漏洞相關的已知危害指標(IOC)進行交叉引用。此外,定期評估和審核供應商,以確保他們始終遵守既定的安全實務。

4. 軟體物料清單(SBOM):建立和維護全面的SBOM,詳細說明程式碼庫中使用的所有元件,包括開源程式庫、框架和模組及其版本和修補程式狀態,此清單提供識別和修復軟體供應鏈中的漏洞所需的資訊。

5. 防篡改分發管道:應用程式在傳輸過程中特別容易被濫用,透過使用端對端加密、數位憑證和安全性協定來保護軟體包在發送給目標受眾的過程中免遭攔截或未經授權的變更。

6. 網路分段:隔離開發、建置和部署環境,以限制某一區域違規的潛在影響。防火牆、虛擬區域網路(VLAN)和軟體定義網路(SDN)工具可以促進分段並遏制威脅行為者在妥協場景中的橫向移動。

7. 多重身分驗證:此技術讓攻擊者更難獲得對開發人員工作站的未經授權的存取,多重身分驗證僅在整個軟體供應鏈(包括遠端員工的設備和供應商系統)中使用時才有效。

8. 細粒度存取控制:根據使用者角色和職責指定權限和特權,建議對高風險操作實施額外的身分驗證因素,例如存取生產環境或部署軟體更新。

9. 威脅情報:訂閱威脅情報來源主動應對新出現的風險。此策略與漏洞管理程序配合使用,該程序根據嚴重性確定修復工作的優先順序。

10. 事件回應計畫:制定路線圖,概述如何識別、遏制軟體供應鏈攻擊並從中恢復,該計畫應包括用於通知利害關係人和受影響用戶的通訊協議。

<本文作者:Abby Lin現為產業分析師>


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!