供應鏈攻擊案例整理：從 SolarWinds、3CX 到 axios、LiteLLM，企業發包系統要記住的教訓

我們團隊每天早上第一件事，是看一份自動產生的清單：昨晚國際公開漏洞資料庫與台灣 TWCERT 又通報了哪些高風險漏洞，有沒有剛好落在我們維護中系統用到的程式套件上。這份清單大部分日子是空的。會讓人停下手邊工作的那幾天，通常就是下面這幾個供應鏈攻擊案例登上新聞的日子。

供應鏈攻擊，一句話講就是：駭客不直接打你，改去打你信任的廠商、軟體或開源套件，再跟著正常的更新管道一起進門。完整的定義與防禦框架可以先看我們拆過的 TanStack npm 供應鏈攻擊全解析；這篇專門整理真的發生過的案例，每一起都附上官方或研究機構的原始來源，讓老闆與 IT 主管看完能回答兩個問題：真的有公司被這樣打過嗎？我們發包系統時要多要求廠商什麼？

先看規模。Verizon 每年出版的資料外洩調查報告，2025 年版統計出一個讓採購部門很難忽視的數字：有第三方涉入的資料外洩，比例從前一年的 15% 翻倍到 30%，Help Net Security 的整理 把它列為整份報告最大的變化之一。換句話說，每三起外洩就有一起，問題出在「別人家」。

供應鏈攻擊案例總覽：七起事件一張表看懂

先給答案：下面七起事件都經過查證，時間跨度從 2020 年到 2026 年，入口各不相同，但結局都一樣，受害者是一大群「什麼都沒做錯、只是照常更新」的下游企業。表格最右欄是被發現的方式，這一欄比攻擊手法更值得老闆細看。

七起裡面，只有一起是被攻擊的那家公司自己發現的。這點後面會專門講。另外兩起類型很接近、也常被拿來討論的事件，放在這裡補充：2021 年 7 月 Kaseya 的遠端管理軟體 VSA 被勒索軟體集團利用零時差漏洞攻擊，The Record 報導 引述 Kaseya 的說法，大約 50 家 IT 代管業者中招，下游受影響的企業約 800 到 1,500 家；Notepad++ 則在 2026 年 2 月公開承認，2025 年 6 月到 12 月間更新管道被劫持，部分使用者被導到惡意的更新伺服器，The Record 引述開發團隊說法，研究人員認為很可能是國家級駭客所為。

供應鏈攻擊從哪裡進來？案例歸納出三種入口

簡單講，駭客挑的是「你會自動相信的東西」。把上面的案例攤開，入口大致分成三類，每一類對應到企業不同的盲點。

第二類是近兩年最常出事的地方，也是中小企業最容易忽略的地方。一套看起來普通的客製化系統，背後可能掛著幾百個開源套件，套件又各自依賴更多套件。你跟廠商簽約買的是「一套系統」，實際上買進來的是一整串你沒見過的程式碼。這也是為什麼我們自己營運的產品，例如 秒發報價Pro 與 SalesKing，每天早上都會自動比對用到的套件有沒有新的高風險漏洞，有新增才通知負責人，由人判斷影不影響、要不要排修補。

第三類則牽涉到權限。代管廠商、維運廠商手上通常握著你系統的帳號，駭客打下廠商就等於拿到你的鑰匙。微軟 10 月點名的 ConnectWise 事件就是同一型，我們在 ARTEX 與 ConnectWise 供應鏈攻擊拆解 裡整理過，駭客用的是客戶早已授權給廠商的權限，系統看到的每一步都是「合法登入」。

經典供應鏈攻擊案例：SolarWinds、3CX、xz utils

這三起是講供應鏈攻擊一定會被提到的事件，分別代表三種入口裡最難防的版本：正式更新被改、員工個人電腦變跳板、開源維護者本人就是攻擊者。每一起用同一張卡片格式整理，方便對照。

SolarWinds Orion：正式更新檔裡藏著後門

這起事件嚴重到美國網路安全暨基礎設施安全局（CISA）在 2020 年 12 月 13 日發布 緊急指令 21-01，要求聯邦機關立刻把 Orion 斷線。對一般企業來說，最值得記住的是時間差：問題版本從 2020 年春天就開始散布，到 12 月才曝光，攻擊者在很多網路裡待了好幾個月。

