事後分析：axios NPM 供應鏈遭入侵事件

背景

知名 HTTP 客戶端函式庫 Axios 近期爆發 NPM 供應鏈入侵事件，一名維護者的電腦遭植入遠端存取木馬（RAT），導致攻擊者能以其身分發布惡意版本。雖然社群成員在事發後一小時內便回報異常，但攻擊者隨即利用權限刪除檢舉紀錄，試圖掩蓋行蹤。此事件再次引發開發者社群對於 NPM 安全機制、雙重驗證（2FA）侷限性以及維護者責任歸屬的激烈辯論。

社群觀點

針對此次入侵，社群首先關注的是現有防禦機制的失效。許多討論指出，即便維護者啟用了軟體形式的雙重驗證（如 TOTP），一旦開發機被植入 RAT，攻擊者便能輕易攔截驗證碼或竊取復原金鑰。部分留言者建議 NPM 應強制要求高流量專案使用實體硬體權杖（如 YubiKey），認為這能有效阻斷遠端攻擊者的自動化操作。然而，反對意見認為，若攻擊者具備足夠耐心且已完全控制主機，任何基於該機器的發布流程都難保絕對安全。

爭論的核心在於「誰該為安全負責」。有觀點嚴厲批評 Axios 團隊疏於防範，認為在當前的資安環境下，不使用數位簽章（Code Signing）或智慧卡保護金鑰的維護者等同於「不洗手的醫生」，屬於專業上的失職。這派意見主張 NPM 應強制推行套件簽章，並要求所有合併至主分支的程式碼必須經過兩位維護者的數位簽署。但隨即有反駁指出，Axios 其實已採取了相當先進的防護，例如使用 OIDC 流程與來源證明（Provenance Attestation），且惡意版本是直接從本地端發布而非透過 Git 提交，這顯示即便維護者遵循了最佳實踐，NPM 平台目前仍缺乏「禁止本地發布、僅限 CI/CD 發布」的強制選項，這才是系統性的漏洞。

此外，社群也對攻擊者的手法感到憂心。據悉維護者是在參加一場 Microsoft Teams 會議時，被告知系統過時並誘導下載了惡意軟體，這種結合社交工程與遠端執行（RCE）的複合式攻擊，顯示供應鏈威脅已演變成國家級規模的對抗。部分開發者感嘆，NPM 的設計初衷本就允許執行不信任的程式碼，要在這種架構上建立完全安全的防禦體系，無異於要求鴕鳥飛行。更有討論提到，雖然惡意版本缺乏合法的來源證明，但實務上幾乎沒有下游使用者會去檢查這些細節，導致防禦機制形同虛設。

延伸閱讀

• 惡意負載分析報告：由 SafeDep 提供的詳細調查，揭露該惡意軟體具備執行任意 Shell 指令的能力，而不僅僅是竊取憑證。
• Axios 維護者說明：在 GitHub Issue #10636 中的詳細回覆，記錄了社交工程的具體過程與技術細節。