什麼是供應鏈風險管理 (SCRM)?

在當前的數位環境中，保護供應鏈與網路安全防禦密不可分。隨著組織越來越依賴外部供應商和第三方軟體來滿足需求，我們現在正面臨一整套發生在組織圍牆之外的全新風險。而這些供應鏈風險可能影響公司中的一切，從軟體設計到已部署的軟體產品。

在這篇部落格中，我們將了解供應鏈風險管理的概念及其在網路安全中的角色。我們也將討論如何識別常見風險、如何制定有效的評估方法，以及如何建立強健的安全策略。我們還會探討一些主要框架、特定產業的使用案例，以及組織可用來確保供應鏈安全的其他最佳實務。

什麼是供應鏈風險管理

供應鏈風險管理 (SCRM) 是一套行動與流程，使組織能夠識別、評估並將涉及其外部合作夥伴、供應商和服務提供者的風險降至最低。它涵蓋交付產品或服務的數位要素。

供應鏈風險管理會在各種元件進入組織環境之前掃描其弱點。它也會建立監控機制，以偵測之後可能出現的潛在問題。此方法旨在確保外部世界與內部系統之間每個接觸點的安全。

安全、IT、採購、法務和業務團隊都需要共同合作，SCRM 才能發揮成效。這種跨職能方法可確保涵蓋供應商關係的整體安全風險範圍，從選擇到合約管理以及定期安全審查。

為什麼供應鏈風險管理很重要？

在組織更加依賴外部供應商與第三方程式庫的時代，供應鏈風險管理已變得更加重要。如今，大多數公司都有數十個甚至數百個協助其營運業務的第三方。每一段關係都會帶來安全風險，並可能改變組織的安全態勢。

許多現代軟體應用程式由來自許多不同來源的元件組成。商業應用程式中的程式碼通常會包含數十個第三方程式庫與框架。如果這些元件中的任何一個存在安全弱點，整個應用程式都可能遭到入侵。相依性問題也同樣適用於雲端服務、受管服務提供者和硬體供應商。

常見的供應鏈風險類型

供應鏈風險可能以遭入侵的軟體、服務攻擊、內部人員或第三方存取的形式出現，而每一種都需要各自的偵測與防護方法。最常見的類型包括：

程式碼注入攻擊

程式碼注入攻擊是指攻擊者在開發或散佈期間，將惡意程式碼插入合法軟體中。這可能發生在攻擊者取得原始碼儲存庫、建置系統或更新伺服器的存取權時。著名案例之一是 SolarWinds 攻擊，其中後門程式碼被插入軟體更新中，並傳送給數千名客戶。

遭入侵的軟體

另一項重大風險來自遭入侵的軟體元件。開源程式庫可以加速開發，且被許多開發人員廣泛使用，但它們也可能包含弱點或惡意程式碼。當這些有問題的部分被建置到應用程式中時，其安全缺陷也會一併帶入。

供應商安全外洩

當可存取組織系統或資料的供應商發生安全事件時，供應商安全外洩便會帶來風險。如果具有網路或敏感資訊存取權的人員遭到入侵，攻擊者就能利用這層關係，並橫向移動進入客戶環境。

硬體竄改

韌體供應鏈攻擊涉及入侵嵌入於硬體元件中的軟體。這可能包括將惡意程式碼注入韌體更新、入侵裝置驅動程式，或操縱開機程序。

更新機制濫用

濫用更新機制是以用於傳送真實軟體更新的通道為目標。攻擊者會進一步入侵這些受信任的散佈路徑，使其能夠提供偽裝成來自受信任供應商的惡意軟體。

供應鏈風險管理的關鍵組成要素

供應鏈風險管理有一些關鍵組成要素，搭配使用時可發揮成效。它們形成一個完整的生態系，用於發現、監控及管理第三方供應商及其元件所帶來的風險。

供應商風險評估與管理

供應商風險評估為供應鏈安全奠定基礎。此流程會在授予新舊供應商存取系統或資料的權限之前，評估其供應商安全實務。良好的評估會檢視技術控制與安全政策、過往事件的審查，以及整體安全成熟度。在評估期間，組織應為供應商建立標準化問卷與評分系統，這有助於客觀比較各供應商。

SCA 與軟體物料清單 (SBOM)

SCA 工具會掃描應用程式程式碼，以識別所有使用中的第三方元件，並尋找其中已知的弱點。這些工具會產生所有軟體相依性的完整清單，並在這些元件中偵測到弱點時通知團隊。SCA 通常會輸出軟體物料清單 (SBOM)，其中列出應用程式中的所有元件，以及其版本、組態和任何可能存在的弱點。

供應鏈攻擊的事件回應規劃

供應鏈攻擊涉及一些並非每個事件回應計畫都會涵蓋的獨特組成部分。這使得組織有必要制定專門針對經由受信任供應商進入之入侵的行動計畫。此類計畫應著重於隔離裝置、聯絡相關供應商、了解入侵的範圍，以及減輕已造成的損害。回應團隊需要明確的指示，說明何時以及如何切斷受入侵供應商的存取權限，並在事件結束後恢復服務。

