數位轉型下的供應鏈安全挑戰

隨著工業4.0與智慧製造浪潮的推進，傳統製造業的營運技術（OT）環境正以前所未有的速度與資訊技術（IT）網路融合。從生產線的自動化控制系統、物聯網（IoT）感測器到企業資源規劃（ERP）軟體，軟體已成為現代製造業的生命線。然而，這種互聯互通的便利性也為惡意的網路攻擊者開闢了新的、更具破壞性的攻擊途徑。

製造業的獨特性在於其對「正常運行時間」（Uptime）的極致依賴。與一般IT系統相比，OT環境中的系統故障不僅可能導致資料洩露，更可能造成物理世界的重大損害、大規模停產和經濟損失。因此，製造業的安全防禦不能僅專注於周邊防護，而必須延伸至其營運所依賴的每一個軟體元件及其供應鏈。當製造商透過第三方供應商獲取軟體、零件或服務時，他們實際上也繼承了供應商的網路風險。一旦供應鏈中的某一環節，特別是軟體開發環節存在漏洞，整個製造生態系統的穩定性都將受到致命威脅。這使得安全軟體開發生命週期（SSDLC）的實施，從單純的開發規範，躍升為製造業維護其核心競爭力與國家經濟穩定的關鍵戰略。

 

網路攻擊的毀滅性後果

儘管供應商和行業專家對網路攻擊大肆渲染，但真正造成毀滅性後果的攻擊相對較少，不過，捷豹路虎(JLR)遭受的網路攻擊卻是個例外。根據路透社報道，這起事件導致捷豹路虎的生產完全停滯數週，可能對英國經濟造成超過20億美元的損失，並影響多達5,000家機構，許多人因此失去了工作。英國政府不得不介入，提供近20億美元的貸款擔保，以維持捷豹路虎的營運。

惡夢成真

捷豹路虎的攻擊事件正是製造商們明知可能發生的惡夢場景，而當它真正發生時，許多製造企業都慌忙地尋找避免重蹈覆轍的方法。

一個問題很快就顯現出來：供應鏈是製造商安全防護中最薄弱的環節之一。畢竟，捷豹路虎遭受的攻擊就源自於其供應鏈，而第三方承包商使用的憑證遭到外洩。

攻擊者是如何入侵供應鏈的？一個強有力的策略是針對製造商及其供應鏈合作夥伴所使用的軟體應用程式的開發工具和流程。捷豹路虎的事件提供我們一個重要的教訓：如果製造商及其供應鏈合作夥伴不警惕確保軟體供應商採用安全的開發實踐，他們就很容易遭受捷豹路虎所遭受的那種程度的攻擊。

供應鏈成為攻擊目標

利用軟體開發攻擊供應鏈並非新鮮事，但這種攻擊手段依然威力強大且危險。一些最著名的網路攻擊就採用了這種策略，包括2020年針對SolarWinds的臭名昭著的攻擊、2021年針對Kaseya VSA的攻擊以及2023年針對VoIP提供商3CX的攻擊。

攻擊者最近開發了一種新的攻擊手段：他們將惡意 Node 套件管理器 (NPM)注入軟體開發流程，JavaScript 開發人員使用 NPM 來共用和安裝可重複使用的程式碼。當NPM 是惡意程式時，攻擊會迅速蔓延，持續數月，並滲透到各種應用程式中。

最近針對 NPM 的攻擊案例之一是 Shai-Hulud 加密竊取程序，據報道該程序已入侵 500多個 NPM 軟體包，其中包括網路安全供應商使用的幾個軟體包。

NPM攻擊只是攻擊者滲透供應鏈的眾多方法之一，攻擊者還可以破壞軟體供應商的更新程式並利用軟體漏洞。

歸根結底，供應鏈應用程式存在安全漏洞，製造商需要確保其合作夥伴使用的應用程式是安全的。

面向MSP的一體化整合備份與網路安全平台

Acronis Cyber Protect Cloud 整合了資料保護、網路安全和終端管理功能。透過單一平台輕鬆擴展網路安全保護服務，同時有效率地經營您的 MSP 業務。由於供應鏈面臨風險，製造商需要評估現有和潛在的合作夥伴是否具備安全的軟體開發生命週期 (SSDLC) 實踐。

在大多數營運技術 (OT) 環境中，採購評估主要關注供應商的財務狀況、服務等級協定和基礎設施安全。但它們往往忽略了軟體開發過程中的漏洞——而這些問題可能會破壞供應鏈應用程式。

