供應鏈攻擊：9 個範例與防禦

Title tag: 供應鏈攻擊案例：完全指南 (2013–2024) 中繼說明: 了解什麼是供應鏈攻擊，並探索從 SolarWinds 到 XZ Utils 的 9 個重大案例，包含攻擊機制、財務影響數據和防禦策略。

什麼是供應衝擊，以及它對資訊安全代表什麼意義

有史以來損失最慘重的網路攻擊並非始於駭客入侵政府網路，而是始於一次軟體更新。烏克蘭成千上萬家企業使用的一款會計程式悄悄地傳送了惡意代碼，並在數小時內蔓延到全球企業網路，最終估計造成了 100 億美元的損失。該攻擊名為 NotPetya，是本指南全面涵蓋的九個重大供應鏈攻擊案例之一，指南中詳細列出了每個案例的攻擊者、機制以及記錄在案的財務影響。

了解這些事件，源自經濟學的一個概念：供應衝擊。供應衝擊是一種突然、出乎意料的產品或服務供應中斷，這種中斷會向外擴散，影響到所有依賴它的對象。經典的例子包括石油禁運和自然災害。這些事件源於供應鏈中的單一節點，但卻會將損害層層傳遞給成千上萬的下游消費者，而這些消費者在最初的中斷事件中並未扮演任何角色。

資安供應鏈攻擊是一種數位供應鏈衝擊的運作方式。攻擊者在「上游」攻陷了一個受信任的軟體供應商或硬體元件，損害便會自動傳播到每一個安裝了該軟體、信任該供應商或依賴該元件的組織。受害者並未做錯任何事。他們的自身防禦被完全繞過。攻擊利用的是供應鏈，而非目標。就像石油禁運會重創從未接觸過煉油廠的產業一樣，一個被攻陷的軟體更新也會摧毀那些從未與攻擊者互動過的組織。

這份指南提供了完整概覽：何謂供應鏈攻擊、其運作機制、從 2013 年至 2024 年間所有重大的知名事件（附量化影響數據）、攻擊者是誰及其動機，以及組織與開發者如何降低曝險。

什麼是供應鏈攻擊？

供應鏈攻擊是一種網路攻擊，它透過鎖定組織供應鏈中受信任的第三方供應商、軟體元件或硬體要素，來間接損害該組織。攻擊者在上游將惡意程式碼或後門植入合法的軟體或硬體中，如此一來，受害者會在不知情的情況下透過例行的更新或採購流程自行引入威脅。由於攻擊來自受信任的來源，受害者的自身安全控制措施會被繞過。

軟體供應鏈涵蓋了建置與交付軟體產品所涉及的每個元件、函式庫與流程。這包括第三方程式碼依賴項、開源函式庫、建置基礎設施、更新伺服器以及硬體韌體。這些元素中的任何一個都可以作為進入點。

供應鏈攻擊與直接網路攻擊的關鍵區別在於攻擊點。在直接攻擊中，攻擊者會針對受害者自身的系統、應用程式或使用者，並必須克服該組織的安全控制。而在供應鏈攻擊中，攻擊者則會針對受害者已信任的供應商，完全繞過這些控制。一個受損的供應商可以同時暴露數千個下游組織。

資料外洩是一種結果，而非攻擊手段。供應鏈攻擊可能導致資料外洩，但並非所有的資料外洩都涉及供應鏈入侵。同樣地，並非所有供應鏈攻擊都會導致資料竊取：NotPetya 造成的是破壞而非資料外傳。

供應鏈攻擊如何運作

供應鏈攻擊遵循一個一致的模式：攻擊者會攻陷一個可信賴的供應商，而非直接針對受害者組織。攻擊會透過軟體分發、更新或硬體採購的正常管道來傳遞。

攻擊生命週期：步驟解析

1. 攻擊者識別出目標所使用的受信任供應商或軟體組件
2. 攻擊者取得供應商的建置系統、程式碼儲存庫或更新伺服器的存取權限
3. 在分發前將惡意程式碼植入合法的軟體或硬體中
4. 供應商透過其正常的受信任管道分發受損產品
5. 目標組織安裝更新或部署組件，從而引入威脅
6. 攻擊者利用已建立的立足點進行橫向移動、間諜活動或投放破壞性酬載

攻擊向量分類

遭篡改的軟體更新

被植入木馬的更新特別危險，因為它幾乎能突破所有標準安全控制措施。更新來自組織已信任的供應商，帶有合法的數位程式碼簽署憑證，通過了防毒軟體和端點安全掃描，且使用者在例行維護中自願安裝。目標組織中沒有人做錯任何事。

