供應鏈安全事件的頻頻爆發，使得供應鏈安全管理越來越被政府和企業重視。企業供應鏈中可能導致安全風險的因素非常復雜，如果沒有良好的供應鏈安全管理和風險控制，由于供應鏈導致的安全風險會急劇增加，企業甚至難以了解攻擊是如何發生，這樣就難以避免和防范下一次類似的攻擊。

　　供應鏈系統安全概述

　　與企業信息安全管理類似，供應鏈安全管理并不是純粹的IT問題，而是人、流程和知識的綜合因素。在供應鏈龐雜的環境中，需要從攻擊者的角度進行安全防御建設。與傳統的信息安全不同的是，供應鏈安全涉及到物理世界與信息世界的交互，兩者之間并無間隙，且相互影響。

　　其中，供應鏈系統安全涉及到的方面包括企業供應鏈管理中的：

　　從與供應商的商務關系到供應商的技術管理和實踐，相關的風險又依次包括：

　　第三方供應商：供應商企業健康狀況和企業實力

　　供應商安全實踐：供應商內部安全管理和安全實踐

　　被攻陷的軟件、硬件：供應商提供的產品可能被攻擊者掌握

　　軟件、硬件的安全漏洞：供應商提供的產品本身存在安全漏洞

　　軟件、硬件的惡意代碼：供應商提供的產品被植入了后門、木馬

　　第三方數據泄露或數據聚合：供應商存儲的客戶數據泄露或供應商通過數據分析獲取客戶機密/秘密

　　除此之外，還包括企業自身在技術活動中引入的第三方技術，比如開發人員在編程中引用的第三方開源或商業組件、調用的SDK（Software Development Kit）、使用的開發工具或運維工具（IDE、IDE插件、數據庫連接管理工具、服務器連接管理工具）等。

　　當下很多企業在從事諸如駐場服務、駐場咨詢、現場交付等等活動的過程中，還會涉及到與供應商或供應商人員的身份認證、授權、權限管理以及數據分享的問題，比如企業在財務審計中需要將財報信息同步給事務所人員、安全公司駐場為企業提供滲透測試服務、供應商交付人員在企業辦公場所進行產品交付、配置工作。

　　所以供應鏈安全本質上是企業管理自身管理范圍之外的一系列相關企業、產品、技術、人員、流程，并期望相關企業和人員具備不低于企業自身安全水平的安全成熟度。

　　從技術供應的角度，企業供應鏈系統安全的風險來源如下圖：

　　供應商管理和采購

　　當前，每家企業都需要借助其他供應商的能力完善自身的生產能力，在選擇供應商和進行采購活動之前，企業自身需要完善相關的供應商管理制度或機制。

　　根據ISO27002（信息安全控制實用規則），涉及到供應商安全的規范包括：

　　供應商關系的信息安全：供應商遵守的信息安全策略、供應商協議的安全問題、信息和通信技術供應鏈；

　　供應商服務交付管理：監視和評審、變更管理。

　　供應商關系的信息安全是指企業應當與供應商就供應產品或服務過程中，供應商人員應當遵守的最低安全要求和安全策略，確保供應商對于企業信息資產的訪問是安全可控的，并明確雙方合作中安全風險的處置原則和要求。供應商服務交付管理是為保障供應商的交付物保持一定的安全和質量水準，并確保交付變更不會帶來新的安全風險。

　　根據SOC2（美國注冊會計師協會開發的針對行業服務的審計標準）的合規要求，企業在供應商管理中需要具備：

　　在選擇和評估供應商時，需要評估供應商的商務信息和技術能力，商務信息包括：法人、注冊地、員工規模、注冊資本、股權結構、融資信息、企業資質、過去三年工商變更信息或工商處罰信息，技術能力包括：安全資質、安全白皮書、安全實踐描述（基礎安全、數據安全、漏洞管理、人員管理等）、開發實踐描述（開發團隊、開發流程等）。

　　商務信息可以通過被動調查的方式從諸如天眼查、企查查獲取供應商的相關信息，技術能力可以通過問卷調查的方式由供應商主動提供，調查的方式除供應商自述之外，還可要求提供相關的系統截圖或代碼截圖證明相關的能力。

　　更進一步，可以在供應商的授權下，采用穿行測試、漏洞測試的方法，對于供應商系統進行安全審查和評估，范圍包括安全合規、安全要求、安全設計、安全漏洞，確保供應商的提供的產品符合企業的安全要求。

　　供應商評估的目的是為了讓企業了解供應商的以下信息：

　　供應商的軟件/硬件研發過程是否有文檔、可復制、可衡量；

　　產品研發過程中是否有緩解漏洞的措施和手段；

　　供應商的漏洞管理能力是怎樣的，是否有發現、跟蹤、驗證、關閉漏洞能力；