因此，對於製造商及其供應鏈合作夥伴而言，確保嚴格的供應鏈安全生命週期(SSDLC)實踐至關重要。如果製造商未能確保合作夥伴遵循SSDLC實踐，則可能面臨營運中斷、財務損失、違規和聲譽損害等風險。

 

安全防護的根本性轉變：SSDLC的核心價值

SSDLC的實施標誌著軟體安全哲學的根本性轉變，即從傳統的「開發後加固」（Security as an Add-on）模式，轉向「由始至終內建安全」（Security by Design）的整合模式。這種「安全左移」（Shift Left）的策略，核心價值在於大幅降低修復漏洞的時間成本與經濟成本。

事實證明，在開發生命週期中越早發現並修復安全缺陷，成本效益越高。例如，一個在需求分析或設計階段透過威脅模型識別出的漏洞，可能僅需數小時的設計調整即可修復。然而，若同樣的漏洞被延遲到產品發佈後才被發現（可能經由外部滲透測試、客戶報告或實際攻擊），則可能需要數週的緊急安全回應、發布補丁、通知客戶，並承擔潛在的停機損失和聲譽風險。在OT環境中，停機損失尤其巨大，且修補（Patching）過程往往因系統穩定性要求而受到嚴格限制。SSDLC正是通過一系列結構化、可重複的流程和工具，將安全性檢查和測試前推至開發流程的早期階段，從源頭上消除風險。

SSDLC：不僅僅是合規性複選框

SSDLC為何如此重要且有效？首先，歐盟NIS 2指令強制要求進行SSDLC流程，並要求制定正式的、有文件記錄的SSDLC流程。這也標誌著一種根本性的轉變，即從將安全性視為開發後的附加功能，轉變為將其嵌入整個軟體創建過程中。

在需求分析階段發現的漏洞可能只需幾個小時就能修復，而同樣的漏洞如果在發布後才發現，可能需要數週的緊急回應。實際上，成熟的SSDLC實作包括：

(1)    安全設計：在編寫任何程式碼之前，請定義安全需求並建立威脅模型。

(2)    安全的編碼實踐：開發人員接受安全培訓，強制進行程式碼審查和自動化安全測試。

(3)    依賴項管理：透過軟體物料清單 (SBOM) 實踐對第三方元件進行審查、追蹤和維護。

(4)    安全的發布管道：更新經過簽名、完整性檢查，並透過強化管道交付。

(5)    漏洞管理：協調揭露流程和明確的安全問題回應時間表。

對於製造商而言，這意味著控制生產線、管理關鍵系統和連接工業運營的軟體，從第一行程式碼到最終部署都嵌入了安全性。

 

SSDLC實踐的深度剖析與應用

為達到SSDLC的真正成熟度，供應商必須在其開發流程中深入落實上述五大實踐：

• 安全設計與威脅建模 (對應第1點)： 威脅建模並非一次性的審查，而是一個持續迭代的過程，用於識別、評估和緩解潛在的安全弱點。它強制開發團隊從攻擊者的視角思考，分析資料流、信任邊界和入口點。在OT系統中，這尤其重要，因為攻擊不僅可能導致資料洩露，還可能導致程序邏輯被篡改，進而對物理設備造成損壞，如過壓、過熱或錯誤操作。嚴格的威脅建模能確保所有與工業控制系統相關的安全需求在設計之初即被納入考量。

• 強化編碼實踐與自動化測試 (對應第2點)： 訓練開發人員使用安全的編碼實踐是基礎。更關鍵的是，必須實施自動化的安全測試工具，包括靜態應用程式安全測試（SAST）和動態應用程式安全測試（DAST）。SAST在程式碼編寫階段即檢查潛在漏洞，而DAST則在運行環境中測試應用程式的反應。此外，將安全檢查（如SAST/DAST）整合到持續整合/持續交付（CI/CD）管道中，實現「門禁」（Security Gates），確保只有通過安全審核的程式碼才能進入部署階段。

• 依賴項管理與SBOM (對應第3點)： 現代軟體高度依賴開源庫和第三方元件。供應鏈攻擊（如SolarWinds、NPM惡意軟體）往往利用這些依賴項的漏洞。軟體物料清單（SBOM）是對應用程式中所有組件、授權和版本進行的完整、分層清單。製造商必須要求其供應商提供詳細且最新的SBOM，並利用自動化工具持續監控SBOM中是否有已知的漏洞（透過軟體組成分析，SCA）。這使得製造商可以在供應商發布補丁之前，就預先掌握潛在風險。