建立系統滲透（Build system compromise）針對的是將原始碼轉換為可執行軟體的自動化編譯流程。攻擊者會取得供應商的建置環境存取權，並在編譯期間植入惡意程式碼。由此產生的軟體套件外觀與合法版本完全相同。在此階段遭到入侵的 CI/CD（持續整合／持續部署）管線，會將惡意程式碼散播到之後的每一次軟體發布中，即使原始碼本身是乾淨的。這就是為何即使對原始碼儲存庫進行徹底的程式碼審計，也無法揭露此攻擊的原因。

可以這樣想：想像一下，一家藥品供應商在出貨前，悄悄地將一種合法藥品換成了受污染的版本。收到並使用這種藥品的醫院並無任何過失。這次攻擊利用的是供應鏈，而不是醫院本身。

SolarWinds、CCleaner 和 ASUS ShadowHammer 均遵循此模式。在每個案例中，攻擊者都是入侵供應商的建置基礎設施，而非直接攻擊目標組織。

開源套件庫 (Package Registry) 攻擊

公開的套件註冊中心是軟體供應鏈中最活躍的攻擊面之一。這包括 JavaScript 的 npm、Python 的 PyPI、Ruby 的 RubyGems、.NET 的 NuGet，以及 Java 的 Maven。僅 npm 註冊中心就託管了超過兩百萬個套件。單一受損的熱門套件可能會將惡意程式碼傳播到數百萬個應用程式中。

這個生態系統面臨三種不同的攻擊模式。在拼寫誤導攻擊 (typosquatting) 中，攻擊者會註冊一個名稱與熱門合法套件極為相似的套件（例如，lodahs 而非 lodash），企圖誘騙粗心的開發者。在依賴項混淆 (dependency confusion) 中，攻擊者會利用與目標組織的私有內部套件完全相同的名稱，將其發佈到公開的註冊表中。如果建置系統在檢查私有註冊表之前先檢查公開註冊表，就會自動下載惡意版本。在惡意套件注入 (malicious package injection) 中，一個合法的套件在發佈後遭到破壞，可能是透過竊取維護者的憑證或透過社群工程手法來達成。

依賴性混淆（Dependency confusion）技術最早在 2021 年由安全研究員 Alex Birsan 大規模公開展示，他利用此技術成功地在 Apple、Microsoft、PayPal 及其他 35 家大型公司的建置管線中獲得了程式碼執行權限。此攻擊之所以奏效，並非因為存在漏洞，而是源於套件管理員處理公開與私人註冊庫之間命名衝突的方式。

關於 Log4Shell：Log4Shell (CVE-2021-44228)，這個於 2021 年 12 月在 Apache Log4j Java 記錄庫中發現的重大漏洞，經常被描述為一種供應鏈攻擊。事實並非如此。Log4Shell 是一個非故意的軟體漏洞。沒有攻擊者將其插入 Log4j 的程式碼庫中。混淆之處在於 Log4j 作為依賴項出現在數千種軟體產品中，使得識別所有受影響的系統類似於供應鏈審計問題。威脅模型不同：供應鏈攻擊涉及攻擊者故意插入惡意程式碼，而 Log4Shell 是一個偶然的缺陷，後來被攻擊者利用。

MSP 損害與橫向移動

受託管理服務供應商 (MSP) 是一家遠端管理客戶組織的 IT 基礎架構、安全性與系統的公司。中小型企業因缺乏內部 IT 團隊，常使用 MSP。攻陷 MSP 能讓攻擊者同時獲得對該 MSP 所有客戶的系統管理員權限，使 MSP 成為具有不成比例下游影響範圍的「力量倍增器」式攻擊媒介。CISA 諮詢公告 AA22-131A) 曾特別警告 MSP，他們是高優先級的目標。

一旦透過受惡意程式碼感染的更新或受損的依賴項進入任何網路後，攻擊者通常會使用橫向移動（lateral movement）技術。這些技術利用合法的憑證和網路存取路徑，從最初受侵害的系統轉向更敏感的目標。在 SolarWinds 攻擊事件中，APT29 使用 SUNBURST 後門作為最初的據點，隨後橫向移動到各個政府機構的電子郵件系統和敏感資料儲存庫。

重大的供應鏈攻擊範例

以下表格總結了 2013 年至 2024 年間最顯著的供應鏈攻擊案例，並依據攻擊者、攻擊媒介以及已記錄的影響進行組織。

Target 資料外洩（2013 年）

Target (2013) — 一個犯罪集團透過先入侵 Fazio Mechanical Services 獲取了對 Target 銷售點網絡的訪問權限。Fazio Mechanical Services 是一家第三方空調與製冷承包商，持有遠端訪問 Target 系統的網絡憑證。

Target 洩漏事件是供應鏈攻擊模式中最早被廣泛研究的範例。攻擊者並未直接突破 Target 的周邊防禦。他們從一家小型空調 (HVAC) 供應商處獲取憑證，並利用這些憑證透過合法的存取路徑進入 Target 的網路，接著橫向移動到處理支付卡資料的 POS 系統。