如何識別與評估供應鏈風險？

識別與分析供應鏈風險有一套系統化方法，涉及技術資源與業務流程分析的結合。但組織必須具備明確的方法，在潛在問題開始影響營運之前將其揭露出來。

建立涵蓋整個組織所使用之所有第三方程式碼、相依性、容器和雲端服務的完整軟體物料清單 (SBOM)，是數位供應鏈風險識別的起點。這應採用自動化清冊的形式，詳細說明每個應用程式使用了哪些元件、其版本資訊、已知弱點，以及對業務營運的重要性。

安全團隊必須將掃描工具與 CI/CD 管線整合，並與開發和 IT 團隊合作，以確保沒有任何相依性、API 或微服務被遺漏。

降低供應鏈風險的技術

組織可以部署多種有效策略來降低供應鏈安全風險。這些技術結合起來，可提供分層防禦，以分層方式防範外部威脅。

供應商安全要求

在供應商合約中明確定義安全要求，能為供應鏈安全奠定穩固基礎。這些要求應包括最低安全控制、合規認證、外洩通知時限，以及稽核權。法律協議應將安全列為不可協商事項，並允許組織對供應商執行標準，要求其對任何安全疏失負責。這些要求應具體、可衡量，且對不合規情況設有後果。

程式碼完整性驗證

驗證程式碼的完整性可確保任何進入環境的軟體皆未遭竄改。這包括驗證數位簽章、確認雜湊輸出符合預期，以及追蹤任何傳入程式碼的來源。組織必須部署自動化工具，在安裝前驗證軟體更新、第三方程式庫和應用程式元件的完整性。這些工具不僅可防止惡意程式碼被插入供應鏈，還能偵測合法軟體遭未經授權的修改。

最小權限存取

每個第三方整合點都應僅配置其功能所需的最低 API 權限與系統存取權。這種圍堵方法可限制任何外洩事件的影響範圍，防止遭入侵的元件存取超出其必要範圍的關鍵系統。

相依性備援

為關鍵套件與程式庫實作備援來源，可讓組織限制單一遭入侵的儲存庫或容器登錄可能造成的損害。此策略可在特定套件中發現安全問題時，快速切換至替代相依性。為關鍵相依性維護多個已驗證來源需要額外的開發資源，因此對於非關鍵元件而言，其安全成本效益可能不足以支持這項投入。

安全測試

持續對第三方產品與服務進行安全測試，可驗證供應商對安全性的聲明，例如滲透測試、弱點掃描，以及對所提供軟體進行程式碼審查。由於最高風險通常來自供應商系統與內部網路之間的連接點，因此測試應以這些整合點為目標。

供應鏈風險管理框架與標準

數個既有框架與標準可協助組織建立結構化的供應鏈安全方法。

美國國家標準與技術研究院 (NIST) 網路安全框架

美國國家標準與技術研究院 (NIST) 網路安全框架包含供應鏈風險管理的具體指引。NIST 特別出版物 800-161 提供有關識別、評估及回應供應鏈風險的詳細說明。此框架採用分層方法，協助組織根據其風險等級與資源限制來調整安全工作。

ISO/IEC 27036

ISO/IEC 27036 專門聚焦於供應商關係中的資訊安全。這項國際標準提供採購流程與持續供應商管理中的安全指引。它可協助組織在整個供應商生命週期中納入安全要求，從選擇到終止皆涵蓋在內。

網路安全成熟度模型認證 (CMMC)

Cybersecurity Maturity Model Certification (CMMC) 架構包含適用於國防承包商的供應鏈要求。它根據供應商所處理資訊的敏感程度，設定供應商必須實施的特定控制措施。雖然其設計初衷是用於國防領域，但許多組織也將 CMMC 作為自身供應鏈要求的模型。

卓越程式碼軟體保證論壇 (SAFECode)

Software Assurance Forum for Excellence in Code (SAFECode) 提供供應鏈中安全軟體開發的最佳實務。這項由產業主導的工作著重於從一開始就將安全性建置於軟體中的實用技術。

與供應鏈風險管理相關的挑戰

實施有效的供應鏈風險管理面臨多項重大挑戰。為了確保外部相依項目受到妥善保護，組織需要拆解這些層層挑戰。

可視性限制

組織對供應鏈的掌握能力並不完整。多數供應商會透過其自身的供應商進行採購，這會形成多層級且難以追蹤的相依關係。安全團隊可能不知道開源相依項目或第三方之間的關係所帶來的潛在風險。這導致透明度有限，也使得難以繪製所有威脅點。

資源限制

要有效實施供應鏈安全需要投入大量資源。安全團隊需要在供應商審查的完整性與可用的時間及預算之間取得平衡。這經常促使組織將安全工作集中於主要相依項目與主要程式碼儲存庫，而忽略較小的元件與微服務；然而，這些項目在軟體供應鏈中仍可能構成重大安全風險。

安全性與營運效率

嚴格的供應鏈控制可能使業務停擺並延遲重要計畫。安全審查可能拖慢採購流程，進而與需要快速讓供應商完成導入的業務單位產生明顯緊張關係。組織需要在安全需求與業務需求之間權衡。過度重視安全可能造成瓶頸並損害競爭力；另一方面，優先追求速度也可能帶來難以承受的風險。

