第三方技術(shù)管理

第三方技術(shù)指的是圍繞技術(shù)引用和實現(xiàn)的技術(shù)工具、接口和組件，由于更偏向技術(shù)應(yīng)用，因此往往不在企業(yè)的采購清單和計劃中，由部門或員工自行進行選擇和使用，如上期文章中提到的XCodeGhost事件。

技術(shù)工具

技術(shù)工具在企業(yè)采購中屬于小眾需求，或不被企業(yè)重視的采購需求，在國內(nèi)多數(shù)企業(yè)依靠員工自行解決相關(guān)的工具需要，除了供應(yīng)鏈的安全風險，技術(shù)工具還會引起知識產(chǎn)權(quán)糾紛，比如：企業(yè)收到某某產(chǎn)品公司發(fā)來的律師函，稱企業(yè)內(nèi)部有使用盜版產(chǎn)品。隨著知識產(chǎn)權(quán)意識的提高以及相關(guān)法律風險的提高，越來越多企業(yè)開始統(tǒng)一采購技術(shù)工具或產(chǎn)品，比如IDA Pro、Burp Suite、XShell、Windows、Office等等。

對于技術(shù)工具帶來的供應(yīng)鏈風險和影響，常見的方案有三種：

終端管控：企業(yè)通過采購終端管控系統(tǒng)來實現(xiàn)對于所有員工電腦終端的管理，需要在員工電腦端安裝管控軟件（員工無法自行卸載，需要管理員密碼），管控系統(tǒng)通常還帶有網(wǎng)絡(luò)準入功能，與企業(yè)內(nèi)部的員工賬戶體系打通可以實現(xiàn)電腦終端的身份認證，同時通過管理端可以檢查、限制甚至操作電腦終端的軟件運行情況，從而可以對員工使用的應(yīng)用情況進行統(tǒng)一檢查和管理，這也是企業(yè)統(tǒng)一采購辦公電腦的原因（不會因為人員入職和離職引入終端安全風險或造成終端管理密碼泄露，如果是個人電腦，則面臨離職后不知道管理員密碼，需要重裝系統(tǒng)才能卸載管控軟件的問題）。在面臨知識產(chǎn)權(quán)糾紛時，這種方式可以快速對涉及的應(yīng)用進行排查，同時有利于終端設(shè)備統(tǒng)一管理。但該方案需要專門的崗位對終端管控系統(tǒng)進行管理和運營，人員的疏忽和運營的疏忽都會造成該方案形同虛設(shè)。

軟件白名單：通過設(shè)立軟件白名單庫，結(jié)合企業(yè)內(nèi)網(wǎng)的限制（無法從外網(wǎng)下載軟件安裝包），可以實現(xiàn)軟件來源的限制，確保員工使用的軟件都是來自白名單庫。白名單庫提供日常辦公中不同崗位常用的軟件，且每款軟件都經(jīng)過安全部門或相關(guān)部門的檢查和評估，確保每個軟件使用的是穩(wěn)定版本和安全版本。但可能存在，白名單庫中軟件更新后，員工電腦的軟件遲遲未更新所帶來的風險，或者員工私自安裝其他版本軟件造成的安全風險，因此也可以采取終端管控+軟件白名單的方式，通過終端監(jiān)控軟件的使用，通過軟件白名單庫提供安全可靠的軟件。

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

技術(shù)接口

無論是企業(yè)自研的軟件，還是采購的第三方軟件或硬件，都可能會存在和需要調(diào)用第三方技術(shù)接口或使用第三方SDK的情況，由于接口或SDK可能是個人開發(fā)，或接口服務(wù)提供，因此很難對供應(yīng)商進行評估和管理。對于接口和SDK的安全評估除了安全檢測之外，無法更進一步對接口實現(xiàn)、處理、分析、存儲、傳輸做更多評估，比如：調(diào)用物流接口查詢快遞單號的物流信息，物流接口提供方可能泄露相關(guān)的快遞單號和物流信息；調(diào)用文檔格式轉(zhuǎn)換接口，接口提供方可能存儲原始文檔并泄露相關(guān)信息。因此，企業(yè)應(yīng)當對于技術(shù)接口和SDK的調(diào)用進行梳理和安全評估，確保即便接口提供方出現(xiàn)的安全風險，也在企業(yè)可承受范圍之內(nèi)。

對于不得不用的接口調(diào)用，可以通過網(wǎng)絡(luò)邊界的流量限制和流量監(jiān)測確保接口不會被濫用。比如：限制網(wǎng)絡(luò)出口，或僅允許必要的接口出網(wǎng)，并監(jiān)測接口調(diào)用記錄。上文中提到的SolarWinds事件發(fā)生后，采取的應(yīng)急處理辦法就是限制Orion軟件（后門采用DGA算法生成與C2連接的域名）部署環(huán)境的出口，或限制出口訪問。

技術(shù)組件

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