結果導致約 4000 萬名客戶的付款卡數據以及約 1.1 億人的個人資料被盜。Target 因該次洩漏而產生的總成本估計超過 2 億美元，包括和解金、法律費用和補救措施。這次攻擊建立了一個範本，供後續攻擊進行改良：滲透一個擁有進入真實目標權限的受信任供應商，然後利用該權限作為切入點。美國特勤局和司法部的調查證實，第三方供應商路徑是其入侵途徑。

SolarWinds 供應鏈攻擊 (2020)

SolarWinds (2020) — APT29 (Cozy Bear)，據信歸屬於俄羅斯對外情報局 (SVR)，滲透了 Orion IT 監控平台的建置程序，並在例行軟體更新中植入了 SUNBURST 後門，約有 18,000 名 SolarWinds 客戶下載了該更新。

SolarWinds 被廣泛認為是史上最重大的供應鏈網路攻擊事件。Orion 是一個被廣泛部署的 IT 監控平台，曾被美國政府機構和大型企業廣泛使用。攻擊者將 SUNBURST 後門植入軟體建置管線中，這意味著惡意程式碼直接被編譯到合法的 Orion 更新套件內，並使用有效的 SolarWinds 憑證進行簽名，再透過官方更新管道進行分發。

在下載了含有木馬更新的約 18,000 個組織中，攻擊者選擇了高價值目標進行二次利用。其中包括美國財政部、商務部、國土安全部和國務院，以及微軟 (Microsoft)、FireEye 和其他主要科技公司。這次入侵在被發現前大約潛伏了九個月，直到 FireEye 在調查其自身系統的異常時才發現了它。

APT29 利用 SUNBURST 立足點作為初始存取點，隨後在受侵害的網路中進行橫向移動，以進入電子郵件系統與敏感通訊。該行動被評估為間諜活動，而非破壞性攻擊。美國政府的應對措施由 CISA 公告 AA20-352A,) 進行協調，其中包括影響所有聯邦文職機構的緊急指令。

NotPetya (2017)

NotPetya (2017) — Sandworm（被歸因於俄羅斯軍事情報局 GRU，即 74455 部隊）將惡意程式碼植入 M.E.Doc 的軟體更新中，這是一款被大量在烏克蘭經營的企業所採用的烏克蘭會計應用程式。

NotPetya 並非勒索軟體。雖然它顯示了勒索訊息，但那只是個煙幕彈。其程式碼覆寫了受感染系統的主開機紀錄 (MBR)，導致系統永久無法復原。這是一種旨在造成最大損害的破壞性抹除程式 (wiper)，完全沒有實際的付款機制。其類似勒索軟體的外觀是為了在初始應變期間掩蓋攻擊來源。

最初的感染途徑是 M.E.Doc 更新，但 NotPetya 透過 EternalBlue 漏洞利用和網路傳播在烏克蘭境外迅速擴散，在數小時內演變成全球性的災難。全球總損失估計約為 100 億美元，就財務影響而言，這是歷史上最具破壞性的網路攻擊。知名的受害者包括航運巨頭馬士基（Maersk，損失約 3 億美元；該公司必須從頭重新安裝 45,000 台電腦和 4,000 台伺服器）、製藥商默克（Merck）、FedEx/TNT Express 以及蒙德里安國際（Mondelez International）。這些機構中有許多與烏克蘭沒有直接聯繫，是透過全球網路連線而受害的附帶受害者。

這次攻擊在 Wired 的回顧性調查) 中有詳盡的記錄，美國、英國及澳洲均將其歸咎於 Sandworm。Sandworm 與 APT29/Cozy Bear 不同：他們隸屬於不同的俄羅斯情報機構（分別為 GRU 與 SVR），且擁有不同的行動職責。

Kaseya VSA 攻擊 (2021)

Kaseya VSA (2021) — REvil 是一個與國家無關的網路犯罪勒索軟體即服務 (RaaS) 組織，該組織利用 Kaseya VSA 中的零日漏洞，同時向託管服務提供商 (MSP) 客戶推送惡意更新。

Kaseya VSA 是一款被託管服務供應商（MSP）廣泛使用的遠端監控與管理平台。以經濟利益為動機的犯罪集團 REvil 識別出 MSP 的攻擊面，並對其進行了大規模利用。藉由入侵 VSA 平台，REvil 能夠向所有下游客戶組織同時推送惡意更新，且這些更新看似源自於受信任的 MSP。

結果：大約 60 家 MSP 遭到入侵，並透過這些服務提供者，大約 1,500 家下游企業遭受勒索軟體攻擊（這是一種會加密受害者數據並要求支付解密金鑰費用的惡意軟體）。REvil 要求支付價值 7,000 萬美元的比特幣以換取通用解密工具。這次攻擊特別清晰地展示了針對 MSP 攻擊的效應倍增邏輯：一個被入侵的平台在單次行動中影響了數百個組織。CISA 顧問公告 AA21-200B) 提供了完整的技術分析。

