企業花了很多力氣把攻擊者擋在外面，卻每天主動安裝廠商推送的更新、讓 IT 服務商遠端管理伺服器、在自家程式裡引用上百個開源套件。供應鏈攻擊利用的正是這些「本來就被信任」的管道：攻擊者在產品或其交付機制送到最終使用者手上之前動手腳，範圍涵蓋開發工具、建置環境、原始碼庫、開源相依套件、軟體更新管道，一路到硬體出貨[1]。
這類攻擊特別難防，因為惡意程式帶著合法廠商的數位簽章、從正常的更新流程進來，或是透過本來就有管理權限的服務商帳號登入。本文說明供應鏈攻擊的常見型態、四個有官方文件可查的案例，以及企業在採購、合約、權限與監控上可以做的事，適合 IT 主管、採購與負責委外管理的人員閱讀。
供應鏈攻擊的四種常見型態
MITRE ATT&CK 把供應鏈入侵分成三個子技術：入侵軟體相依套件與開發工具、入侵軟體供應鏈、入侵硬體供應鏈[1]。再加上透過 IT 服務商的信任關係入侵，企業常見的入口可以歸納為四類。
被竄改的軟體更新
攻擊者入侵軟體廠商的建置環境，把惡意程式碼植入正式版本，再透過廠商自己的發行與更新管道散布。攻擊者有時會大範圍散布，再從中挑選真正的目標下手[1]。因為檔案帶有廠商簽章，端點防護與應用程式白名單通常會放行。
被污染的開源套件與開發工具
攻擊者在開源套件或開發、建置工具中植入惡意程式碼，讓所有引用它的軟體一起受影響[1]。現代軟體大量依賴開源元件，一個廣泛使用的底層套件出問題，影響範圍可能遠超過直接使用它的人所能想像。
IT 服務商與 MSP 被入侵
代管服務供應商（MSP）、系統整合商、遠端維運廠商通常握有客戶環境的高權限帳號與遠端管理工具。美、英、澳、加、紐五國資安機關在 2022 年的聯合公告中指出，預期攻擊者（包括國家支持的 APT 組織）會加強鎖定 MSP，以利用服務商與客戶之間的網路信任關係[2]。
硬體與韌體
在製造或運送過程中竄改硬體、韌體或預載軟體[1]。這類攻擊較少見、一般企業也難以自行驗證，主要對策是向可信通路採購、確認韌體來源與簽章，並維持完整的設備盤點紀錄。
四個有官方文件可查的案例
SolarWinds Orion（2020）
依 CISA 的公告，相關攻擊活動至少從 2020 年 3 月開始：攻擊者把惡意 DLL 植入 SolarWinds Orion 的軟體建置流程，並以 SolarWinds 合法的程式碼簽章憑證簽署，受影響的是 2019.4 HF5 到 2020.2 HF1 之間的特定版本[3]。後門以偽裝成正常 SolarWinds 流量的方式對外連線，CISA 在 2021 年 4 月的更新中將這起活動歸因於俄羅斯對外情報局（SVR）[3]。CISA 也發現同一批攻擊者使用了與 SolarWinds 無關的其他入口，例如密碼猜測、密碼噴灑與 SAML 權杖濫用，因此只移除 Orion 並不夠，還必須重設相關憑證、全面檢查身分驗證系統[3]。
Kaseya VSA（2021）
2021 年 7 月，勒索軟體攻擊者利用 Kaseya VSA 遠端管理軟體的漏洞，同時攻擊多家 MSP 及其下游客戶[4]。CISA 與 FBI 建議受影響的 MSP 全面啟用 MFA，並把遠端監控管理（RMM）工具的通訊限定在已知 IP，或把管理介面放在 VPN 或防火牆之後；給客戶的建議則包括保持與內部網路隔離（air-gapped）的最新備份、暫時改回依原廠指引的手動修補流程，以及對關鍵資源的管理帳號落實 MFA 與最小權限[4]。
3CX（2023）
3CX 官方發行的桌面語音與視訊通訊軟體被植入惡意程式，散布到使用者端。Mandiant 調查發現，最初的入口是一個被竄改的 X_TRADER 交易軟體安裝程式：這套軟體據報已在 2020 年停止服務，但 2022 年仍可從原廠網站下載；攻擊者藉此進入 3CX 內部後橫向移動，最終入侵了 Windows 與 macOS 的建置環境[5]。Mandiant 表示，這是他們第一次看到一起軟體供應鏈攻擊導致另一起軟體供應鏈攻擊，並將活動歸於疑似與北韓有關的 UNC4736[5]。
xz-utils（2024）
2024 年 3 月 29 日，工程師 Andres Freund 在 oss-security 郵件論壇揭露，Linux 常用壓縮工具 xz 的上游 5.6.0 與 5.6.1 版本被植入後門，可能導致 SSH 伺服器遭入侵；他是在 Debian 不穩定版（sid）上注意到 SSH 登入異常耗用 CPU 等現象，才循線發現。當時這兩個版本多半只進入各發行版的預先發行版本，尚未大量部署[6]。CISA 事後的分析指出，這是惡意行為者花了數年時間取得套件維護者信任、再植入後門的行動，也凸顯安全責任不該落在單一開源維護者身上[7]。
這四個案例的共同點是：受害者並沒有做錯什麼「明顯的事」，他們只是照常更新、照常使用服務商。防禦的重點因此不是「不信任任何廠商」，而是在信任之外加上驗證、限制與監控。
廠商風險管理：從採購與合約開始
NIST SP 800-161 Rev. 1 是網路安全供應鏈風險管理（C-SCRM）的主要參考文件，主張把供應鏈風險納入組織各層級的風險管理，而不是只在採購當下檢查一次[8]。多數台灣企業可以先從以下幾件事做起：
- 依存取程度分級：能遠端登入你環境、持有你資料或提供核心軟體的廠商列為高風險，納入定期檢視
- 合約寫清楚：資安事件的通知時限與方式、雙方責任分工、是否允許轉包（複委託）、稽核權，以及合約結束時的帳號停用與資料返還。五國聯合公告也建議在合約中要求 MSP 落實基本安全措施、提供安全事件監控，並約定事件通知方式[2]
- 要求證明而不只是承諾：例如第三方驗證、弱點修補流程、產品資安事件回應（PSIRT）窗口
台灣的《資通安全管理法》於 2025 年修正後，第 10 條規定公務機關與特定非公務機關委外辦理資通系統建置、維運或資通服務時，應選任適當的受託者，要求並監督其資通安全管理機制；受託者的相關程序與環境應具備完善的資安管理措施或通過公正第三方驗證，雙方並應簽訂書面契約，載明權利義務與違約責任[9]。即使你的公司不在資安法適用範圍內，這些要求也是很實用的基準；適用對象與義務請見台灣資通安全管理法。
SBOM：先知道自己用了什麼
軟體物料清單（SBOM）是 CISA 所說的「巢狀清單」，也就是組成軟體的元件成分表[10]。像 xz-utils 這類事件揭露時，第一個要回答的問題是「我們有沒有用到受影響的版本、裝在哪些系統上」。有 SBOM 與完整的軟體資產清冊，就能直接比對；沒有的話，只能逐台登入檢查。
實務做法：
- 採購時要求廠商提供 SBOM，或至少承諾在重大漏洞公布時能說明產品是否受影響
- 自行開發的系統在建置流程中自動產生 SBOM，並跟著版本一起保存
- 把 SBOM 與資產清冊連起來，當資安通報出現新的漏洞時能快速比對
限制廠商存取，並監控更新管道
- 最小權限：MSP 帳號不要加入內部管理員群組，只限於其負責管理的系統[2]，不使用時停用
- MFA 與連線限制：所有廠商帳號強制 MFA；遠端管理工具只允許來自已知 IP 的通訊，管理介面放在 VPN 或防火牆後面[4]
- 分批更新：重要軟體的更新先在測試環境或一小群主機上線，觀察後再全面部署。這不是拒絕更新，修補仍要在合理時間內完成（參考修補優先順序）
- 監控高權限軟體的網路行為：監控、備份、遠端管理這類高權限軟體，只允許連往必要的外部目的地，出現新的對外連線就要調查；SolarWinds 後門正是靠對外連線與攻擊者通訊[3]
- 留存廠商活動紀錄：要求服務商讓你看得到他們在你環境中的操作，並把關鍵日誌集中保存[2]
- 事件發生時能快速比對：廠商公布入侵指標時，要能迅速在自己的環境中搜尋，做法可參考如何運用入侵指標
行動清單
- 列出所有能遠端連入公司環境的廠商與 MSP，包含使用的工具、帳號、權限範圍與內部負責人。
- 檢查廠商帳號是否在網域管理員或其他高權限群組中；改為只限其管理系統的專用帳號，並啟用 MFA。
- 停用合約已結束或長期未使用的廠商帳號與遠端管理工具。
- 為高風險廠商補上合約條款：事件通知時限、轉包限制、操作紀錄提供，以及合約結束時的資料與帳號處理。
- 建立或更新軟體資產清冊，並開始為核心系統與自行開發的程式產生 SBOM。
- 限制監控、備份、遠端管理伺服器的對外連線，只允許必要目的地。
- 重要軟體改為分批更新，並追蹤廠商安全公告與本站的供應鏈攻擊分類。
- 安排一次桌上演練：假設某個核心廠商被入侵，確認你能在多久內找出受影響系統、停用廠商存取，並通知相關單位。