軟件供應鏈攻擊的特征是向軟件包中注入惡意代碼，以破壞供應鏈下游的相關系統。近年來，許多供應鏈攻擊在軟件開發過程中充分利用了開放源代碼的使用， 這是由依賴項管理器(dependency managers)提供的，它在整個軟件生命周期中自動解析，下載和安裝數百個開放源代碼包，從而促進了供應鏈攻擊。

本文介紹了174個惡意軟件包的數據集，這些數據包在開源軟件供應鏈的真實攻擊中使用，并通過流行的軟件包存儲庫npm、PyPI和RubyGems分發，對2015年11月至2019年11月的軟件包進行了手動收集和分析。

本文還提出了兩種通用攻擊樹，以提供有關將惡意代碼注入下游用戶的依賴樹以及在不同時間和不同條件下執行此類代碼的技術的結構化概述。這項工作旨在促進開源和研究社區在未來發展的預防和保障措施。

01Introduction

通常，軟件供應鏈攻擊旨在將惡意代碼注入到軟件產品中。攻擊者經常篡改給定供應商的最終產品，以使其帶有有效的數字簽名，因為該數字簽名是由相應的供應商簽名的，并且可以由最終用戶通過受信任的分發渠道（例如分銷商）獲得，即網站下載或更新。

此類供應鏈攻擊的一個突出例子是NotPetya，這是一種被隱藏在流行的烏克蘭會計軟件的惡意更新中的勒索軟件。2017年，NotPetya目標是烏克蘭公司，但也打擊了全球的公司，造成了數十億美元的損失，據說是當今已知的最具破壞性的網絡攻擊之一。同年，可從供應商的官方網站下載惡意版本的CCleaner（一種適用于Microsoft Windows系統的流行維護工具），并且超過一個月沒有被發現。在此期間，它被下載了約230萬次。

供應鏈攻擊的另一種形式是將惡意代碼注入到軟件供應商產品的依賴項中。這種攻擊媒介已經由Elias Levy在2003年進行了預測，并且近年來隨著該方案的出現，出現了許多實際攻擊。這種攻擊成為可能，因為現代軟件項目通常依賴于多個開源程序包，這些程序包本身引入了許多可傳遞的依賴關系。這種攻擊濫用了開發人員對托管在常用服務器上的軟件包的真實性和完整性的信任，并濫用了鼓勵這種做法的自動構建系統。

數千個開源軟件項目可能需要單個開源軟件包，這使得開源軟件包成為軟件供應鏈攻擊的非常有吸引力的目標。最近對npm軟件包event-stream的攻擊表明了此類攻擊的潛在范圍：只需通過要求原始開發人員接管其維護工作，即可將所謂的攻擊者授予顯著npm軟件包的所有權。當時，event-stream還被另外1600個軟件包使用，平均每周被下載150萬次。

開源軟件供應鏈攻擊可與易受攻擊的開源軟件包的問題相提并論，后者可能會將其漏洞傳遞給相關的軟件項目，這屬于OWASP 前10應用程序安全風險之一。但是，在供應鏈攻擊的情況下，會故意注入惡意代碼，攻擊者會采用混淆和規避技術來避免被人或程序分析工具檢測到。

02Methodology

相關工作主要涉及易受攻擊的程序包，這些程序包包含偶然引入的設計缺陷或代碼錯誤，沒有惡意。但由于疏忽大意，可能構成潛在的安全風險。與此相反，惡意軟件包包含故意的設計缺陷或代碼錯誤，這些缺陷或代碼錯誤在軟件生命周期中被謹慎的加以利用或觸發。

區分易受攻擊的軟件包和惡意軟件包很重要。如前所述，易受攻擊的軟件包可能包含設計缺陷或代碼錯誤，這些缺陷或代碼錯誤是無意間但由于疏忽而意外引入的，并且可能構成潛在的安全風險。