Codecov 供應鏈攻擊 (2021)

Codecov (2021) — 一名身分不明的攻擊者竄改了 Codecov Bash Uploader 腳本，這是一個嵌入在數千家組織 CI/CD 流水線中的程式碼覆蓋率報告工具，攻擊者並利用其竊取了包括憑證與 API 代碼在內的環境變數。

Codecov 是一款程式碼覆蓋率分析服務，軟體開發團隊使用它來追蹤測試覆蓋率。攻擊者修改了 Bash Uploader 腳本，各組織會下載此腳本並將其作為自動化建置流程的一部分執行。由於該腳本在 CI/CD 環境中運行，因此可以直接存取包含憑據、權證和儲存庫存取金鑰的環境變數。

這次入侵在約兩個月內未被察覺，直到 Codecov 於 2021 年 4 月發現為止。受影響的組織包括 Twilio、HashiCorp 和 Confluent，這些組織披露了其憑證已遭洩露。此次攻擊展示了一種特定於 CI/CD 的供應鏈攻擊向量：攻擊者並非入侵最終的軟體產品，而是針對組織用於建置與測試軟體的工具。此攻擊處於建置流水線（build pipeline）入侵與憑證竊取的交界處，代表了與 SolarWinds 和 CCleaner 中所使用的更新分發向量截然不同的模式。

CCleaner 供應鏈攻擊 (2017)

AXIOM 群組（一項被指稱與中國國家支持的駭客攻擊有關的行動）滲透了 CCleaner 開發商 Piriform 的建置環境，並在透過官方管道散發的正版 CCleaner 安裝程式中植入了 Floxif 惡意軟體。

CCleaner 是一款受歡迎的電腦優化工具，擁有數百萬名個人與企業用戶。此次攻擊顯示，供應鏈攻擊並不侷限於企業軟體。在發現受駭之前，約有 227 萬名用戶下載了被植入木馬的版本。

這次攻擊包含第二階段：預先配置的定向惡意載荷（payload）僅會在屬於約 40 家高科技公司的系統上啟動，包括 Cisco、Intel、Samsung 和 Sony。對於絕大多數受影響的使用者而言，該惡意軟體僅是被動地收集數據。對於被鎖定的科技公司，這代表對其敏感網路的嚴重入侵。Cisco Talos 對 CCleaner 命令與控制基礎設施的分析 提供了針對此次攻擊的首次完整技術剖析。

ASUS ShadowHammer (2019)

ASUS ShadowHammer（2019）— BARIUM 集團，據指稱與中國國家支持的駭客攻擊有關，入侵了華碩的 Live Update 工具程式，並透過官方華碩更新伺服器散布了一個使用合法華碩數位憑證簽署、帶有後門的版本。

這次攻擊顯示出一個重大的涵義，即對於數位信任而言：如果簽署基礎設施本身遭到破壞，則合法的程式碼簽署憑證不能再被信賴，無法作為軟體完整性的證明。這個被木馬程式感染的 ASUS 更新攜帶了有效的 ASUS 憑證，並透過官方的 ASUS 更新機制發布，通過了所有標準身份認證檢查。約有 50 萬 ASUS 用戶收到了帶有後門的更新。

攻擊者並未對所有 500,000 名用戶感興趣。惡意酬載被預先配置，僅在擁有約 600 個特定 MAC 位址的系統上啟動，這表明攻擊者事先掌握了關於特定目標的情報。該活動於 2019 年由 Kaspersky 研究團隊 (Securelist)) 發現並記錄。

硬體與韌體供應鏈攻擊特別令人擔憂：在韌體層級所做的修改，在作業系統重新安裝後依然存在，並且對基於軟體的安全工具不可見。

3CX 供應鏈攻擊 (2023)

3CX (2023) — Lazarus Group，被歸因於北韓偵察總局 (RGB)，執行了首次公開確認的「供應鏈對供應鏈」攻擊，透過先前 Trading Technologies 軟體的供應鏈入侵，滲透進 3CX 的構建環境。

一名 3CX 員工的個人電腦因安裝了遭植入特洛伊木馬的 Trading Technologies X_TRADER（一個金融交易平台）安裝程式而遭到入侵。該 Trading Technologies 安裝程式本身在早先的一項行動中已遭 Lazarus Group 進行供應鏈攻擊。受害員工的電腦讓攻擊者得以存取 3CX 的構建環境，攻擊者隨後利用該環境將惡意軟體植入 3CX Desktop App；這是一個在全球擁有超過 60 萬家企業和 1200 萬名每日活躍使用者的 VoIP 通訊平台。

