作者 | 褚杏娟
近日，不少開發者（https：//v2ex。com/t/840562#reply11）在使用到 vue -cli 中的 node-ipc 模組時，這個依賴項會在桌面以及其他位置建立一個叫做“WITH-LOVE-FROM-AMERICA。txt”的檔案，不過開啟這個檔案是空的。據悉，該 package 每週下載量達到了百萬。另外，使用 Yarn 的開發者也受到了影響。
以反戰為名的供應鏈投毒？
開始有人以為只是個惡作劇，但事情並非如此簡單。有開發者在對程式碼進行測試處理後發現，node-ipc 包的作者 RIAEvangelist 在投毒。他起初提交的是一段惡意攻擊程式碼：如果主機的 IP 地址來自俄羅斯或白俄羅斯，該程式碼將對其檔案進行攻擊，將檔案全部替換成 。該作者是個反戰人士，還特意新建了一個 peacenotwar 倉庫來宣傳他的反戰理念。
攻擊原始碼地址：https：//github。com/RIAEvangelist/node-ipc/blob/847047cf7f81ab08352038b2204f0e7633449580/dao/ssl-geospec。js
TC39 代表、Web 開發工程師賀師俊在知乎上分析稱（https：//www。zhihu。com/question/522144107/answer/2391166752），原始碼經過壓縮，並簡單地將一些關鍵字串進行了 base64 編碼，目的是利用第三方服務探測使用者 IP，針對俄羅斯和白俄羅斯 IP 嘗試覆蓋當前目錄、父目錄和根目錄的所有檔案。
雖然作者刪除了該段程式碼，但賀師俊認為這仍然是一種惡劣的供應鏈投毒。“這裡，具體的動機不重要，無論其動機多麼良好（更不用說，很多人可能並不同意其政治傾向和道德立場），這樣的行為都嚴重破壞了開源生態中的信任。”
OpenHarmony 專案群工作委員會執行總監、中國科學院軟體研究所高階工程師羅未也表示，開源軟體供應鏈安全是一個及其嚴酷的議題，如果說 log4j 還能看做難以避免的工程誤差，這件事就存在違法嫌疑。
有開發者提供了該問題的解決方式：首先按照 readme 正常 install，構建結束後，用編輯器全域性搜尋‘peacenotwar’，將其全部刪除；然後在專案的 node_models 目錄下，將‘peacenotwar’目錄刪除；之後將‘專案 /node_modules/node-ipc/node-ipc。js’這個檔案中引用‘peacenotwar’的程式碼註釋掉，便可以正常啟動專案。
此外，Vue-cli 昨天釋出了新版本5。0。2（https：//github。com/vuejs/vue-cli/blob/dev/CHANGELOG。md），將 node-ipc 版本鎖定到 v9。2。1，使用者可以直接升級。據悉，受惡意程式碼受影響的 node-ipc 版本為 v10。1。3 ，已經被作者刪除或被 NPM 撤下，而 WITH-LOVE-FROM-AMERICA。txt 檔案是由 v11。0。0 版本引入的。
在此次事件中，有開發者認為（https：//github。com/vuejs/vue-cli/issues/7054）Vue 團隊在釋出新版本方面做得還不夠，Vue 團隊應該在官方網站上新增關於該事件的彈出視窗，棄用所有受感染的 vue-cli 包，為其新增一條訊息。另外還可以在釋出新版本時新增一些警告，以便使用者看到警告並自動升級。
脆弱的 Node。js 生態
這一事件再次顯示了 JS/Node/NPM 生態的脆弱。
去年 10 月，NPM 官方倉庫 ua-parser-js 被惡意劫持，多個版本被植入了挖礦指令碼。這個庫每週下載數百萬次，被用於一千多個專案，包括 Facebook、微軟、亞馬遜、Instagram、谷歌、Slack、Mozilla、Discord、Elastic、Intuit、Reddit 等公司的專案。同年 2 月，NPM 遭遇供應鏈投毒攻擊，其官方倉庫被上傳了 radar-cms 惡意包，藉此竊取 K8s 叢集憑證。
NPM 模組備受開發人員歡迎，這些模組間還普遍存在複雜的依賴關係，某個包通常安裝另一個包作為依賴項，而開發人員對此卻並不知情。依賴項的絕對數量也帶來了更多的安全問題。只要破壞了開發人員普遍使用的流行包，惡意程式碼可以直接大規模地傳播給受害者，而這完全可以透過依賴混淆、劫持弱憑據、利用漏洞訪問目的碼或使用開發人員放棄的包的名稱來完成。
另外，NPM 儲存庫 npmjs。com 不要求 NPM 包中的程式碼與連結的 GitHub 儲存庫中的程式碼相同。這意味著攻擊者不需要破壞 GitHub 儲存庫，只要破壞 NPM 包即可。
賀師俊在知乎上表示，要解決或緩解這一問題，應該考慮在 JS 語言和 JS 執行時層面引入一些機制，比如說針對包級別的許可權管理（deno 那樣粗粒度的應用級別的許可權管理並不足以解決供應鏈投毒問題）、在更多的 API 中引入類似 TrustedType 的機制等。“而這顯然已經超出了庫、框架或工程管控的層面。這也是為什麼我一直說國內頭部大廠應該要投入資源去參與語言標準、引擎和平臺實現。”
羅未提出，開源軟體可參照其他行業的處理方式，如建築設計師要終生為建築設計質量擔責、銀行批貸員要終生為發放的貸款擔責等。
“開源軟體，特別是重要的核心開源軟體，往往遠比一筆貸款或一個建築對全球社會經濟影響深遠。開源軟體作為一個具有風險的重型工程行業，必須匹配的行業風險管控體系，這是我們不得不面對的問題。”
結束語
“看一遍開源協議，要麼 fork 要麼忍著。”有開發人員對該事件評論道。前有 Node、React、pytorch、GitHub 等官網宣告支援烏克蘭，後有個人開發者進行供應鏈投毒，戰爭讓大家對開源有了不同以往的認識。
開源組織應不應該旗幟鮮明地表達自己技術之外的立場，並利用自身影響力去支援某一方呢？這是一個仁者見仁、智者見智的問題，我們不做贅述。但這個問題實實在在地出現了，就成了整個開源行業應該考慮的問題：當開源開始“站隊”時，開發者該如何自處？