開源惡意軟體包：Xygeni 方法

这 發現者 此流程會取得發布事件的資訊流。發布事件是指建立新元件或現有元件的新版本。由於主流的註冊中心不提供使用者導向的發布/訂閱機制，因此通常透過輪詢註冊中心來獲取最新事件資訊。 這是OSSF的一個優秀項目， 包裹式飼料，支持 MEW 支援 PyPI 或 Maven Central 等流行的註冊表，並提供統一的基於 feed 的介面。我們添加了一些特定的實作來減少等待時間，例如使用 NPM 所使用的 CouchDB 資料庫的副本，該副本與公共註冊表資料庫保持同步。

在 Xygeni，我們有庫存[1] 我們客戶軟體中使用的所有元件（直接或間接使用）都會納入分析範圍。客戶的元件座標會定期提交給 MEW，以便進行優先排序：客戶使用的元件會優先處理。優先排序也取決於發布者的信譽和組件的關鍵性，因此來自信譽較低的發布者的組件也會被優先處理。

这 分析儀 然後處理優先權佇列中的待處理元件。當選擇某個元件版本進行分析時，會從登錄機碼下載其壓縮包。請注意，分析的是打包好的二進制組件：大多數開源組件通常來自開源倉庫（例如 github.com），此處僅提供上下文信息，惡意軟體始終在組件壓縮包中搜索，因為威脅行為者通常會謊報其聲稱用於構建所發布組件壓縮包的源代碼。 

從使用者的角度來看

我知道你在想：提前知道惡意軟體版本對我有什麼好處？在這一集中… “惡意包裹剖析：有哪些趨勢？” 我們發現，總停留時間以天為單位，而MEW向使用受影響組件的客戶發出的首次通知僅需幾分鐘。只需一個簡單的防護措施即可。[2] 您可以阻止建置（警報分為兩個層級：一個是引擎自動偵測到潛在惡意軟體時發出的完全自動警報，另一個是我們的安全團隊透過人工檢查確認惡意軟體存在後發出的後續通知）。由於惡意軟體的潛伏期較長，等到註冊表確認並將其從註冊表中移除通常為時已晚。

組織可以使用防護措施來檢查是否存在可能含有惡意軟體的元件（在兩個警報層級中的任何一個），或透過 API 快速了解軟體專案中的任何直接或間接依賴項是否正在使用惡意元件。

MEW 的運作原理：內幕細節

核心：惡意軟體檢測引擎

分析器使用不同的偵測器來捕捉不當行為的證據。這些偵測器結合了靜態分析、能力分析和情境分析。[3]如本系列前一篇所述。 

Xygeni 擁有一支經驗豐富的靜態分析工程團隊，這是我們與其他反惡意軟體解決方案的主要區別。需要注意的是，對於某些生態系統，打包的 tar 套件可能包含原始程式碼（例如 NPM 套件中的 JavaScript 或 TypeScript 程式碼，PyPI 套件中的 Python 原始程式碼），或包含與原始程式碼足夠接近的已編譯程式碼（例如 Maven 的 JAR 檔案中的字節碼），以便進行靜態分析。而對於其他系統，例如容器鏡像，二進位執行檔較為常見，因此我們採用功能推斷技術，並結合基於 YARA 規則和惡意軟體簽章的傳統惡意軟體偵測方法。 

請注意，像正規表示式或簽章這樣的簡單技術並不適用於偵測惡意行為。試想一下，偵測投放器或下載器：某些程式碼或二進位檔案位於軟體包中，或從外部網域下載，與元件無關（可能是來自…）。 威脅行為者購買的大量域名列表[4]或 使用合法網域名稱來逃避偵測然後，這段程式碼會透過某個函數執行。程式碼可以被修改，從而隱藏下載 URL 或用於執行下載程式碼的函數。通常需要進行完整的資料流分析才能偵測到這種攻擊，這需要使用靜態分析的全部機制；或者，如果惡意行為運行的條件確實滿足，則可以使用沙盒執行來偵測。

威脅行為者採用相同的攻擊手法，因此也針對這些手法設計並實作了對應的偵測器。此外，通常還需要一些預處理步驟，例如移除混淆訊息，以揭示隱藏的行為。 

新增上下文