這次攻擊不成比例地針對金融產業公司。由於 3CX 被入侵本身是先前供應鏈攻擊的後續影響，這是首例經證實由供應鏈攻擊引發第二次供應鏈攻擊的案例。實際的影響在於：組織現在不僅需要考慮其直接供應商是否安全，還需要考慮其供應商的供應商是否已被入侵。完整的技術分析記錄在 Mandiant 的事件分析.

XZ Utils 後門 (2024)

XZ Utils (2024) — 在資安研究人員根據行為指標評估，認為這是一場國家級行動、但尚未有確切公開歸屬證實的情況下，一個未知行為者假冒「賈譚」(Jia Tan) 的身分，花費了約兩年的時間滲透 XZ Utils 開源專案，然後植入了針對 Linux 系統 SSH 驗證的後門。

XZ Utils 是一個資料壓縮函式庫，它在數百萬台 Linux 伺服器上作為隱藏式基礎架構運作。它並非面向使用者的應用程式，而是其他軟體靜默依賴的那種基礎軟體。一名以「Jia Tan」名義活動的攻擊者，於 2022 年開始向 XZ Utils 專案貢獻合法、高品質的程式碼，藉由長期參與專案維護者，逐步建立信譽並最終獲得了提交（commit）權限。

2024 年初，「Jia Tan」在 XZ Utils 5.6.0 和 5.6.1 版本中植入了後門。該後門旨在破壞受影響 Linux 發行版上的 SSH 身份驗證，可能讓攻擊者獲得任何運行該受影響函式庫版本的伺服器的遠端存取權限。SSH 是全球 Linux 伺服器的主要遠端管理協定，這使得潛在的影響範圍非常廣泛。

該後門程式在大範圍部署前，被微軟工程師 Andres Freund 發現。他在例行工作中注意到異常的 CPU 消耗和 SSH 效能下降，並追蹤到了來源。他在 2024 年 3 月發布的發現，阻止了一場可能影響數百萬台伺服器的供應鏈入侵事件。OpenSSF 公告) (CVE-2024-3094) 提供了完整的技術說明。

為什麼供應鏈攻擊如此危險

供應鏈攻擊之所以難以偵測與防範，是因為這類攻擊是利用組織對其軟體供應商的信任，而非針對組織自身系統的漏洞。有四個因素加劇了偵測上的挑戰。

惡意軟體來自一個可信來源：一個目標組織已授權其憑證、網域和更新基礎架構的供應商。被植入木馬的更新通常攜帶發行給合法供應商的有效數位程式碼簽署憑證，因此憑證驗證能順利通過。防毒軟體和端點偵測工具可能不會標記由可信供應商簽署並透過官方管道傳送的軟體。複雜的攻擊者還會故意延遲初始存取後的活躍操作，以避免觸發異常偵測。APT29 在 SolarWinds 被入侵的網路中活動了約九個月才被偵測到，此潛伏時間說明了從入侵到發現之間的差距可能有多長。

在過去十年中，供應鏈攻擊的頻率和複雜程度均有所增加。歐盟網路安全局 (ENISA) 的《威脅情勢報告》記錄了持續上升的趨勢，供應鏈攻擊被列為關鍵基礎設施領域的首要威脅類別。這種情勢的升級從歷史記錄中可見一斑：2017 年 CCleaner 遭入侵影響了 227 萬名消費者用戶；2020 年 SolarWinds 行動入侵了超過 100 個美國政府機構；2024 年 XZ Utils 的險遭入侵事件則針對全球數百萬台伺服器使用的核心 Linux 基礎設施。攻擊者的野心隨著每一次週期而大幅增長。

財務影響規模相當。NotPetya 造成了約 100 億美元的全球損失，而馬士基（Maersk）一家就報告了約 3 億美元的損失。Kaseya 攻擊事件產生了 7000 萬美元的勒索要求，影響了 1,500 家企業。美國政府對 SolarWinds 事件的回應，花費了數億美元用於補救和加強安全投資。政府和公共部門組織（SolarWinds）、金融服務公司（3CX）、科技公司（CCleaner 第二階段目標）以及 CISA 指定優先級領域的關鍵基礎設施營運商都成為了攻擊目標。沒有任何依賴第三方軟體或託管服務的行業可以置身事外。

--- ## 誰發動供應鏈攻擊

供應鏈攻擊是由兩類截然不同的威脅行為者發動：國家級的進階持續威脅（APT）組織，以及以經濟利益為動機的犯罪組織。

進階持續性威脅 (APT) 指的是一種精密且資源充足的威脅行為者，通常是國家級情報機構或軍事網路單位，其會進行長期、鎖定目標的入侵活動，並具有特定的戰略目標。APT 偏好供應鏈攻擊，因為單一的上游端點被入侵可同時存取數百或數千個高價值目標，進而最大化單一行動的情報產出，同時最小化被偵測的風險。APT 活動的歸因是機率性的，基於鑑識指標，包括程式碼重疊、基礎設施模式和操作時序，而非直接證據。