從技術上講，惡意和易受攻擊的編碼可能相似甚至相同，因此，主要區別在于攻擊者的意圖。這項工作有兩個方面的作用：使用攻擊樹對可能的攻擊進行系統描述，以及在實際攻擊中使用的惡意軟件包數據集。攻擊樹能夠表示對系統的攻擊。攻擊的主要目標用作根節點，子節點代表實現該目標的可能方法。

第一個攻擊樹的目的是將惡意代碼注入下游用戶的軟件供應鏈，而第二個攻擊樹的目的是在不同情況下觸發其惡意行為。手動分析每個惡意軟件包和信息源，并在提供足夠信息的情況下將其映射到每個攻擊樹的節點。如果不存在擬合節點，則添加一個新節點。這種迭代方法確保攻擊樹的節點代表現實的攻擊向量。但是，該方法的缺點是這些樹不完整，因為它們不反映尚未觀察到或未描述的攻擊媒介。

在此期間，對漏洞數據庫Snyk、特定于語言的安全建議和研究博客進行了審查，以確定惡意包和可能的攻擊向量。注意，這些來源僅提及軟件包的名稱和受影響的版本，因此，實際的惡意代碼必須從其他來源下載。但是，這種惡意程序包通常在相應編程語言的標準程序包存儲庫中不再可用，例如npm或PyPI。

相反，在可能的情況下，它們是從不推薦使用的鏡像，互聯網檔案和公共研究資料庫中檢索到的。如果可以檢索到惡意軟件包的代碼，則會對其進行手動分析和分類。這樣做是為了確認軟件包的惡意軟件，將其映射到現有的攻擊樹或在必要時進行擴展。軟件包的惡意版本的發布日期根據Libraries.io（該服務可監視所有主要軟件包存儲庫中軟件包的發布）而定。咨詢和公共事件報告可用于對惡意程序包進行公開披露。

03Threat Analysis and Attack Trees

本節從高層次介紹與開源軟件開發項目相關的活動和系統開始，并以兩個攻擊樹為結尾。本屆的攻擊樹是基于在野觀察到的實際惡意軟件包以及安全研究人員和從業人員描述的潛在攻擊和弱點以迭代方式創建的。

通常，攻擊樹允許對針對任何類型的系統的攻擊進行系統的描述。因此，給定樹的根節點對應于攻擊者的頂級目標，子節點代表實現此目標的替代方法。攻擊樹的頂級目標是將惡意代碼注入軟件供應鏈，從而注入開發項目的依存關系，并在不同情況下觸發該惡意代碼。

A、開源開發項目

在如上圖所示的典型開發環境中，維護者是開發項目的成員，他們管理所描述的系統，提供，審查和批準文稿，定義和觸發構建過程。開源項目還從貢獻者那里獲得代碼貢獻，維護者可以對其進行審查并合并到項目的代碼庫中。

構建過程（build process）將攝取項目的源代碼和其他資源，并且其目標是產生軟件工件。這些工件隨后被發布，以使它們可供最終用戶和其他開發項目使用。

項目資源位于版本控制系統（VCS）中，例如Git，并將其復制到構建系統的本地文件系統中。在這些資源中有直接依賴項的聲明，在構建過程開始時，依賴項管理器會對其進行分析，以建立具有所有直接和傳遞性依賴項的完整依賴項樹。由于在構建期間（例如，在編譯時或在測試執行期間）都需要它們，因此它們是從軟件包存儲庫中下載的，這些存儲庫包括用于Python的PyPI，用于Node.js的npm或用于Java的Maven Central。

在成功構建的最后，程序代碼和其他資源被組合到一個或多個構建工件中，這些工件可能會被簽名并最終發布。要么是諸如應用商店之類的分發平臺，以便最終用戶可以使用它們，要么將其打包為其他開發項目的存儲庫。

這樣的項目環境受眾多信任邊界的約束，并且許多威脅都針對各自的數據流，數據存儲和流程。即使僅考慮單個軟件項目的環境，管理這些威脅也可能具有挑戰性。當考慮具有數十個或數百個依賴項的供應鏈時，要注意每個單獨的依賴項都存在這樣的環境。顯然，此類項目的組合攻擊面比完全由內部開發的軟件要大得多。