因此SCA（Software Composition Analysis）工具應(yīng)運而生，SCA是一類工具的統(tǒng)稱，可以通過分析源代碼識別其中引用的開源組件信息（名稱、版本、校驗值）、組件漏洞、開源協(xié)議等信息，從而幫助開發(fā)人員和安全人員快速對于企業(yè)代碼中的開源風險進行識別，本質(zhì)上是對源代碼庖丁解牛，現(xiàn)如今的SCA工具能夠根據(jù)源代碼、二進制文件、鏡像文件生成SBOM（Software Bill Of Materials）清單，更全面和深入地分析軟件構(gòu)成，比如供應(yīng)商信息、作者信息、間接引入的組件信息等等，就像食品袋上的配料表，對于軟件構(gòu)成一目了然。上文中提到的Log4j組件漏洞被曝出后，國內(nèi)的SCA廠商也很快跟進更新了組件漏洞數(shù)據(jù)，客戶可以在短時間內(nèi)快速排查涉及相關(guān)組件的項目、代碼以及對應(yīng)的部門，而在之前安全部門在應(yīng)急響應(yīng)中最花費時間的是排查漏洞涉及的項目、部門和人員，而負責項目的研發(fā)人員自身也未必全面了解組件的構(gòu)成情況，因而容易有漏網(wǎng)之魚。

全面、清晰、深入地掌握軟件成分和物料清單，有助于在出現(xiàn)新的安全漏洞時進行快速響應(yīng)和排查，實際開發(fā)過程中，企業(yè)常常需要花很長時間排查漏洞影響的組件涉及的業(yè)務(wù)、部門、項目、代碼、人員，并協(xié)同相關(guān)人員進行漏洞修復或組件升級，而實際上開發(fā)人員自己也不見得能夠全面了解軟件的構(gòu)成，尤其是組件引用的組件或更深層次的組件。

SCA工具從開發(fā)階段到部署階段都可以運用，典型的應(yīng)用場景如下圖：

企業(yè)私服安全管控：私服倉庫中的組件安全是開源治理中重要一個環(huán)節(jié)，只有從源頭來杜絕安全問題才能從后期的開源治理中有更好的收獲。SCA工具支持多種類型的私服防火墻功能，根據(jù)配置的安全策略，實現(xiàn)對私服引入外部組件的實時檢測，一旦發(fā)現(xiàn)存在風險的組件被引入則執(zhí)行阻斷，做到私服倉庫中組件的安全可控。

研發(fā)流程：研發(fā)人員在編碼過程中，可以從企業(yè)私服倉庫調(diào)用安全組件，也支持從中央倉庫調(diào)用開源組件，編碼完成后，代碼提交至軟件版本庫，之后通過Jenkins構(gòu)建持續(xù)集成，并將軟件制品存入制品庫中，等待上線發(fā)布。

SCA開源組件檢測：安全人員可以使用SCA工具對軟件版本庫中的源碼和Jenkins構(gòu)建中生成的二進制文件和容器鏡像對軟件成分進行檢測，發(fā)現(xiàn)漏洞組件和不合規(guī)組件后，告知開發(fā)人員修復至與當前版本差異最小的無漏洞版本。

新漏洞預警：SCA工具通過不斷更新組件漏洞信息獲取新的組件漏洞情報，發(fā)現(xiàn)新漏洞后可以及時預警，定位影響的組件、項目等信息，幫助企業(yè)在最短時間內(nèi)掌握信息系統(tǒng)中的開源組件資產(chǎn)和漏洞情報信息。

軟件供應(yīng)鏈框架

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

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

· Level 1：構(gòu)建過程是完全腳本化或自動化，且能夠基于結(jié)果識別來源源碼；

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

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

· Level 4：所有變更均有雙人評審，且有封閉的、可重復的構(gòu)建過程。

典型的軟件發(fā)布流程如下：

開發(fā)者提交代碼變更到源碼控制管理倉庫（SCM），提交動作觸發(fā)構(gòu)建流程，構(gòu)建服務(wù)接收源代碼并進行編譯，之后編譯打包的軟件包分發(fā)到最終用戶進行使用，或者進入到私服倉庫作為其他項目的依賴包使用。

在SLSA框架中，上圖中的發(fā)布流程對應(yīng)的安全風險如下：

以Level 4為例，在軟件構(gòu)建過程中需要實踐以下4點：

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

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

安全的自動化構(gòu)建流程/環(huán)境：構(gòu)建流程應(yīng)當是完全自動化的，且構(gòu)建環(huán)境應(yīng)該具有隔離性（構(gòu)建過程不受其他構(gòu)建影響）、封閉性（構(gòu)建過程應(yīng)包含所有依賴關(guān)系）、無參化（構(gòu)建結(jié)果只受源代碼影響）和短暫性（每次構(gòu)建都在專門的容器或虛擬機中進行）。

可重復構(gòu)建的流程：相同的源代碼構(gòu)建每次構(gòu)建的結(jié)果總是相同的，并且構(gòu)建流程是可以驗證的。

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

附供應(yīng)鏈安全最佳實踐

英國國家網(wǎng)絡(luò)安全中心（NCSC）提出了供應(yīng)鏈安全管理準則，分為4個部分的12條：

· 理解風險（Understand the risks）

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

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

了解供應(yīng)鏈帶來的安全風險；

· 建立控制（Establish Control）

和供應(yīng)商溝通你的安全需求

為供應(yīng)商設(shè)立和溝通最低安全要求

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

履行你作為供應(yīng)商和客戶的安全責任

在供應(yīng)鏈內(nèi)部提升安全意識

為供應(yīng)鏈提供安全事件支持

· 檢查安排（Check your arrangements）

建立保障措施確保供應(yīng)鏈管理能夠?qū)崿F(xiàn)

· 持續(xù)改進（Continuous improvement）

鼓勵供應(yīng)鏈持續(xù)改進和提升安全能力

與供應(yīng)商建立互信關(guān)系

更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<