已知發生的供應鏈攻擊事件中，被歸因於國家級駭客組織的包括：APT29（Cozy Bear），被指認為俄羅斯對外情報局（SVR）所為，該組織發動了SolarWinds攻擊事件；Sandworm（沙蟲），被指認為俄羅斯聯邦軍事情報總局（GRU）所為，該組織透過M.E.Doc發動了NotPetya攻擊；Lazarus集團，被指認為北韓偵察總局（RGB）所為，該組織發動了3CX攻擊事件；BARIUM集團，被指認為中國國家級駭客組織營運，該組織發動了ASUS ShadowHammer攻擊事件；以及AXIOM集團，同樣被指認為中國國家級駭客組織營運，該組織發動了CCleaner攻擊事件。儘管BARIUM和AXIOM兩者都被歸因於中國，但它們是獨立的組織。

並非所有供應鏈攻擊皆為國家級行動。Kaseya VSA 攻擊是由 REvil 所發動，這是一個不具國家背景、以俄語為主的網路犯罪勒索軟體即服務 (RaaS) 組織。受經濟利益驅使的犯罪集團已開始採用供應鏈技術，因為僅需攻破一家受管理服務供應商 (MSP)，便能在單次行動中向數百家客戶組織傳播勒索軟體，相較於針對單一受害者，這大幅提升了獲利回報。

--- ## 如何防禦供應鏈攻擊

防禦供應鏈攻擊需要將您的安全計畫延伸至您自身的系統之外，涵蓋您的組織所依賴的供應商、軟體元件及基礎設施。目標並非建立一個完美的邊界，而是要在信任的供應商遭到入侵時，降低其影響範圍。

企業與組織防禦檢查表

• 為貴組織採購或構建的所有軟體實施軟體物料清單 (SBOM) 政策，以便在供應鏈遭到入侵的消息披露時，能夠識別受影響的組件
• 稽核第三方供應商的安全實務，在採購前及每年定期使用符合 NIST SP 800-161r1 標準的問卷進行評估
• 要求供應商提供最新的 SBOM，作為採購和合約流程的一部分，適用於所有進入您環境的軟體產品
• 應用零信任架構原則：對所有軟體和服務執行最小權限存取控管，實施網路微隔離以遏制橫向移動，並持續驗證而非信任網路位置
• 監控受信任供應商軟體的異常行為，因為即使簽章有效，與已知基準的行為偏離也可能預示更新已遭到破壞
• 審查供應商安全認證 (SOC 2 Type II、ISO 27001)，並在供應商合約中納入明確的安全要求和違規通知義務
• 遵循 CISA 的供應鏈安全指引)**，並實施 NIST SP 800-161r1 (C-SCRM) 框架，將您的風險管理延伸至第三方供應商
• 維護事件應變計畫，明確涵蓋第三方軟體遭入侵的情境，包括在整個環境中緊急隔離受影響軟體的程序

什麼是軟體物料清單 (SBOM)？

軟體物料清單 (SBOM) 是一份機器可讀的清單，包含軟體產品中所有的組件、函式庫和依賴項。其功能類比為軟體的營養標籤：營養標籤列出成分和數量，而 SBOM 則列出構建應用程式時所使用的每一個開源函式庫、第三方組件和直接依賴項，以及版本號和授權資訊。

SBOM 對於供應鏈安全至關重要，因為它能回答組織在資安事件發生時難以回答的問題：「我們是否受影響？」SolarWinds 事件被揭露時，沒有軟體資產清單的組織必須手動稽核每個系統，以確定他們是否運行 Orion。擁有最新 SBOM 的組織則能直接查詢其資產。XZ Utils 差點出事的事件也適用相同的邏輯：知道哪些伺服器運行哪個版本的函式庫，決定了回應時間是數小時還是數週的不確定性。

行政命令 14028：改善國家網路安全 (於 2021 年 5 月簽署，以直接應對 SolarWinds 攻擊) 規定向美國聯邦政府銷售軟體的軟體供應商必須提供 SBOM。 CISA 已發布 SBOM 實施指南，適用於生產者和消費者。SPDX、CycloneDX 和 Syft 等工具可以從大多數程式碼庫和容器映像檔自動生成 SBOM。

零信任架構與供應鏈防禦

零信任架構透過將「永不信任，始終驗證」的原則應用於每一個存取請求，包含來自看似源自受信任供應商軟體的請求，來減少供應鏈攻擊所能造成的損害。供應鏈攻擊能取得成功，主要就是利用了隱性信任。零信任則從這個環節中移除了那種隱性信任。