3CX：一次供應鏈攻擊引發另一次供應鏈攻擊

Mandiant 在 2023 年 4 月 20 日公布的 調查報告 說，這是他們第一次看到「一次軟體供應鏈攻擊直接造成另一次軟體供應鏈攻擊」，並以中等信心把它歸因到北韓相關的駭客。對發包企業的啟示很直接：廠商工程師用什麼電腦、裝了什麼軟體、能不能用個人裝置連進開發環境，這些看似是廠商的內部管理，最後都會變成你的風險。

xz utils：花兩年取得信任的開源後門

CISA 在 2024 年 3 月 29 日當天就發出 警示，建議降回未受影響的版本。業界普遍認為這次是「運氣好」：如果那位工程師沒有對半秒的延遲起疑，後門很可能跟著穩定版散布到全球大量伺服器。運氣不是一種防禦策略，這也是後面「怎麼被發現」那一節要講的重點。

台灣供應鏈攻擊案例：行銷公司的程式碼被改，上千個網站跟著遭殃

台灣不是旁觀者。Google 威脅情報小組在 2025 年 11 月 20 日發表的 APT24 研究 裡寫得很清楚：2024 年 7 月，這個被認為與中國有關的駭客組織攻下台灣一家區域型數位行銷公司，影響超過 1,000 個網域，而且這家公司在之後一年內被反覆入侵好幾次。

這個案例對中小企業特別有感。很多公司官網都掛著行銷公司、客服工具、分析工具提供的一段程式碼，網站本身寫得再好，那段外部程式碼被改，訪客一樣中招。更麻煩的是攻擊者只挑特定訪客下手，一般人打開網站完全看不出異狀，網站主自己更不會發現。

政府機關也遇過同類問題。iThome 在 2021 年 1 月的 報導 提到，法務部調查局在 2020 年下半年就示警，承包政府標案的委外廠商被入侵後，原本為了遠端維運而開給廠商的 VPN 帳號，變成駭客進入機關的通道。時間雖然是幾年前，問題到今天仍然存在。數位發展部資安署公布的統計顯示，2025 年公務機關通報的資安事件有 726 件，其中非法入侵占 68.60%，新北市政府轉載的宣導資料 有完整數字。

近一年的開源套件供應鏈攻擊：npm、Trivy、LiteLLM、axios

一句話：2025 年下半到 2026 年上半，攻擊者明顯把火力集中在開發者每天在用的套件與工具。這幾起事件有一個共同點，惡意版本都只存活幾個小時，但下載量大到幾個小時就夠了。TanStack 在 2026 年 5 月的事件也是同一波趨勢，細節在 TanStack npm 供應鏈攻擊全解析。

npm chalk、debug：一封假的雙重驗證信

Endor Labs 的整理 把這次稱為 npm 史上規模最大的一次帳號劫持。值得注意的是攻擊者拿到的是「即時」的驗證碼，所以一般手機驗證碼型的雙重驗證完全擋不住，這也是業界一直推廣硬體金鑰與通行密鑰的原因：這兩種驗證方式綁在特定裝置與網域上，假網站拿不到可以轉用的憑證。

Trivy、KICS、LiteLLM：資安工具本身變成入口

時間線很緊湊：Wiz 的分析 指出 Trivy 在 2026 年 3 月 19 日出事；3 月 23 日 KICS 的 35 個版本標籤全被改掉，Wiz 另一篇 認為用的正是前一波偷到的憑證；3 月 24 日輪到 LiteLLM，NetSPI 建議裝過問題版本的單位，把那台機器上能接觸到的所有密碼、金鑰都當成已經外洩。這組案例最諷刺的地方在於，很多公司裝這些工具，就是為了提升資安。

axios：每週上億次下載的套件，惡意版本只活了三小時

Google 威脅情報小組與 Mandiant 在 事件當天的分析 把它歸因到北韓相關、以獲利為目的的駭客組織 UNC1069。三小時聽起來很短，但對每週上億次下載的套件來說，自動化建置流程在這段時間裡會拉到多少次問題版本，沒人算得清。北韓駭客近年在供應鏈與工程師身上下的功夫，在 幣安被駭事件拆解 裡也看得到。

供應鏈攻擊案例的共同點：多半是別人發現的