　　供應商的配置管理和質量管理是怎樣的，如何確保不會因配置導致安全風險，以及確保質量符合要求；

　　惡意軟件/后門是如何檢測、防護、清理的；

　　數據管理生命周期中數據采集、存儲、使用、銷毀是如何的，包括保護、加密、留存、銷毀；

　　人員安全是如何實踐的，包括人員背景審查和審計、關鍵崗位保密協議和能力驗證等等；

　　產品發布過程是如何保障安全的，是否有發布審核、批準和驗證流程。

　　在設定供應商的準入門檻，評估供應商符合要求之后，相關的供應商應當進入企業的供應商名單。在與供應商進行合同簽約過程中，依然要考慮合同內容中的安全要求、責權信息，明確雙方的義務與權利，以及SLA中的產品、服務等級、質量以及賠償方式和賠償內容。

　　供應商連續性管理

　　供應鏈中相同的第三方產品或服務不應當只有當前已采購的，還應當維護一定量的備用供應商和后備產品服務。這需要企業在供應鏈管理中考慮以下三點：

　　供應商的合作等級：取決于供應商的實力，比如鉆石級、白金級、白銀級；

　　供應鏈的安全風險等級：供應商提供的產品或服務在保密性、完整性、可用性方面對企業造成的風險級別；

　　安全風險的緩解措施：包括企業自身的替代能力，和其他供應商的替代能力；

　　企業自身供應鏈風險的評估內容包括：

　　在風險識別過程中，有很大的機會能夠發現企業內部的重復采購或無效采購，尤其是沒有統一的采購部門，或采購部門沒有記錄和管理采購內容的情況。在沒有統一采購部門的情況下，安全部門可以和財務部門進行協作，安全部門的供應鏈風險評估結果與財務部門進行同步，前者把握風險關，后者把控資金關，避免無效采購或重復采購。

　　供應商質量管理

　　對于已經合作的供應商，企業應當每年進行一次供應商評估，定期評估可以讓企業掌握供應商的企業風險和產品/服務風險，避免由于供應商風險造成的企業自身風險。定期評估的內容可參考上文供應商管理和采購部分的內容。

　　對于在產品使用和服務過程中出現的安全事件，企業應當進行驗證、記錄、反饋，并督促供應商整改，對于事件的嚴重等級按照風險進行劃分，并基于供應商準入門檻以及合同中的要求評估是否繼續采用該供應商的產品或服務。對于發生嚴重事件并影響到企業安全的供應商，或持續不符合供應要求的供應商，企業可以采用供應商降級或解約的方式將供應商從供應商名單中剔除。

　　質量不佳的供應商不僅無法維持企業供應鏈安全的質量和要求，而且會消耗企業大量的管理成本、運營成本與供應商進行反復溝通、整改、驗證工作，最終的結果可能依然不符合要求，勉強的合作讓企業的采購得不償失。

　　第三方技術管理

　　第三方技術指的是圍繞技術引用和實現的技術工具、接口和組件，由于更偏向技術應用，因此往往不在企業的采購清單和計劃中，由部門或員工自行進行選擇和使用。

　　技術工具

　　技術工具在企業采購中屬于小眾需求，或不被企業重視的采購需求，在國內多數企業依靠員工自行解決相關的工具需要，除了供應鏈的安全風險，技術工具還會引起知識產權糾紛。對于技術工具帶來的供應鏈風險和影響，常見的方案有三種：

　　終端管控

　　企業通過采購終端管控系統來實現對于所有員工電腦終端的管理，需要在員工電腦端安裝管控軟件（員工無法自行卸載，需要管理員密碼），管控系統通常還帶有網絡準入功能，與企業內部的員工賬戶體系打通可以實現電腦終端的身份認證，同時通過管理端可以檢查、限制甚至操作電腦終端的軟件運行情況，從而可以對員工使用的應用情況進行統一檢查和管理。但該方案需要專門的崗位對終端管控系統進行管理和運營，人員的疏忽和運營的疏忽都會造成該方案形同虛設。

　　軟件白名單

　　通過設立軟件白名單庫，結合企業內網的限制（無法從外網下載軟件安裝包），可以實現軟件來源的限制，確保員工使用的軟件都是來自白名單庫。但白名單庫中軟件更新后，員工電腦的軟件遲遲未更新同樣會帶來風險，因此也可以采取終端管控+軟件白名單的方式，保障軟件白名單庫提供安全可靠的軟件。

　　云桌面

　　目前越來越多企業開始采用云桌面的方式來徹底解決終端工具風險的問題，即輕終端、重云端。企業員工通過身份驗證訪問云端桌面進行日常辦公，包括研發工作，可以確保所有的軟件在云端都是可控且安全的，但缺陷是會由于網絡不穩定或網絡延遲造成辦公效率降低。

　　技術接口