最直接與供應鏈防禦相關的三項控制措施是：最小權限存取（限制任何受損軟體在您的網路內可存取的範圍，以免帶有後門的更新存取其合法範圍以外的系統）；網路微隔離（限制橫向移動，使攻擊者在獲得初始立足點後無法自由傳播）；以及持續的行為監控（偵測受信任軟體中的異常活動，即使初始入侵繞過了基於簽名的偵測）。

零信任是一種安全理念和架構模型，而不是可以購買的軟體產品。主要的權威參考資料包括 CISA 零信任成熟度模型) 和 NIST SP 800-207.)

開發者與 DevOps 防禦清單

開發人員和 DevOps 工程師直接掌控著開源供應鏈攻擊中最常被鎖定的攻擊面。這些行動能降低您的 CI/CD 管道的曝險程度：

["釘選並鎖定所有套件資訊清單（package-lock.json、requirements.txt、Gemfile.lock）中的依賴項版本，以便新發布的惡意版本在下次建置時不會被自動拉取。","設定您的建置系統，使其優先使用私有登錄檔而非公開登錄檔，並在公開登錄檔上保留所有內部套件命名空間，以防止依賴項混淆攻擊。","在每次建置時執行自動化依賴項掃描，使用 Dependabot、OWASP Dependency-Check 或 Snyk 等工具，在已知存在漏洞或可疑的套件進入生產環境之前將其標記出來。","使用 CycloneDX 或 Syft 為每次發布產生 SBOM，並將其與您的建置成品一起儲存，以便您擁有已部署之每個版本的可稽核元件清單。","要求簽署提交（signed commits），並在您的主要建置管線中強制執行分支保護規則，以防止未經授權的程式碼進入建置流程。","在加入第三方套件前進行審核：檢查維護者的發布歷史、下載次數、儲存庫活動，以及套件是否最近轉移給了新擁有者。"]

供應鏈安全：法規與合規要求

現在，多個主要的監管框架已明確要求組織將解決供應鏈安全風險納入其網路安全義務的一部分。這些要求從指引轉變為強制性規定，主要歸因於 SolarWinds 攻擊事件。

美國監管框架

在美國，主要的監管觸發因素是拜登總統於 2021 年 5 月 12 日簽署的《第 14028 號行政命令：改善國家網路安全》，這是針對 SolarWinds 攻擊和 Kaseya VSA 事件的直接回應。第 14028 號行政命令規定，向美國聯邦政府銷售產品的軟體供應商必須為其產品提供軟體物料清單 (SBOM)。該命令指示 NIST 制定供應鏈安全指南，並由 CISA 實施 SBOM 標準。這項指令適用於向聯邦政府供貨的供應商。它並未直接要求所有私營部門組織提供 SBOM，但其產生的標準已在企業環境中被廣泛採納為採購要求。

主要的技術標準參考為 NIST SP 800-161r1（《系統與組織的網路安全供應鏈風險管理實務》），該標準擴展了標準的網路安全風險管理框架，以明確涵蓋第三方供應商、廠商和軟體組件。根據 NIST SP 800-161r1，C-SCRM（網路供應鏈風險管理）要求組織進行廠商風險評估、驗證軟體來源、在採購中強制要求 SBOM（軟體物料清單），並維持納入第三方遭入侵情況的事件響應計畫。CISA 的出版物《防禦軟體供應鏈攻擊》提供了符合第 14028 號行政命令（EO 14028）要求的可操作執行指南。

歐盟監管框架

歐洲組織在兩個框架下必須滿足平行要求。NIS2 指令（網路與資訊安全指令 2）要求關鍵領域（包括能源、運輸、健康和數位基礎設施）的組織，在其強制性網路安全風險管理義務中，納入對供應鏈安全風險的處理。DORA（數位營運韌性法案）適用於歐盟的金融業實體，並包含管理資通訊科技（ICT）第三方服務供應商風險的詳細要求，直接針對供應鏈攻擊向量。ENISA（歐洲聯盟網路安全局）是歐盟組織的主要權威來源，其角色相當於美國的 CISA。

法規參考摘要

關於供應鏈攻擊的常見問題

什麼是供應鏈攻擊？

供應鏈攻擊透過損害受信任的第三方供應商、軟體元件或硬體元件，來間接針對某組織。攻擊者在上游植入惡意程式碼，使受害者在不知情的情況下，透過例行軟體更新或硬體採購引入該威脅。無需受害者自身系統存在任何弱點。此類攻擊得以成功，是因為它透過了受害者早已授權的管道。

供應鏈攻擊有哪些範例？

2013 年至 2024 年間最嚴重的供應鏈攻擊案例：