從攻擊者的角度出發，惡意行為者打算通過感染一個或多個上游開源軟件包來損害軟件項目的構建或運行時環境的安全性，每個上游開源軟件包均在與上圖相當的環境中開發。在以下各節中，將通過兩個攻擊樹來描述實現此目標的方法，這兩個攻擊樹提供了有關攻擊路徑的結構化概述，這些攻擊路徑用于將惡意代碼注入下游用戶的依賴樹并在不同時間或不同條件下觸發其執行。

B、注入惡意代碼

上圖所示的攻擊樹的最高目標是將惡意代碼注入到下游軟件包的依賴樹中。因此，一旦具有惡意代碼的軟件包在分發平臺（例如，分發平臺）上可用，就可以實現該目標。軟件包存儲庫成為一個或多個其他軟件包的直接或傳遞依賴項。這樣，這種類型的代碼注入不同于其他注入攻擊，其中許多攻擊在應用程序運行時利用安全漏洞，例如，安全漏洞。由于缺乏用戶輸入清理功能而可能導致緩沖區溢出攻擊。要將軟件包注入依賴樹中，攻擊者可能會采用兩種可能的策略，即感染現有軟件包或提交新軟件包。

顯然，使用其他人未使用的名稱開發和發布新的惡意程序包可以避免干擾其他合法項目維護者。但是，此類程序包必須由下游用戶發現并引用，以便最終進入受害者程序包的依賴關系樹中。這可以通過使用與現有軟件包名稱類似的名稱（搶注）或通過開發和推廣木馬病毒來實現。攻擊者還可能借此機會重用由其原始的合法維護者撤回的現有項目，程序包或用戶帳戶的標識符（免費使用）。

第二種策略是感染已經具有用戶、貢獻者和維護者的現有軟件包。攻擊者可能出于各種原因選擇軟件包，例如大量或特定的下游用戶組。但是，到目前為止收集的數據尚無法驗證相應的假設。一旦攻擊者選擇了要感染的軟件包，就可以將惡意代碼注入到源中，在構建過程中或注入到軟件包存儲庫中。

開源項目通過社區的貢獻來生存和奮斗，因此，攻擊者可以模仿良性的項目貢獻者。例如，攻擊者可能通過創建帶有錯誤修復或看似有用的功能或依賴項的拉取請求（PR）來假裝解決現有問題。后者可以用來創建對使用先前描述的技術從頭創建的攻擊者-控制器程序包的依賴關系。無論如何，此PR必須由合法的項目維護者批準并合并到主代碼分支中。或者攻擊者可能會通過使用脆弱或受到破壞的憑據或對安全敏感的API令牌將攻擊者的全部惡意代碼提交給項目的代碼庫。

此外，攻擊者可以通過社會工程成為維護者。在任何情況下，無論惡意代碼如何添加到源中，無論在哪里進行構建，它都將在下一個發行版本中成為正式軟件包的一部分。與對構建系統和軟件包存儲庫的攻擊相比，VCS中的惡意代碼更易于手動或自動查看提交或整個存儲庫。

構建系統的折衷通常需要篡改在整個構建過程中使用的資源，例如編譯器，構建插件或網絡服務（例如代理或DNS服務器）。如果構建系統（無論是開發人員的工作站還是Jenkins之類的構建服務器）容易受到漏洞攻擊，或者如果通信渠道不安全以致攻擊者可以操縱從存儲庫中下載軟件包，這些資源可能會受到損害。目標軟件包的發布版本也可以在共享的構建系統上運行，因此可以被多個項目使用。

根據設置的不同，此類構建過程可能不是孤立運行的，因此，包緩存或構建插件之類的資源會在不同項目的構建之間共享。在這種情況下，攻擊者可能會在其控制下的惡意構建項目期間破壞共享資源，從而使目標項目在以后的時間點受到破壞。

即使是流行的軟件包系統信息庫，也仍然會遭受簡單但嚴重的安全漏洞。盡管所有其他攻擊媒介都試圖將惡意代碼注入到單個程序包中，但利用程序包存儲庫中的漏洞本身會使帶有其所有程序包的整個存儲庫處于危險之中。