直接講結論：這些案例裡，受害的下游企業幾乎沒有一家是自己發現的。發現者通常是資安公司、研究團隊，或剛好起疑的工程師。下游企業能做的，是在消息出來的那一刻，能不能在幾小時內回答「我們有沒有用到」。

這張表的最後一欄是重點。能不能快速回答，取決於平常有沒有一份「系統用了哪些軟體與套件」的清單，業界叫它軟體物料清單（SBOM）。沒有這份清單，每次大新聞都要工程師一台一台查，查到的時候往往已經過了好幾天。

我們的看法比較直接：中小企業沒有預算請資安團隊做威脅獵捕，也不需要。真正該花錢的地方，是讓系統「被問到時答得出來」，以及「有新漏洞時有人知道」。這兩件事做到，就能把大部分供應鏈攻擊的損害壓在可控範圍。花大錢買一套很厲害的偵測工具，卻沒有人在看它的告警，效果反而不如一份每天更新的清單。

我們自己怎麼面對供應鏈攻擊：每天自動檢查維護中系統

說到做到，這裡交代我們自己的做法。我們是做客製化系統開發與維運的團隊，交付出去、還在維護的系統，例如自家的 秒發報價Pro，都在這套每日檢查的範圍裡。流程很單純，重點在每天都跑、有人判斷。

整套流程全程只讀取、不自動改程式。這是刻意的設計：自動升級套件聽起來省事，但 axios 與 chalk 的案例剛好說明，惡意版本最危險的就是剛發布那幾個小時，系統若在這時候自動升級，等於主動把問題版本拉進來。所以我們選擇讓機器負責「看」，人負責「改」。

從供應鏈攻擊案例學到的事：發包系統時要求廠商做到的 6 件事

先給清單，再逐條說明。這六件事都可以寫進合約或驗收條件，不需要懂技術也能要求。合約怎麼寫可以對照 軟體開發合約範本，維運期間的條款可以參考 維運合約怎麼簽。

套件清單：出事時答得出來

第一條最便宜也最有用。清單本身不防攻擊，但它決定你在下一次新聞出來時，是花十分鐘還是花三天確認影響。上線前的程式碼審計通常也會順便產出這份清單，程式碼審計完整指南 有更多細節。

版本鎖定與延後升級：讓「只活幾小時」的攻擊打空

近一年的案例裡，惡意版本存活時間大多在三小時內。只要系統不在新版本剛發布時就自動升級，大部分這類攻擊就會直接落空。延後幾天升級的代價很小，換到的是讓整個開源社群先幫你踩雷。

持續監控與通知：寫進維運合約

很多維運合約只寫「系統壞了幾小時內回應」，沒寫「有新漏洞時要不要主動通知」。建議明確寫入：哪些等級的漏洞要通知、多久內給出影響評估、修補費用怎麼算。系統上線後的維運費用常被低估，上線後 3 個月隱性成本 那篇有完整的帳本可以對照。

帳號與權限：鑰匙越少越好

chalk 與 Trivy 的案例都是從帳號與憑證開始崩。要求廠商說明發布帳號怎麼驗證、憑證多久換一次、出事時能不能一次全部換掉。這背後的概念就是 零信任：預設任何一把鑰匙都可能被偷，所以每把鑰匙能開的門要盡量少。同樣的道理也適用在你開給維運廠商的遠端權限。

外部程式碼與第三方服務：定期盤點

官網、電商、會員系統上嵌的外部程式碼與串接的第三方服務，至少每年盤點一次。服務商本身被入侵的例子也不少，像 EVERY8D 簡訊平台遭駭 與 TiDB Cloud 資安事件，都是企業把資料交給第三方之後才發現自己控制不了的風險。萬一真的出事，最後一道防線是備份，資料備份與災難復原指南 可以一起看。

看到這裡，如果你正準備發包一套新系統，或想確認手上的系統有沒有人在盯套件漏洞，我們很樂意 聽你聊聊現在的情況。這套每日檢查的做法我們自己每天在跑，可以一起看看你的系統適合從哪一步開始。

這篇屬於恆遠的資安系列，同系列還有：供應鏈攻擊是什麼、資安健檢是什麼、網站弱點掃描怎麼做、資安健檢費用怎麼算。