　　無論是企業自研的軟件，還是采購的第三方軟件或硬件，都可能會存在和需要調用第三方技術接口或使用第三方SDK的情況，由于接口或SDK可能是個人開發，或接口服務提供，因此很難對供應商進行評估和管理。因此，企業應當對于技術接口和SDK的調用進行梳理和安全評估，確保即便接口提供方出現的安全風險，也在企業可承受范圍之內。對于不得不用的接口調用，可以通過網絡邊界的流量限制和流量監測確保接口不會被濫用。

　　技術組件

　　開發過程中必不可少的會用到不同開發語言的組件或庫，這些組件大多是由個人開發者開發并開源的，雖然方便了開發過程，加速了開發進度，但個人維護的組件常常因為種種原因無法及時更新或升級，以至于一旦被人發現存在某種漏洞，使用組件的企業便需要快速響應和處理。

　　因此SCA（Software Composition Analysis）工具應運而生，SCA是一類工具的統稱，可以通過分析源代碼識別其中引用的開源組件信息（名稱、版本、校驗值）、組件漏洞、開源協議等信息，從而幫助開發人員和安全人員快速對于企業代碼中的開源風險進行識別。全面、清晰、深入地掌握軟件成分和物料清單，有助于在出現新的安全漏洞時進行快速響應和排查。SCA工具從開發階段到部署階段都可以運用。

　　軟件供應鏈安全框架

　　供應鏈安全問題是人、流程和知識的問題，而非純粹的技術問題。在解決軟件研發過程的供應鏈安全問題時，需要貼合SDLC（軟件開發生命周期）考慮供應鏈安全風險。為此，Goolge提出了SLSA（Supply-chain Levels for Software Artifacts）框架，微軟提出了SCIM（Supply Chain Integrity Model）框架以及CNCF（云原生計算基金會）的軟件供應鏈最佳實踐，三種框架都強調對于源代碼、第三方依賴、構建系統、制品、發布、部署的安全性。

　　以SLSA框架為例，SLSA是一個標準清單和控制框架，用于緩解軟件項目中的代碼和軟件包的供應鏈風險。SLSA框架從三個方面評估軟件供應鏈的安全等級，分別是源碼、構建和依賴，并可劃分為4個級別：

　　Level 1：構建過程是完全腳本化或自動化，且能夠基于結果識別來源源碼；

　　Level 2：使用有身份認證能力的版本控制和托管服務，確保構建來源是可信的；

　　Level 3：源碼和構建平臺符合可審計標準，且有成品完整性保證；

　　Level 4：所有變更均有雙人評審，且有封閉的、可重復的構建過程；

　　在SLSA框架中，應用系統的發布流程會存在以下安全風險：

　　以Level 4等級要求為例，在軟件構建過程中企業需要實踐以下4點：

　　可驗證的版本控制

　　開發人員提交代碼變更需要多因子身份認證（如用GPG簽名commit）及提交時間戳，必須采用類似GitLab或GitHub的版本控制系統，確保能夠跟蹤每次變更、代碼分支/標簽/Ref或提交人；

　　雙人評審

　　每一個進入最終版本的提交都必須經過至少一個其他合格的審查員的評審，確保代碼的正確性、安全性、需求吻合和代碼質量等等；

　　安全的自動化構建流程/環境

　　構建流程應當是完全自動化的，且構建環境應該具有隔離性（構建過程不受其他構建影響）、封閉性（構建過程應包含所有依賴關系）、無參化（構建結果只受源代碼影響）和短暫性（每次構建都在專門的容器或虛擬機中進行）。

　　可重復構建的流程

　　相同的源代碼構建每次構建的結果總是相同的，并且構建流程是可以驗證的。

　　不足的是，對于最終用戶而言，雖然可以使用哈希值進行軟件包來源校驗，但無法確保軟件包的構建來源是可靠的，僅僅通過校驗哈希值無法解決這個問題。因此，構建安全的軟件供應鏈構建流程便尤為重要。

　　附、供應鏈安全最佳實踐

　　英國國家網絡安全中心（NCSC）提出了供應鏈安全管理準則，分為4個部分的12條：

　　理解風險（Understand the risks）

　　理解哪些需要被保護以及為什么；

　　知道你的供應商是誰，并了解它們的安全狀況；

　　了解供應鏈帶來的安全風險；

　　建立控制（Establish Control）

　　和供應商溝通你的安全需求

　　為供應商設立和溝通最低安全要求

　　將安全考慮納入合同流程，并要求供應商也如此

　　履行你作為供應商和客戶的安全責任

　　在供應鏈內部提升安全意識

　　為供應鏈提供安全事件支持

　　檢查安排（Check your arrangements）

　　建立保障措施確保供應鏈管理能夠實現

　　持續改進（Continuous improvement）

　　鼓勵供應鏈持續改進和提升安全能力

　　與供應商建立互信關系

更多信息可以來這里獲取==>>電子技術應用-AET<<