類似于在源代碼中注入代碼，攻擊者可能會使用脆弱或受到破壞的憑據或通過社會工程獲得維護者授權，以發布合法版本的惡意版本。由于前者已被用于多種攻擊中，因此諸如核心基礎設施（Core Infrastructure Initiative）的徽章計劃之類的計劃向項目維護者提供了正式建議，以啟用雙因素身份驗證。

此外，攻擊者可能會將惡意程序包版本上載到原始維護者未提供的備用存儲庫或存儲庫鏡像，并等待受害者從那里獲取依賴關系。據說此類存儲庫和鏡像不那么受歡迎，攻擊取決于受害者的配置，例如查詢依賴關系或使用鏡像的存儲庫順序。

C、執行惡意代碼

一旦某個項目的依賴關系樹中存在惡意代碼，上圖所示的攻擊樹就具有在不同條件下觸發惡意代碼的頂級目標。這樣的條件可以用來逃避對特定用戶和系統的檢測和/或目標攻擊。

惡意代碼可能在受感染的軟件包及其下游用戶的不同生命周期階段觸發。如果測試用例中包含惡意代碼，則攻擊主要針對被感染程序包的貢獻者和維護者，他們在其開發人員工作站和構建系統上運行此類測試。

在許多記錄的攻擊中，惡意代碼被包含在安裝腳本里，安裝腳本在軟件包安裝期間由下游用戶或其依賴關系管理器自動執行。此類安裝腳本適用于Python和Node.js，可用于執行安裝前或安裝后活動。安裝腳本中的惡意代碼使下游程序包的提供者和維護者及其最終用戶受到威脅。惡意代碼也可能在下游程序包的運行時觸發，這要求將其作為受害者程序包的常規控制流的一部分進行調用。

在Python中，這可以通過在init .py中包含惡意代碼來實現，該惡意代碼通過import語句調用。在JavaScript中，這可以通過猴子補丁（monkey-patching）等現有方法來實現。細化此目標可以輕松涵蓋各個編程語言，程序包管理器等的細節。

與生命周期階段無關，惡意行為的執行可能總是觸發（無條件的）或僅在滿足某些條件時（有條件的執行）觸發。對于任何其他惡意軟件，條件執行會使惡意開源軟件包的動態檢測復雜化，因為在沙箱環境中可能無法理解或滿足相應條件。以應用程序狀態為條件的執行是逃避檢測的常見手段，例如在測試環境或專用的惡意軟件分析沙箱中。同樣，各個構建系統的細節可能會包含在各自的子目標中，例如Jenkins環境變量的存在表明惡意代碼是在構建期間而不是在生產環境中觸發的。

此外，條件可能與特定的受害者包有關，例如檢查特定的應用程序狀態，例如加密錢包的余額。大量重復使用開放源代碼軟件包可能導致以下事實：惡意軟件包最終出現在許多下游軟件包的依賴關系樹中。如果攻擊者只對某些軟件包感興趣，則它們可能會在手邊給定依賴關系樹的節點上限制代碼執行。此外，所使用的操作系統可以作為條件。

05Description of the Dataset

總共可以識別469個惡意軟件包。此外，還發現了59個可被確認為POC的軟件包（由研究人員發布），因此不再進行進一步檢查。最終，能夠為174個軟件包獲得至少一個受影響的版本。Npm的惡意軟件包成功下載率為109/374（29.14％），PyPI為28/44（63.64％），RubyGems為37/41（90.24％）和Maven Central為0/10（0.00％）。

A、組成和結構

該數據集包含在npm上發布的62.6％的程序包，因此是用JavaScript為Node.js編寫的。其余的軟件包通過PyPI（16.1％，Python）和RubyGems（21.3％，Ruby）發布。不幸的是，無法下載針對Android開發人員的惡意Java軟件包。對于PHP，根本無法識別任何惡意軟件包。