• SolarWinds (2020)： SUNBURST 後門程式被植入 Orion 平台更新中；波及約 18,000 名客戶，包括 100 多個美國政府機構
• NotPetya (2017)： 透過 M.E.Doc 會計軟體更新傳播的破壞性資料清除程式 (wiper)；估計造成全球 100 億美元的損失
• Kaseya VSA (2021)： REvil 利用 VSA 零日漏洞，透過受入侵的託管服務供應商 (MSP) 向 1,500 多家企業發送勒索軟體
• XZ Utils (2024)： 一場為期兩年的社交工程攻擊，差點在全球 Linux 基礎設施中植入 SSH 後門
• CCleaner (2017)： Floxif 惡意軟體波及 227 萬名用戶；第二階段攻擊針對 40 家大型科技公司
• ASUS ShadowHammer (2019)： 帶有後門且使用有效華碩 (ASUS) 憑證簽署的韌體更新，波及 50 萬名用戶
• 3CX (2023)： 首例獲證實的「供應鏈對供應鏈」攻擊；透過 Lazarus Group 波及超過 60 萬家公司

供應鏈攻擊是如何運作的？

供應鏈攻擊遵循一個可重複的序列：

1. 攻擊者選擇目標所依賴的受信任供應商或軟體相依性
2. 攻擊者取得該供應商構建環境、程式碼儲存庫或更新基礎設施的存取權限
3. 在分發之前，惡意程式碼被植入到合法軟體中
4. 供應商透過其正常、受信任的管道發布受損產品
5. 目標安裝更新，將威脅帶入其自身的防禦邊界內
6. 攻擊者激活據點以進行間諜活動、數據竊取或破壞性載荷

什麼是最著名的供應鏈攻擊？

SolarWinds 攻擊（2020 年）被廣泛認為是歷史上最重大的供應鏈網路攻擊。被歸類為俄羅斯對外情報局 (SVR) 的 APT29，將 SUNBURST 後門植入 SolarWinds Orion 更新中，影響了約 18,000 名客戶，其中包括 100 多個美國政府機構。此次入侵在約九個月的時間內未被察覺，並直接促成了旨在提高國家網路安全的第 14028 號行政命令。

為什麼供應鏈攻擊如此危險？

供應鏈攻擊具有複合風險，原因有四點。惡意軟體來自組織已經信任的供應商，繞過周邊防禦，而無需利用目標自身系統中的任何漏洞。被植入木馬的更新帶有有效的數位簽章，可通過憑證檢查。防毒工具可能不會標記經簽署且由供應商交付的軟體。老練的攻擊者在初始存取後會保持休眠狀態，以避免觸發行為異常檢測。SolarWinds 行動持續了九個月未被發現。一個受侵害的供應商可以觸及成千上萬個下游組織，將單次入侵的影響力擴大到遠超典型直接攻擊所能達到的程度。

供應鏈攻擊是否正在增加？

在過去十年中，供應鏈攻擊的頻率和複雜性顯著增加。ENISA 的年度威脅態勢報告將供應鏈攻擊記錄為一類持續且不斷增長的威脅，攻擊量逐年上升。這一趨勢在事件本身中清晰可見：從 2013 年因一家小型 HVAC 承包商而導致的 Target 數據洩露，到 2020 年影響美國政府的 SolarWinds 間諜活動，再到 2024 年針對核心 Linux 基礎設施的 XZ Utils 差點洩漏事件。出於經濟動機的犯罪集團也採用了供應鏈手法，正如 Kaseya 攻擊所示：一個受感染的 MSP 平台在數小時內影響了數百家客戶組織。

組織如何防範供應鏈攻擊？

組織可以透過以下措施降低供應鏈攻擊的曝險：

• 實施軟體材料清單 (SBOM) 政策，以維持軟體元件的完整庫存，並在發生安全事件時識別受影響的系統
• 要求供應商提供 SBOM，並將最新的安全認證 (SOC 2, ISO 27001) 作為採購條件
• 應用零信任架構原則：最小權限存取、網路微分割和持續行為監控
• 監控來自信任供應商的軟體，偵測行為異常，而非僅依賴基於特徵碼的指標
• 遵循 CISA 的供應鏈安全指南，並將供應商風險評估流程與 NIST SP 800-161r1 (C-SCRM) 對齊
• 維持包含明確涵蓋第三方軟體安全漏洞的事件應變計畫

發布說明： (1) 在常見問題 (FAQ) 區塊實施 FAQPage 結構化資料綱要，並在整個頁面實施 Article 綱要，以最大化符合「用戶也問」(People Also Ask) 功能和豐富結果的資格。 (2) 本文中的外部引用連結至 CISA、NIST、Mandiant、Kaspersky/Securelist、Wired、OpenSSF 和 Cisco Talos 作為權威來源。 (3) 網站上相關網路安全內容的內部連結 (勒索軟體攻擊指南、零信任架構說明、SBOM 實施資源、供應商風險管理指南、APT 威脅行為者概述) 應由發布團隊在部署前添加。在撰寫本文時，網站索引不包含已編入索引的網路安全文章，因此內部連結的放置需要編輯團隊手動審核。