• 安全的發布管道 (對應第4點)： 確保軟體更新和發布過程本身的完整性至關重要。這包括使用數位簽章來驗證更新來源，確保更新在傳輸過程中未被篡改，以及對部署環境（DevOps管道）進行最高級別的強化（Hardening），防止攻擊者將惡意程式碼注入發布鏈的任何環節。

安全開發的可靠證明：IEC 62443-4-1 認證

產業認證是衡量軟體安全生命週期(SSDLC)在開發過程中應用情況的可靠指標。雖然存在多種安全認證，但IEC 62443-4-1對製造供應鏈尤其重要。IEC 62443系列標準專門針對工業自動化和控制系統安全，這正是製造商營運的環境。

在此框架內，IEC 62443-4-1 專門關注安全產品開發生命週期要求，並為評估 OT 軟體供應商提供最嚴格、最相關的標準之一。與一般資訊安全框架不同，IEC 62443-4-1 認證表明供應商已實施專門為工業環境設計的實踐，在這些環境中，正常運行時間至關重要，修補視窗可能有限，並且軟體故障可能會造成物理世界後果。

IEC 62443-4-1 認證提供具體、經獨立驗證的證據，證明軟體供應商正在系統地將安全性融入每個產品中，而不僅僅是做出承諾。對於製造業和關鍵基礎設施領域的原始設備製造商 (OEM)、系統整合商和最終客戶而言，這提供了至關重要的信任基礎。

 

OT環境安全標準的戰略意義

IEC 62443系列標準為工業控制系統（ICS）安全建立了一個全面且分層的框架。該系列不僅涵蓋了-4-1所關注的產品開發生命週期，還包括：

• 一般性 (Part 1-X)： 涵蓋術語、概念和模型。

• 政策與程序 (Part 2-X)： 專注於資產所有者和系統整合商的安全要求。

• 系統級安全要求 (Part 3-X)： 定義安全等級（SL）以及系統的技術安全要求。

這凸顯了-4-1的戰略重要性：它是確保製造商所採購的產品（軟體、元件、系統）從設計之初就符合工業安全標準的唯一獨立驗證方法。由於OT環境的特殊性（例如，許多系統無法像IT系統那樣頻繁重啟或修補），產品的內建安全性（Security Built-in）比後續的修補（Security Patched-on）更為關鍵。IEC 62443-4-1認證向製造商保證，供應商在開發過程中已考慮到工業系統特有的高可用性、低延遲和長期運行需求，從而在根源上為製造商的網路韌性奠定了堅實的基礎。

重新思考評估方式

在評估與 SSDLC 合作夥伴的合作時，製造商應考慮：

(1)    將 SSDLC 標準融入採購流程：在 RFP 和合約中加入安全開發要求，以便供應商從一開始就了解預期。

(2)    要求提供結構化證據：作為盡職調查的一部分，要求提供認證範圍、稽核報告、SBOM 記錄和測試結果。

(3)    優先考慮相關認證：對於在工業環境中運營的產品供應商，應特別關注 IEC 62443-4-1 認證；對於組織安全治理，應重點關注 ISO/IEC 27001 認證；對於適用的雲端特定認證，應重點關注相關認證。

(4)    持續評估成熟度：拋棄二元問卷調查，根據成熟度連續體評估供應商，並將持續監控納入供應商管理。

製造商再也不能將供應商安全評估僅視為關注基礎設施和營運的工作，漏洞往往源自於產品開發生命週期，製造商必須確保在開發生命週期內防範這些漏洞。

 

建構具備網路韌性的供應鏈戰略

傳統的供應商評估模式將安全視為IT部門的獨立任務，這在當前的供應鏈威脅環境下已不再可行。製造商必須將SSDLC標準化視為其整體風險管理和採購策略的核心。這意味著，安全開發要求應成為投標邀請書（RFP）中的強制性條款，且合約中必須明確規定對SBOM交付、漏洞修復時間表和安全審計的義務。

此外，從「一次性評估」轉向「持續監控」的供應商成熟度評估模式至關重要。製造商不應僅依賴供應商的自我聲明或單一的合規性問卷，而應要求結構化且可驗證的證據，例如季度性的靜態程式碼分析報告、漏洞披露記錄和第三方認證稽核摘要。只有通過系統性的證據要求和標準（如IEC 62443-4-1）的實施，製造商才能建立起對其供應鏈夥伴安全實踐的深層信任，從而有效降低系統性網路風險，保障關鍵製造營運的連續性和韌性。總而言之，安全軟體開發生命週期是製造業從被動防禦走向主動韌性的關鍵橋樑。

資料來源：https://www.bleepingcomputer.com/news/security/why-a-secure-software-development-life-cycle-is-critical-for-manufacturers/