舊有系統

許多組織仍在使用不具備現代安全能力的舊有系統。這些舊有應用程式可能使用具有已知弱點的過時元件，因為相關供應商早已停止支援。問題在於，更換這些系統成本高昂，且會對業務造成干擾。應規劃最終汰換舊有元件，但在此之前，安全團隊將需要制定策略來降低這些風險。

一致的安全標準

要在不同供應商之間建立一致的安全性幾乎是不可能的。它們來自不同產業，受到不同法規約束，且安全成熟度也各不相同。雲端服務供應商可能與硬體製造商截然不同。組織面臨的挑戰，是建立足夠靈活的評估技術，以便在不犧牲安全保證的情況下納入這些差異。

供應鏈風險管理最佳實務

有效的供應鏈安全有賴於一致的方法，以及紀錄、政策與組織承諾。以下最佳實務可協助組織建立對抗供應鏈威脅的強大防禦。

供應商安全評估流程

應建立標準化測試流程，以確認每個供應商都以相同方式接受評估。這應包括安全問卷、文件審查，以及與供應商風險等級相符的驗證步驟等流程。組織需要建立以風險為基礎的方法，並定義在各個等級應執行哪些檢查，例如對低風險與中風險供應商進行基本檢查，對關鍵供應商進行深入審查。

定期安全稽核

隨機稽核可檢查供應商是否言行一致。這些審查的例子包括自動化程式碼掃描、動態 API 測試，以及針對關鍵相依項目的儲存庫存取稽核。稽核必須驗證 CI/CD 管線、容器登錄庫與套件儲存庫的完整性，以確認已正確實施安全控制措施。

合約中的安全要求

在合約中為供應商納入詳細的安全要求，可建立可強制執行的義務。此類條款應詳細說明最低安全控制等級、通報外洩事件的時限、稽核權利以及不合規的後果。法務部門應與安全團隊合作，協商在技術上準確的條文。要求應涵蓋資料保護、存取控制、弱點管理 以及事件回應。合約也應包含在發生網路安全違規時的終止權。

程式碼簽署與驗證

對軟體的所有元件使用程式碼簽署，可確保程式碼在建立後未遭竄改。企業必須要求供應商提供的程式碼經過數位簽署，並具備驗證方法。在安裝更新或新元件之前，內部系統應先檢查簽章。此步驟旨在確保程式碼的完整性與真實性。所有未簽署或簽署不當的程式碼都應觸發警示，並禁止安裝。

安全意識文化

在所有團隊中建立員工意識，並與供應商互動，可強化供應鏈安全的人員面向。這包括培訓人員了解安全標準、指導開發人員檢查元件來源，以及提醒業務團隊注意供應商安全中的風險。應定期向員工更新新興供應鏈威脅與攻擊技術。

值得注意的供應鏈攻擊

以下安全事件在兩起重大供應鏈攻擊中格外受到關注。

SolarWinds 攻擊

在該次外洩發生後不到一個月，各家電腦安全供應商與政府網路安全機構即得出結論，認為 SolarWinds 攻擊（於 2020 年 12 月發現）是有史以來已識別或曾被嘗試過最複雜的供應鏈入侵事件之一。

駭客入侵了該公司的開發環境，並將惡意工具植入 Orion 網路監控程式。這個遭入侵的軟體更新經過數位簽章，並散布給估計 18,000 名客戶。在安裝之後，惡意軟體（稱為 SUNBURST）建立了一個後門，讓攻擊者得以進入受影響的網路。這起攻擊數月未被發現，波及多個高價值目標，包括數個美國政府機構、Microsoft、FireEye，以及眾多《財星》500 大公司。

NotPetya 攻擊

2017 年 6 月的 NotPetya 攻擊始於對 M.E.Doc 的更新；M.E.Doc 是一款用於稅務申報的烏克蘭會計軟體。駭客找到方法入侵該軟體的更新伺服器，並上傳會摧毀端點的惡意軟體，偽裝成真實更新。

雖然其設計原本僅針對烏克蘭組織發動攻擊，但這種可自我複製的惡意軟體很快便透過網路連線在全球擴散。航運巨頭 Maersk、製藥公司 Merck，以及快遞服務 FedEx 都遭遇重大營運中斷。以 Maersk 為例，該公司被迫更換 45,000 台電腦與 4,000 台伺服器，損失總額超過 3 億美元。

結論

隨著組織愈來愈常透過外部供應商與軟體相依項目遭受攻擊，供應鏈安全正變得至關重要。現代供應鏈的複雜性往往會產生安全漏洞，而攻擊者更傾向於利用這些漏洞。組織在某種程度上可以保護自己免受此類網路威脅，但前提是必須具備結構化的風險管理方法。

供應鏈安全歸根究柢是技術控制、供應商評估流程與組織意識的結合。組織需要掌握其外部相依項目的可視性，同時不能犧牲安全要求與業務需求。供應鏈攻擊正日益複雜，安全團隊將需要次世代工具，才能有效偵測這些攻擊。