有些檢測器會利用上下文資訊。例如，元件註冊表中的版本與關聯 GitHub 倉庫中的標籤/發布版本不匹配，就足以證明惡意行為者可能獲得了註冊表的發布權限，但並未獲得 GitHub 倉庫的發布權限。類似影響加密錢包供應商的攻擊就是一個例子。 萊傑 這種不匹配很容易被偵測到。

A 惡意評分 (MS) 是根據偵測器運作結果計算得出的，計算依據是捕獲到的證據強度。並非所有結果都相同，執行順序也很重要。 

用戶和組件信譽

並非所有開源開發者都水平相當！ 

一位聲譽卓著的開發者可能會遭遇 NPM 帳號被盜（即使是安全意識很強的人也難免會遇到這種情況），並被利用該帳號發布惡意軟體。顯然，聲譽會急劇下降，只有當被盜帳號被找回且開發者修復了導致帳號被盜的根本原因後，聲譽才能恢復如初。聲譽得來不易，卻可能瞬間喪失。  

在MEW，我們實施了一套全面的聲譽管理系統，旨在獎勵積極行為並懲罰可疑活動。該系統對新用戶初始保持中立，並根據其持續的活動調整聲譽。

用戶可以透過積極的行為提升聲譽，例如維護活躍的社交媒體帳戶、啟用多因素身份驗證、定期為專案做出貢獻以及簽名。 commit使用可驗證金鑰的 s。相反，惡意行為（例如發布惡意軟體、使用一次性電子郵件地址、不簽署）會導致信譽下降。 commit或在貢獻中表現出不尋常的模式。

我們系統的首要目標是確保安全可靠的環境。它透過根據各種因素動態調整用戶信譽來實現這一目標，同時兼顧隱私問題和不同註冊機構的限制。

系統會計算使用者的內部信譽評分（如果可能，會加入註冊表和 GitHub 帳戶），並將其與惡意評分一起用於對被分析的元件進行分類，以便更好地確定誰是元件發布者。

已發現惡意行為的證據。那又怎樣？人工審核流程

目前分類器根據匯總分析結果和使用者/元件信譽的分數閾值，將分析的元件版本歸類為「已確認惡意」、「可能惡意」、「高風險」、「低風險」或「非惡意」類別之一。歸類為「高風險」或「可能惡意」類別會觸發人工審核和首次通知。 「已確認惡意」類別會在人工審核後或當證據與先前已確認惡意版本的相同證據相符時確定。 

當有足夠的證據表明潛在的惡意行為時，系統會向受影響的組織發出第一道警報（隔離警報）。如前所述，這可能會阻止依賴被隔離組件的軟體的安裝或建置。 

這對MEW內部造成了一個問題。 dashboard 因此，安全分析師可以開始對該組件進行人工審查。團隊擁有專門的工具（沙箱、反混淆器、惡意軟體研究分發工具、惡意軟體報告工具），可以快速評估正在調查的元件版本的性質。大多數惡意軟體（「鳳尾魚」或不複雜的惡意元件）都會經過審查。  

審查結果得出以下結論之一 安全至上 因此，自動分析引擎發現了一個誤報，該誤報被用作反饋給機器學習分類器，以學習模式；或者 已確認惡意因此，按照報告流程，該元件會被負責任地揭露為惡意元件，並提交至公開註冊表。隨後，會向受影響的組織發送第二份通知，這些組織反過來可能會… 解除組件的隔離，或徹底阻止其參與版本升級過程或阻止其參與內部註冊表中使用的組件防火牆。

這種設定使我們能夠每天分析數萬個新版本，並識別出其中數十個可能存在惡意行為的版本，然後進行手動審核。請記住上一集中提到的，目前我們在實際環境中發現的惡意元件比例約為萬分之一。 

向註冊處報告

我們發現，作為開源基礎設施支柱之一的大多數公共註冊表，在報告安全問題（尤其是惡意元件）方面提供的機制相當有限。我們正在努力改善報告流程的底層組織結構。通常情況下，我們最多只能收到註冊表安全團隊的一封回饋郵件，確認該元件已從註冊表中移除。 

有時註冊表會被濫用，違反其使用條款，但不會導致交付的軟體出現惡意行為。這種情況也會報告給註冊表，但為了減少干擾，不會通知相關組織。