完整的數據集可在GitHub上免費獲得:https://dasfreak.github.io/Backstabbers-Knife-Collection。出于道德原因，僅在有正當理由的情況下才允許訪問。數據集的結構如下：package-manager/package-name/version/package.file。惡意軟件包在第一級由其原始軟件包管理器分組。此外，一個軟件包的多個受影響版本會在相應軟件包名稱下。事件流受影響版本示例：npm/event-stream/3.3.6/event-stream-3.3.6.tgz。

B、時間方面

上圖可視化了收集到的軟件包的發布日期，范圍從2015年11月到2019年11月。發布和披露日期是根據軟件包的上載時間和相應通報的發布日期來標識的，這些通報將相應版本標識為惡意。顯然，已發布的惡意軟件包數量呈增長趨勢。雖然已知用于PyPI的惡意程序包可以追溯到2015年，并且此后一直在增加，但npm在2017年獲得了大量惡意程序包，而RubyGems上的惡意程序包在2019年經歷了最高點。

上圖顯示在被公開報告之前，平均有209天的惡意軟件包可用（min=-1，max= 1216，ρ= 258，x= 67）。盡管知道npm/eslint-scope/3.7.2的感染，但由于開發人員的重新打包策略，該軟件包仍在使用中。npm/rpc-websocket/0.7.7最大值達到了1,216天，它接管了一個廢棄的軟件包，很長時間沒有被發現。

總的來說，這表明軟件包傾向于長期可用。雖然PyPI的平均在線時間最高，但該時間段的npm變化最大，而RubyGems傾向于更及時地檢測到惡意軟件包。

C、惡意行為的觸發

程序包的惡意行為可能在與程序包交互的不同點觸發。最典型地，可以安裝、測試或執行軟件包。每個軟件包存儲庫的分離如下圖所示。它說明了在安裝過程中對任意代碼的錯誤處理會產生使用最多的感染媒介。

顯然，大多數惡意軟件包（56％）會在安裝時啟動其例程。這可以由軟件包存儲庫的安裝命令觸發，例如npm install 。這會調用軟件包定義中定義的代碼，例如package.json和setup.py。該代碼對于執行安裝軟件包所需的任何操作可能是任意的，例如下載其他文件。對于PyPI上的惡意軟件包，這似乎很常見。

與此相反，Ruby沒有實現這種安裝邏輯，Ruby中不存在該情況的軟件包。因此，在RubyGems上找到的所有包都將運行時用作觸發器。總體而言，有43％的程序包在程序運行時（即從其他函數調用時）暴露了其惡意行為。

對于1％的軟件包，測試程序被用作觸發器。調用npm/ladder-text-js/1.0.0的測試例程將執行sudo rm-rf / *，這可能會刪除所有文件。

D、有條件的執行

如上圖所示，有41％的軟件包在檢查條件之前會觸發進一步的執行。這可能取決于應用程序的狀態，例如檢查主應用程序是否處于生產模式（例如RubyGems/paranoid2/1.1.6），域名的可解析性（例如npm/logsymbles/2.2.0）或加密錢包中包含的金額（例如npm/flatmap- stream/0.1.1）。

其他技術是檢查依賴關系樹中是否存在另一個軟件包（例如npm/load-from-cwd-or-npm/3.0.2）或該軟件包是否在某個操作系統上執行（例如PyPI / libpeshka / 0.6）。

在PyPI和RubyGems上發布的大多數軟件包都是無條件執行的。對于npm，條件執行和無條件執行的比率幾乎相等。

E、注入惡意軟件包

在上圖中，很明顯，大多數（61％）惡意軟件包都是通過域名搶注來模仿現有軟件包的名稱的。對該現象的更深入分析顯示，平均搶注程序包到目標的Levenshtein距離為2.3（,,min= 0，max= 11，ρ= 2.05，x= 1.0）。在某些情況下，可以從其他軟件包存儲庫中獲得搶注目標。完全相同名稱的Linux軟件包系統信息庫apt。例如python-sqlite就是這種情況。在以kafka-python為目標的pythonkafka的情況下，最大距離為11。常用的技術是添加或刪除連字符，省略單個字母或交換經常被錯誤鍵入的字母。經常被針對的單詞是,,color”或與之對應的英式英語單詞,,color”。

