文／楊建洲 James Yang，Profet AI 執行長特助
資安邊界逐漸模糊的高度連結供應鏈
上一篇我們談到了在半導體產業導入 AI 的資安隱憂，而這篇我們想從半導體供應鏈的資安出發，分享建立在高度複雜且彼此緊密連結的供應鏈協作之下，資安防護之於維持競爭力優勢的重要性。
由於半導體製造的每一個環節都依賴不同企業提供的技術、設備、資料與服務，這種高度分工讓半導體產業得以維持龐大的生產規模與效率，但同時也讓企業的資安邊界逐漸變得模糊。
過去談企業資安，思考的往往是如何保護自己的網路、設備與系統；但當外部供應商可以遠端連線、第三方軟體可以存取系統、SaaS 平台透過 API 串接企業資料，而供應商本身又依賴其他第三方服務時，企業真正需要管理的範圍，早已超越自己的 IT 環境，只要其中一個節點遭到入侵，就可能沿著既有的信任關係存取權限，將風險帶進企業內部，甚至是其他企業。
因此，對半導體產業而言，供應鏈資安已不再只是供應商管理的附加項目，而逐漸成為企業營運韌性的一部分。
供應鏈正在成為新的攻擊面
這樣的風險並不是假設性的情境。資安風險評估與供應鏈資安公司 SecurityScorecard 於 2025 年針對近 550 名負責資安策略與管理的主管進行採訪，結果顯示超過 70% 的受訪者表示，組織過去一年至少經歷一次重大第三方資安事件；研究同時指出，只有不到一半的組織能監控其延伸供應鏈中 50% 以上的資安狀況。這代表企業面對的問題不只是第三方事件增加，更在於企業未必能完整看見自己的供應鏈風險。
到了 2026 年，SecurityScorecard 的後續研究更指出，78% 的受訪者表示，其組織內部供應鏈資安計畫，僅涵蓋不到一半供應商生態系。當供應商、服務與數位連結持續增加，企業的監督範圍卻沒有同步擴張，供應鏈就可能形成一個企業自身難以完全掌控的風險網路。
而發生於 2025 年 9 月的 npm 供應鏈攻擊即是一例。這起事件波及 18 個廣泛使用的 JavaScript 套件，資安公司 Palo Alto Networks 的情報團隊 Unit 42 指出，這些套件合計每週下載量超過 26 億次，而攻擊者透過入侵套件維護者之帳號，將惡意程式碼放入原本受到信任的套件，使下游使用者在正常安裝或更新軟體時，可能將遭污染的程式碼帶入自己的軟體開發或執行環境。
這起事件值得注意的地方，除了第三方軟體遭到污染，更重要的是攻擊者利用了供應鏈中的信任關係。下游企業不直接與攻擊者產生互動，僅是正常使用原本信任的軟體元件，就可能成為攻擊鏈的一部分。
類似的問題也出現在 SaaS 與第三方應用程式的整合關係。2025 年 11 月，Salesforce 發現與 Gainsight 應用程式連線有關的異常活動，相關連線可能使部分客戶資料遭到未授權存取。對此，Salesforce 隨後撤銷相關應用程式的存取權限，並表示沒有跡象顯示事件源自 Salesforce 核心平台本身的漏洞。這起事件顯示，供應鏈資安的風險不只來自供應商本身的產品或系統，也可能存在於企業與第三方之間的整合、信任關係與存取權限。攻擊者不一定需要直接突破企業核心平台，也可能利用具有合法權限的第三方連結尋找攻擊路徑。
這些案例共同說明一件事，那就是攻擊者不一定需要直接突破企業本身的防禦，也可能利用企業與第三方之間的信任、整合與權限尋找攻擊路徑。
資安複雜度更高的半導體供應鏈
這個問題放到半導體產業，複雜度又更高。半導體製造高度依賴設備商、材料商、工程服務商與軟體供應商，設備本身又可能涉及作業系統、應用程式、網路連線、遠端維護與資料交換。也就是說，一台設備背後可能連結的不只是一家供應商，而是一整組企業、系統與服務。
上一篇文章中我們曾提到，半導體產業已經有針對半導體製造設備的資安標準 SEMI E187。此外 2025 年台灣數位發展部也攜手 SEMI、TSMC、ASE 等產業夥伴推動 SEMI E187 半導體設備資安標準驗證制度，並於 2026 年正式實施，進一步建立設備資安的第三方驗證機制 ，讓設備資安要求從單一企業的要求，逐步走向產業共同的驗證與信任機制。
然而，有標準並不代表整條供應鏈就安全。E187 主要聚焦於半導體製造設備，而企業實際面對的供應鏈風險，還包括第三方服務、遠端維運、SaaS、API、軟體元件、供應商帳號，以及供應商自身的第三方依賴。
因此，雖然 SEMI E187 確實為半導體供應鏈資安的重要基礎，但不能直接等同於完整的供應鏈資安治理。標準解決的是「應該做到什麼」，治理機制則必須進一步回答「誰來做、怎麼驗證、多久檢視，以及風險發生變化時怎麼處理」。
過去企業談供應鏈資安，往往從供應商管理開始，透過問卷、稽核、認證與合約要求，確認第三方是否符合企業的安全標準。這些機制仍然重要，但當供應鏈進一步延伸到供應商的第三方、軟體元件、SaaS、API 與數位整合時，企業需要掌握的就不再只是單一供應商的安全狀態，而是整個供應鏈中的關鍵依賴、風險節點，以及風險如何沿著不同企業與系統之間的連結傳遞。
「要求安全」不等於「能夠安全」
這也帶出供應鏈資安最現實的挑戰。
從客戶端來看，企業可能同時管理大量供應商，而每一家供應商的角色、權限、接觸資料與業務重要性都不同。如果所有供應商都採用相同的資安要求，企業需要投入大量人力進行問卷、稽核與追蹤，也可能讓真正高風險的供應商被大量低風險資訊淹沒。
因此，企業真正需要回答的問題，不只是「我要管理多少家供應商」，而是「哪些供應商與我的關鍵資產、系統、設備與營運存在最高風險的連結」。
例如，僅提供一般物料的供應商，與可以遠端連接製造設備的設備維護商，其風險顯然不同；只能讀取一般資訊的帳號，與能夠存取核心研發資料的高權限帳號，也不應該採取相同的管理方式。
而從供應商端來看，資安要求同樣存在現實限制。對部分中小型供應商而言，新增的資安要求可能意味著額外的人力、技術與維運成本。當不同客戶提出不同的問卷、認證與控制要求時，供應商可能需要投入大量資源處理合規工作，卻不一定能直接轉化成風險降低。
因此，供應鏈資安不能只是客戶不斷增加要求，再將責任與成本往供應商端轉移。真正成熟的治理方式，應該讓安全要求與供應商實際承擔的風險相匹配，並建立清楚的驗證方式與改善機制。
供應鏈資安的三個轉變
1.從一次性稽核為主，走向稽核與持續性風險管理
一次性的供應商問卷或稽核仍然有其價值，原因在於它可以確認供應商是否建立基本控制，也能成為採購與合約管理的重要依據。然而它無法代表供應商未來幾個月甚至幾年的安全狀態。原因在於供應商的系統可能改版、帳號與權限可能增加、遠端維護方式可能改變，甚至供應商自己的第三方也可能發生資安事件。
對此，美國國家標準與技術研究院 NIST 對 Cybersecurity Supply Chain Risk Management（C-SCRM）的概念，就是將供應鏈資安視為一套持續識別、評估與降低風險的系統性過程。因此，成熟的供應鏈資安不應只依賴年度問卷或一次性稽核，而應形成一個持續循環：先辨識供應商與企業之間的依賴關係，再依風險進行評估與控制，之後持續監控環境變化，最後在事件發生或風險升高時進行應變與改善。稽核回答的是「目前是否符合要求」，持續性管理則進一步回答「風險現在有沒有改變」。
2.從全面要求走向風險分級
供應鏈越龐大，越不可能要求所有供應商採取完全相同的資安控制，企業應依照供應商接觸的資料、系統、設備、權限與業務重要性，決定管理強度。風險較低的供應商，可以採取較簡化的評估與驗證方式；涉及核心製造環境、關鍵設備或敏感資料的供應商，則需要更深入的安全評估、權限管理、技術驗證與持續監控。
這並不是降低安全要求，而是讓有限的資安資源真正投入高風險的位置。對企業而言，重要的不僅是管理多少家供應商，更要能清楚辨識哪些供應商一旦遭到入侵，可能對企業的關鍵營運造成重大影響。
3.從單向要求走向協同治理
如果供應鏈資安只是「客戶要求供應商做到什麼」，最終很容易變成責任轉嫁。客戶把資安要求寫進合約，供應商提交文件，雙方完成稽核，流程看似結束，但實際風險可能仍然存在。
真正有效的供應鏈治理，應該讓客戶、供應商與相關服務提供者建立清楚的責任邊界與應變機制。哪些風險由供應商負責降低？哪些風險需要雙方共同管理？供應商發生事件時多久需要通報？企業是否能快速撤銷權限、隔離連線？這些問題都需要在平時就被定義。
因此，供應鏈資安並不是要求所有企業「一起做到最高標準」，而是建立一套能夠依風險分配責任、持續驗證狀態，並在事件發生時快速協同的治理模式。
從供應商管理，走向供應鏈治理
當供應鏈一路延伸到第四方、第五方甚至更多層級時，企業不可能逐一掌握每一個節點。因此，供應鏈資安的成熟度，不應該只用管理的供應商數量來衡量，而應該看企業是否能辨識關鍵依賴、判斷風險優先順序，並在無法直接控制的情況下掌握自身的暴露程度與潛在影響。
對半導體產業而言，真正需要保護的從來不僅限於某一台設備、某一個帳號或某一家供應商，而是跨企業協作過程中所累積的製程資料、工程 Know-how、智慧財產、設備能力與營運流程。這些價值分散在不同企業、不同系統與不同服務之間，並透過設備、軟體、人員與資料持續流動。
因此，半導體供應鏈越複雜，企業就越不可能單純憑藉管理供應商來確保安全。真正的挑戰，是建立一套能串聯企業、系統與供應鏈，持續辨識與管理風險的治理機制。換句話說，企業不只要管理供應商本身，更必須看見供應鏈中的關鍵依賴、辨識高風險節點、理解權限與資料流向，並在風險發生變化時及時調整管理方式。
當企業從「管理供應商」進一步走向「治理供應鏈」，資安就不再只是把要求與責任往下一層傳遞，而是建立一套能看見關鍵依賴、持續掌握風險，並在某個節點發生問題時快速反應的治理能力。對半導體產業而言，供應鏈的下一道資安防線，不只是要求每一個節點做到安全，而是讓整個生態系更透明、更可驗證，也更有韌性。