第二種最常見的注入方法是感染現有包裝。這通常可以通過存儲庫系統的憑據受損（例如npm/eslint-scope/3.7.2）來實現。在大多數情況下，無法回顧確切的感染技術。這是因為相關的來源通常會從版本控制系統中刪除，或者沒有進一步公開有關注入的詳細信息。因此，這些軟件包被列為感染現有軟件包。

另一種注入技術是創建一個新軟件包，其中僅包含木馬惡意軟件包。在這些軟件包中找不到有意義的拼寫搶注目標。這些軟件包可以與受感染的現有軟件包結合使用，也可以獨立使用。

F、主要目標

如下圖所示，大多數軟件包都針對數據滲透。通常，感興趣的數據是/etc/passwd，~/.ssh/*，~/.npmrc或~/.bash歷史記錄的內容。此外，惡意程序包試圖泄漏環境變量（其中可能包含訪問令牌）和常規系統信息。另一個流行的目標是語音和文本聊天應用程序Discord的令牌。Discord用戶的帳戶可能會鏈接到信用卡信息，因此可用于財務欺詐。

此外，有34％的軟件包充當Dropper來下載第二階段的有效負載。另有5％的用戶利用后門（即反彈shell）到遠程服務器，并等待進一步的說明。3％的目的是通過用fork炸彈和文件刪除（例如npm/destroyer-of-worlds/1.0.0）耗盡資源或破壞其他軟件包的功能（npm/load-from-cwd-or-npm/3.0.2）。3％將財務收益作為主要目標，如在后臺運行加密礦工（npm/hooka-tools / 1.0.0）或直接竊取加密貨幣（例如pip/colourama/0.1.6）。另外，可能會發生上述目標的組合。

G、目標操作系統

為了識別目標操作系統，對源代碼進行了手動分析，以獲得可能像if platform.system() is “Windows”一樣構造的提示，例如使用PyPI/openvc/1.0.0 或者通過依賴僅在某些OS上可用的資源而隱含的。這些資源可能是包含敏感信息的文件，如.bashrc等（npm/font-scrubber/1.2.2）或可執行文件，如/bin/sh（npm/rpc-websocket/0.7.11）。

對針對其目標操作系統（OS）的軟件包的分析表明，大多數軟件包（53％）是不可知的，即不依賴于操作系統特定的功能。該分析是對程序包的初始可見代碼進行的，因此第二階段有效負載的目標OS仍然未知。但是，由于構建環境通常是在此類OS上運行的，因此與Unix類似的系統似乎比Windows和macOS更具針對性。

只有一種已知的macOS案例是目標，其中軟件包npm/angluar-cli/0.0.1通過刪除和修改macOS的McAfee病毒掃描程序對macOS進行拒絕服務攻擊。

H、混淆

惡意行為者經常試圖掩蓋其代碼的存在，即阻礙其被肉眼看到。在數據集中將近一半的軟件包（49％）采用了某種混淆處理。大多數情況下，使用不同的編碼（Base64或Hex）來掩蓋惡意功能或可疑變量（例如域名）的存在。

良性軟件包經常使用的一種壓縮源代碼并節省帶寬的技術是最小化的。但是，這對于惡意行為者來說是一個機會，可以潛入人類無法讀取的額外代碼（例如npm/tensorplow/1.0.0）。隱藏變量的另一種方法是使用字符串采樣。這需要一個看似隨機的字符串，該字符串用于通過逐個字母的選擇來重建有意義的字符串（例如npm/ember-power-timepicker/1.0.8）。

在一種情況下，惡意功能被加密隱藏。軟件包npm/flatmap-stream/0.1.1利用AES256和目標軟件包的簡短描述作為解密密鑰。這樣，惡意行為僅在目標軟件包使用時才暴露出來。此外，存在上述技術的組合。

I、群集

為了推斷攻擊活動的存在，對所有軟件包進行了分析，以重新使用惡意代碼或依賴關系。這樣，有可能識別出21個群集，至少有兩個程序包具有相同的惡意代碼，或者由攻擊者控制的程序包依賴于另一個具有實際惡意代碼的程序包，這些群集至少有兩個。總共174個軟件包中的157個（占90％）屬于一個集群。平均而言，群集包括7.28個程序包（min= 2，max= 36，ρ= 8.96，x = 3）。

對一個群集中的包裝的出版物發布日期進行交叉比較發現，發布之間的平均時間間隔為42天,618（min=140，max= 353天,1102，ρ= 78天,010，x = 7天,1551）。最大的集群形成在crossenv的36個軟件包，平均時間間隔為5.98天。它分兩期發布，2017年7月19日在15分鐘內發布了11個軟件包，2017年8月1日在30分鐘內發布了另外25個軟件包。

發布日期間隔為353天的集群由兩個軟件包PyPI/jeilyfish /0.7.0和PyPI/python3-dateutil /2.9.1組成。第一次發布于18/12/11 12:26 AM，其中包含的代碼可以下載腳本以從Windows計算機中竊取SSH和GPG密鑰。直到第二個軟件包在19/29/19 11:43 AM發布之后很長時間都未被檢測到，該軟件包本身并不包含惡意代碼，但引用了第一個軟件包。在19/12/19 05:53 PM被報告并刪除了該群集。

盡管大多數群集只包含一個軟件包存儲庫中的軟件包，但是可以找到一個群集，其中主要包含npm中的軟件包，以及RubyGems中的RubyGems/active-support/5.2.0。這意味著存在攻擊活動，或者至少技術跨多個軟件包存儲庫流動。

J、兩個惡意軟件包的代碼審查

根據對代碼相似性的手動評估，上圖的npm/jqeury/3.3.1（左）和RubyGems/active-support/5.2.0（右）都屬于同一集群，即使它們發布在不同的存儲庫中。

06Conclution

從攻擊者的角度來看，程序包存儲庫代表了可靠且可擴展的惡意軟件分發渠道。到目前為止，Node.js（npm）和Python（PyPI）的存儲庫是惡意軟件包的主要目標，這可能是由于在軟件包安裝過程中可以輕松觸發惡意代碼這一事實。已經存在許多可以由不同利益相關者實施的對策，例如面向開放源代碼維護者的多因素身份驗證，面向開放源代碼用戶的版本固定和禁用安裝腳本，或者隔離構建過程和增強構建服務器。

但是，盡管提高了利益相關者的普遍意識，這種對策必須更易于訪問，并且在可能的情況下默認實施，以防止開源軟件供應鏈攻擊。

A、結果

從觀察到的案例和相關工作中得出了兩個攻擊樹。一種用于將惡意程序包注入開源生態系統，另一種用于執行惡意代碼。這些攻擊樹可對過去和將來的攻擊進行系統描述。能夠創建第一個手動管理的惡意開源軟件包的數據集，該數據包已在現實世界的攻擊中使用。從2015年11月到2019年11月，它包含174個惡意軟件包（npm 62.6％，PyPI 16.1％，RubyGems 21.3％）。

手動分析顯示，大多數軟件包（56％）會在安裝時觸發其惡意行為，另有41％使用進一步的條件確定是否運行。超過一半的軟件包（61％）利用域名搶注將自身注入到生態系統中，而數據泄露是最常見的目標（55％）。這些軟件包通常與操作系統無關（53％），并且經常采用混淆處理（49％）來隱藏自身。最終可以通過不同的編程語言，通過重用的代碼來檢測惡意軟件包的多個群集。

B、未來的工作

希望有新的技術和工具來掃描整個程序包存儲庫中的可疑程序包，例如根據觀察發現惡意代碼可在同一廣告系列的程序包甚至語言之間重復使用。在這種情況下，手動管理和標記的數據集允許有監督的學習方法，這些方法支持對惡意軟件包的自動化和整個存儲庫范圍內的搜索。此外，關于現有和新的緩解策略，本文提出的數據集可作為基準。

審核編輯 ：李倩