前言

隨著 DevSecOps 概念的逐漸推廣和云原生安全概念的快速普及，研發(fā)安全和操作環(huán)境安全現(xiàn)在已經(jīng)變成了近兩年行業(yè)非常熱的詞匯。在研發(fā)安全和應(yīng)急響應(yīng)的日常工作中，每天都會(huì)收到大量的安全風(fēng)險(xiǎn)信息，由于目前在系統(tǒng)研發(fā)的過(guò)程中，開(kāi)源組件引入的比例越來(lái)越高，所以在開(kāi)源軟件治理層面需要投入很多精力。但是由于早期技術(shù)債的問(wèn)題，很多企業(yè)內(nèi)部在整個(gè)研發(fā)流程中對(duì)使用了哪些開(kāi)源組件，這些開(kāi)源組件可能存在嚴(yán)重的安全隱患等相關(guān)的問(wèn)題幾乎是沒(méi)有任何能力去收斂，所以多年前的 SCA(Software Composition Analysis 軟件成分分析)技術(shù)又重出江湖，變成了這一部分風(fēng)險(xiǎn)治理的神器。本文主要探討的范圍是利用 SCA 技術(shù)實(shí)現(xiàn)對(duì)開(kāi)源組件風(fēng)險(xiǎn)治理相關(guān)能力的建設(shè)與落地。

SCA 概念其實(shí)出現(xiàn)很久了，簡(jiǎn)單來(lái)說(shuō)就是針對(duì)現(xiàn)有的軟件系統(tǒng)生成粒度非常細(xì)的 SBOM(Software Bill of Materials 軟件物料單)清單，然后通過(guò)風(fēng)險(xiǎn)數(shù)據(jù)去匹配有沒(méi)有存在風(fēng)險(xiǎn)的組件被引用。目前市面上比較出色的商業(yè)產(chǎn)品有 Synopsys 的 Blackduck 、Snyk 的 SCA 、HP 的 Fortify SCA 等，開(kāi)源產(chǎn)品有國(guó)內(nèi)懸鏡的 OpenSCA 。但是通過(guò)對(duì)這些產(chǎn)品的調(diào)研和分析后發(fā)現(xiàn)，這些產(chǎn)品由于諸如風(fēng)險(xiǎn)數(shù)據(jù)庫(kù)完整度、與現(xiàn)有研發(fā)流程耦合程度、性能和社區(qū)支持不完整等原因，不能很好地融入企業(yè)內(nèi)部的研發(fā)流程，但是這一部分能力在企業(yè)內(nèi)部對(duì)于SDL工作而言又是不可或缺的能力。所以企業(yè)內(nèi)部的信息安全團(tuán)隊(duì)需要結(jié)合業(yè)務(wù)團(tuán)隊(duì)的需求，安全團(tuán)隊(duì)自身對(duì)于風(fēng)險(xiǎn)的理解，企業(yè)內(nèi)部的研發(fā)流程現(xiàn)狀和現(xiàn)有的技術(shù)與數(shù)據(jù)能力、應(yīng)用成本和 ROI 等現(xiàn)狀和問(wèn)題進(jìn)行綜合考慮，打造自己的 SCA 能力，從而幫助業(yè)務(wù)團(tuán)隊(duì)多快好省地解決軟件供應(yīng)鏈層面上的信息安全問(wèn)題，安全團(tuán)隊(duì)也可以更好地對(duì)組件風(fēng)險(xiǎn)問(wèn)題進(jìn)行全局視角下的治理。從上面的內(nèi)容大家也許聽(tīng)出來(lái)了，在企業(yè)內(nèi)部建設(shè) SCA 能力的過(guò)程中會(huì)涉及到很多的產(chǎn)品和運(yùn)營(yíng)方面的問(wèn)題，諸如跨部門協(xié)作、系統(tǒng)穩(wěn)定性、業(yè)務(wù)和安全部門對(duì)于風(fēng)險(xiǎn)的定義不一致等問(wèn)題。本文主要介紹 SCA 能力在企業(yè)內(nèi)部實(shí)際落地的過(guò)程、遇到的問(wèn)題以及對(duì) SCA 技術(shù)的看法和展望，旨在為業(yè)界提供一個(gè)可以參考的解決方案和范本。

安全視角下的研發(fā)風(fēng)險(xiǎn)

在企業(yè)內(nèi)部的信息安全團(tuán)隊(duì)看來(lái)，很多企業(yè)內(nèi)部實(shí)際上在整個(gè)研發(fā)流程當(dāng)中遇到的風(fēng)險(xiǎn)面實(shí)際上是蠻多的，通過(guò)對(duì)于各種攻擊面的梳理和分析之后，實(shí)際上在研發(fā)流程中被經(jīng)常提及的風(fēng)險(xiǎn)主要包含以下三類。

通用漏洞風(fēng)險(xiǎn)

在組件安全層面上，首先遇到的問(wèn)題，也是最容易發(fā)現(xiàn)的問(wèn)題就是漏洞問(wèn)題，造成的影響也十分直觀，可以導(dǎo)致系統(tǒng)因?yàn)閻阂獾睦脤?dǎo)致出現(xiàn)非預(yù)期的功能，進(jìn)一步破壞系統(tǒng)的完整性和可用性。根據(jù) 2021 年 Synopsys 放出的軟件供應(yīng)鏈相關(guān)的數(shù)據(jù)顯示，開(kāi)源代碼倉(cāng)庫(kù)中至少存在一個(gè)漏洞的倉(cāng)庫(kù)占整體開(kāi)源倉(cāng)庫(kù)的比例從 2016 年的 67% 上升到了 84%，至少存在一個(gè)高危漏洞的代碼倉(cāng)庫(kù)占全部倉(cāng)庫(kù)的比例從 2016 年的 53% 上升到了 60%，最高的時(shí)候是 2017 年，這一數(shù)字是 77%。

而根據(jù) 2020 年 Snyk 發(fā)布的另一份開(kāi)源組件與供應(yīng)鏈安全的報(bào)告顯示，漏洞的數(shù)量仍然需要提高警惕，XSS 漏洞仍然占據(jù)數(shù)量榜首，緊隨其后的是命令執(zhí)行類漏洞，這些漏洞會(huì)嚴(yán)重影響系統(tǒng)的穩(wěn)定性。

在上述所羅列出來(lái)的風(fēng)險(xiǎn)當(dāng)中，當(dāng)注意力集中到惡意包(Malicious Packages)上時(shí)，我們可以發(fā)現(xiàn)該類型的風(fēng)險(xiǎn)是 2019 年度上升幅度最快的威脅之一，這也引出了下面的問(wèn)題。也就是軟件供應(yīng)鏈相關(guān)的風(fēng)險(xiǎn)。

供應(yīng)鏈相關(guān)的風(fēng)險(xiǎn)

開(kāi)源組件的生產(chǎn)-構(gòu)建-發(fā)布過(guò)程其實(shí)是與企業(yè)內(nèi)部常規(guī)的系統(tǒng)研發(fā)上線的流程是一致的，簡(jiǎn)單來(lái)說(shuō)可以抽象成下圖中的樣子：

開(kāi)源軟件作者完成代碼編寫后 push 到源代碼管理平臺(tái)(GitHub、碼云、Gitlab私服平臺(tái))等，然后在 CI/CD 平臺(tái)上發(fā)起構(gòu)建編譯打包的流程，在這個(gè)過(guò)程中，CI/CD 平臺(tái)會(huì)從組件依賴平臺(tái)(Sonatype Nexus 私服或是 MVNRepository 官方源)上獲取需要依賴的包，在 CI/CD 完成打包/鏡像封裝過(guò)程后，通過(guò)項(xiàng)目分發(fā)平臺(tái)分發(fā)到生產(chǎn)環(huán)境上，更為現(xiàn)代的方法是直接拉取 Docker 鏡像做部署，完成系統(tǒng)的上線。

這個(gè)過(guò)程看似簡(jiǎn)單，但是實(shí)際上環(huán)節(jié)還是有不少的，我們把每個(gè)環(huán)節(jié)拆解來(lái)看，實(shí)際上每個(gè)環(huán)節(jié)都是會(huì)有很多風(fēng)險(xiǎn)的，如下圖所示：

IDE 插件投毒：為了更高效率地開(kāi)發(fā)軟件，開(kāi)發(fā)人員往往會(huì)在自己的IDE當(dāng)中引入各種各樣的插件來(lái)提升自己的開(kāi)發(fā)體驗(yàn)與效率。這個(gè)是一件非常正常的事情，但是往往軟件開(kāi)發(fā)人員沒(méi)有足夠的安全意識(shí)，導(dǎo)致自己的IDE中可能會(huì)安裝了一些有問(wèn)題的組件，甚至 IDE 本身也出現(xiàn)了供應(yīng)鏈投毒的情況，這種 case 多到數(shù)不勝數(shù)，比較出名的是2021年5月份 Snyk 披露的一份安全報(bào)告中顯示攻擊者在 VSCode 的插件市場(chǎng)發(fā)起了投毒行為，一些有問(wèn)題的擴(kuò)展是“LaTeX Workshop”、“Rainbow Fart”、“在默認(rèn)瀏覽器中打開(kāi)”和“Instant Markdown”，所有這些有問(wèn)題的擴(kuò)展累計(jì)安裝了大約 200 萬(wàn)次，此次事件所造成的影響是非常廣泛的。

提交缺陷代碼：在軟件開(kāi)發(fā)環(huán)節(jié)，開(kāi)發(fā)人員因?yàn)樗健踩庾R(shí)的諸多原因，往往會(huì)在開(kāi)發(fā)過(guò)程中引入漏洞，這本身是一件十分正常的事情，但是對(duì)于開(kāi)源軟件而言，因?yàn)閹缀跏撬腥硕伎梢韵蜷_(kāi)源項(xiàng)目提交代碼，并且通過(guò)審核后就可以merge進(jìn)項(xiàng)目，所以總會(huì)有不懷好意的人故意引入有問(wèn)題的代碼，比較典型的 case 是2021年4月，明尼蘇達(dá)大學(xué) Kangjie Lu 教授帶領(lǐng)的研究團(tuán)隊(duì)因故意向 Linux 引入漏洞，導(dǎo)致整所大學(xué)被禁止參與 Linux 內(nèi)核開(kāi)發(fā)。除開(kāi)道德問(wèn)題，這種風(fēng)險(xiǎn)實(shí)際上有可能因?yàn)閷徍说氖韬鰧?dǎo)致風(fēng)險(xiǎn)直接被引入。

源代碼平臺(tái)被攻陷：其實(shí) Git 平臺(tái)本身由于保護(hù)不當(dāng)，也有極大的概率被攻陷，雖然說(shuō)攻陷GitHub這種平臺(tái)本身不太現(xiàn)實(shí)，但是有很多開(kāi)源項(xiàng)目都是自己搭設(shè)的Git平臺(tái)，再加上一些眾所周知的原因，Git平臺(tái)本身缺乏保護(hù)是一件很大概率發(fā)生的事情，在2021年3月，PHP 的官方 Git 就遇到了類似的case，由于 PHP 官方 Git， PHP 團(tuán)隊(duì)在 git.php.net 服務(wù)器上維護(hù)的 php-src Git 倉(cāng)庫(kù)中被推送了兩個(gè)惡意提交。攻擊者在上游提交了一個(gè)神秘的改動(dòng)，稱其正在"修復(fù)排版"，假裝這是一個(gè)小的排版更正，并且偽造簽名，讓人以為這些提交是由已知的 PHP 開(kāi)發(fā)者和維護(hù)者 Rasmus Lerdorf 和 Nikita Popov 完成的。所以Git平臺(tái)的安全保護(hù)本身也是需要提高重視的。

代碼branch被篡改導(dǎo)致打包結(jié)果不一致：由于開(kāi)源項(xiàng)目的 Git 倉(cāng)庫(kù)是向所有人開(kāi)放的，有些攻擊者會(huì)嘗試新建不同的 branch 植入代碼然后進(jìn)行發(fā)布，這樣雖然編譯過(guò)后的包帶有CI/CD平臺(tái)的簽名，但是仍舊會(huì)引發(fā)嚴(yán)重的安全隱患，早在2019年的 DEFCON 會(huì)議上，就有安全研究員就發(fā)現(xiàn)了WebMin的1.890在默認(rèn)配置中存在了一個(gè)很嚴(yán)重的高危漏洞，1.882 到 1.921 版本的 WebMin 會(huì)受到該漏洞影響。但奇怪的是，從 GitHub 上下載的版本卻未受到影響，影響范圍僅限于從SourceForge下載的特定版本的WebMin，后來(lái)經(jīng)過(guò)調(diào)查后發(fā)現(xiàn)，是代碼倉(cāng)庫(kù)沒(méi)有添加分支保護(hù)機(jī)制出現(xiàn)了問(wèn)題，引發(fā)此類安全風(fēng)險(xiǎn)。

CI/CD 體系被攻陷：在前面如果我們完成了代碼完整性檢測(cè)的話，如果流程沒(méi)有被篡改或者構(gòu)建平臺(tái)運(yùn)行正常，一般情況下出現(xiàn)問(wèn)題的幾率很低，但如果 CI/CD 平臺(tái)和前面的 Git 一樣被惡意篡改或是破壞，結(jié)果必定會(huì)出現(xiàn)安全隱患，SolarWind 事件就是由于這一原因?qū)е碌?，攻擊者?CI/CD 過(guò)程中嵌入了后門，通過(guò)了簽名校驗(yàn)，再通過(guò) OTA 分發(fā)補(bǔ)丁之后導(dǎo)致出現(xiàn)了讓人震驚的供應(yīng)鏈攻擊事件。

不安全組件引入：在依賴引入的過(guò)程中，如果引入了有問(wèn)題的組件，則相當(dāng)于引入了風(fēng)險(xiǎn)，這也是目前最典型的供應(yīng)鏈攻擊手段，通過(guò)我們對(duì)各個(gè)源的安全調(diào)查和分析后發(fā)現(xiàn)，投毒的重災(zāi)區(qū)在 Python 和 NodeJS 技術(shù)棧(一個(gè)原因是因?yàn)榍岸说耐诘V已經(jīng)很成熟，容易被黑產(chǎn)濫用，另外一個(gè)原因是Python的機(jī)器學(xué)習(xí)的庫(kù)相當(dāng)豐富，加上機(jī)器學(xué)習(xí)配套的計(jì)算環(huán)境性能強(qiáng)悍，導(dǎo)致挖礦的收益會(huì)比入侵普通IDC主機(jī)更高)。由于例子相當(dāng)多，在這里就不一一列舉了。

外部 CI/CD 流程構(gòu)建：因?yàn)?CI/CD 平臺(tái)有時(shí)候不能滿足需求，或開(kāi)發(fā)者出于其他因素考量，會(huì)使用非官方的 CI/CD 進(jìn)行構(gòu)建，而是自己上傳打包好的 jar 或者 docker 鏡像來(lái)部署，更有甚者會(huì)同時(shí)把打包工具鏈和源代碼一起打包上傳到容器實(shí)例，然后本地打包(極端情況下，有些“小可愛(ài)”的依賴倉(cāng)庫(kù)都是自己搭建的 Sonatype Nexus 源管理系統(tǒng))。因?yàn)楹芏嚅_(kāi)源軟件的使用者不會(huì)去做 CI/CD 的簽名校驗(yàn)(比如說(shuō)簡(jiǎn)單匹配下 hash)，導(dǎo)致這類攻擊時(shí)有發(fā)生。早在2008年的時(shí)候，亞利桑那大學(xué)的一個(gè)研究團(tuán)隊(duì)就對(duì)包括 APT、YUM 在內(nèi)的 Linux 包管理平臺(tái)進(jìn)行了分析和研究，發(fā)現(xiàn)絕大多數(shù)源都不會(huì)對(duì)包進(jìn)行校驗(yàn)，這些包隨著分發(fā)，造成的安全問(wèn)題也越來(lái)越廣泛。

直接部署有問(wèn)題的包：有些打包好的成品在使用的時(shí)候，因?yàn)闆](méi)有做校驗(yàn)和檢查，導(dǎo)致可能會(huì)部署一些有問(wèn)題的包，最典型的例子是 Sonatype 之前披露的 Web-Broserify 包的事件，雖然這個(gè)包是使用了數(shù)百個(gè)合法軟件開(kāi)發(fā)的，但它會(huì)對(duì)收集目標(biāo)系統(tǒng)的主機(jī)信息進(jìn)行偵查，所以造成了相當(dāng)大規(guī)模的影響。

過(guò)維護(hù)期的組件

在實(shí)際的生產(chǎn)環(huán)境中，有很多的開(kāi)發(fā)者使用的運(yùn)行時(shí)版本、組件版本以及 CI/CD 平臺(tái)版本都是已經(jīng)很久未更新的。雖然說(shuō)站在安全的角度上講，我們希望所有的系統(tǒng)都用上最新版本的組件和中間件，但是事實(shí)情況是，基于業(yè)務(wù)自身的規(guī)劃迭代、大版本改動(dòng)較多容易引發(fā)兼容性問(wèn)題導(dǎo)致升級(jí)遷移成本過(guò)高等諸多原因，使得落地這件事情就變的不是那么容易。為了讓安全性和易用性達(dá)到平衡，企業(yè)內(nèi)部往往會(huì)妥協(xié)到通過(guò)其他手段收斂攻擊面并且建立旁路的感知體系，保證除了安全問(wèn)題可以及時(shí)發(fā)現(xiàn)和止損。但是長(zhǎng)久看來(lái)引入過(guò)時(shí)版本的組件會(huì)引發(fā)諸多問(wèn)題：

維保問(wèn)題：因?yàn)殚_(kāi)源社區(qū)的人力和精力有限，往往只能維護(hù)幾個(gè)比較主要的版本(類似于操作系統(tǒng)中的 LTS 版本，即 Long-Term Support，長(zhǎng)期支持版本是有社區(qū)的長(zhǎng)期支持的，但是非 LTS 版本則沒(méi)有)，所以一旦使用過(guò)時(shí)很久的版本，在安全更新這一部分就會(huì)出現(xiàn)嚴(yán)重的斷層現(xiàn)象，如果出現(xiàn)了高危漏洞，官方不維護(hù)，要么就是自己編寫補(bǔ)丁修復(fù)，要么就是升級(jí)版本達(dá)到長(zhǎng)痛不如短痛的效果，要么就是像一顆DSZD一樣放在那里，祈求攻擊者或者藍(lán)軍的運(yùn)氣差一點(diǎn)。

安全基線不完整：隨著信息安全技術(shù)的發(fā)展和內(nèi)生安全的推動(dòng)，版本越新的安全組件往往會(huì) secure by design，讓研發(fā)安全的要求貫穿整個(gè)研發(fā)設(shè)計(jì)流程。但是早期由于技術(shù)、思路、攻擊面的局限性，這一部分工作往往做了跟沒(méi)做一樣。感觸特別深的兩個(gè)例子一個(gè)是前幾年 APT 組織利用的一個(gè) Office 的 0day 漏洞瞄準(zhǔn)的是 Office 中一個(gè)年久失修的組件，這個(gè)組件可能根本連基本的 GS(棧保護(hù))、DEP(數(shù)據(jù)區(qū)不可執(zhí)行)、ASLR(內(nèi)存地址隨機(jī)化)等現(xiàn)代的代碼安全緩解機(jī)制都沒(méi)有應(yīng)用。熟悉虛擬化漏洞挖掘的同學(xué)們可能知道 QEMU/KVM 環(huán)境中比較大的一個(gè)攻擊面是QEMU模擬出來(lái)的驅(qū)動(dòng)程序，因?yàn)镼EMU/KVM 模擬的驅(qū)動(dòng)很多都是老舊版本，所以會(huì)存在很多現(xiàn)代化的安全緩解技術(shù)沒(méi)有應(yīng)用到這些驅(qū)動(dòng)上面的情況，從而引入了攻擊面。其實(shí)在開(kāi)源軟件的使用過(guò)程中也存在類似的情況，我們統(tǒng)稱為使用不具備完整安全基線的開(kāi)源軟件。

未通過(guò)嚴(yán)謹(jǐn)?shù)陌踩珳y(cè)試：現(xiàn)在的很多開(kāi)源組件提供商諸如Sonatype會(huì)在分發(fā)前進(jìn)行一定程度的安全檢測(cè)，但是時(shí)間越早，檢測(cè)的范圍越小，換句話說(shuō)就是，組件越老出現(xiàn)的問(wèn)題越多。畢竟之前不像現(xiàn)在一樣有好用的安全產(chǎn)品和安全思路，甚至開(kāi)發(fā)的流程也沒(méi)有嵌入安全要求。而這樣就會(huì)導(dǎo)致很多時(shí)候新發(fā)布的版本在修復(fù)了一個(gè)漏洞的同時(shí)又引入了一個(gè)更大的漏洞，導(dǎo)致風(fēng)險(xiǎn)越來(lái)越大，越來(lái)越不可控。

綜上，在安全團(tuán)隊(duì)的視角看來(lái)，風(fēng)險(xiǎn)無(wú)處不在。但是在一個(gè)非安全業(yè)務(wù)的安全公司，往往業(yè)務(wù)對(duì)于風(fēng)險(xiǎn)的理解和要求與安全團(tuán)隊(duì)可能大相逕庭。

業(yè)務(wù)視角下的安全研發(fā)風(fēng)險(xiǎn)

實(shí)際上在業(yè)務(wù)同學(xué)看來(lái)，他們也十分重視信息安全的相關(guān)工作，有些公司的業(yè)務(wù)技術(shù)團(tuán)隊(duì)甚至成立了專門的安全團(tuán)隊(duì)來(lái)協(xié)助研發(fā)同學(xué)處理安全相關(guān)的問(wèn)題。可見(jiàn)業(yè)務(wù)不是排斥安全工作，而是缺乏合理化和可操作的安全指導(dǎo)，導(dǎo)致業(yè)務(wù)同學(xué)不知道我們有什么風(fēng)險(xiǎn)。在實(shí)際的組件風(fēng)險(xiǎn)修復(fù)過(guò)程中，我們也收到了很多業(yè)務(wù)同學(xué)的反饋和吐槽。總結(jié)起來(lái)有以下幾種情況：

兼容性問(wèn)題：在推動(dòng)以版本升級(jí)為主要收斂手段的風(fēng)險(xiǎn)修復(fù)中，業(yè)務(wù)提出最多的質(zhì)疑往往是兼容性問(wèn)題，畢竟穩(wěn)定性對(duì)于業(yè)務(wù)是非常重要的，所以一般情況下我們?cè)谕苿?dòng)升級(jí)的時(shí)候，往往會(huì)推送安全穩(wěn)妥且穩(wěn)定性最高的修復(fù)版本，作為主要的升級(jí)版本。但這種問(wèn)題不是個(gè)例，每次遇到此類型推修的時(shí)候，業(yè)務(wù)都會(huì)問(wèn)到類似問(wèn)題?？紤]到本文篇幅原因，這里就不展開(kāi)講具體的策略和方法。

安全版本的問(wèn)題：和上一個(gè)問(wèn)題類似，業(yè)務(wù)同學(xué)在引入組件的時(shí)候往往也會(huì)考慮安全性問(wèn)題，但業(yè)務(wù)同學(xué)由于缺乏很多安全知識(shí)，導(dǎo)致自己對(duì)于“安全版本“的判斷會(huì)有一定出入，所以業(yè)務(wù)同學(xué)會(huì)把這個(gè)問(wèn)題拋給安全同學(xué)。但是安全團(tuán)隊(duì)也不能100%正確回答這個(gè)問(wèn)題，因?yàn)殚_(kāi)源組件這么多，我們不能像 Google、微軟這種財(cái)大氣粗的公司一樣把市面上所有的組件安全性全都分析一遍，所以一般只能現(xiàn)用現(xiàn)查。這一來(lái)一去，會(huì)拉低這一部分的質(zhì)量和效率。所以這一部分的需求也是重要且很急迫的。

追求“絕對(duì)安全”：有些業(yè)務(wù)同學(xué)會(huì)直接問(wèn)你，我到底該怎么干，我才能安全地用各種組件?話雖直接，但是能夠體現(xiàn)出背后的問(wèn)題——安全的尺度和評(píng)價(jià)標(biāo)準(zhǔn)不夠透明。提升安全的可量化并且追求標(biāo)準(zhǔn)透明也是非常急迫的，考慮到這是一個(gè)運(yùn)營(yíng)的問(wèn)題，在此就不展開(kāi)敘述了。

合規(guī)問(wèn)題：很多業(yè)務(wù)會(huì)不了解開(kāi)源協(xié)議導(dǎo)致不小心違反了開(kāi)源協(xié)議的約束，引發(fā)法務(wù)問(wèn)題。

從實(shí)際情況來(lái)看，業(yè)務(wù)同學(xué)并不是不想做安全，很多時(shí)候是缺乏一個(gè)有效的機(jī)制，告訴他們引入的軟件依賴是否安全，需要完成那些操作和配置才能讓開(kāi)源組件用著安全。作為安全工程師而言，我們需要站在業(yè)務(wù)的立場(chǎng)上去設(shè)身處地想想，這些問(wèn)題是不是真的不能被解決。由于業(yè)務(wù)和安全雙方都有關(guān)于組件安全相關(guān)的需求，恰好 SCA 這項(xiàng)技術(shù)可以很好地滿足業(yè)務(wù)和自身的需求，所以在整個(gè) SCA 建設(shè)的過(guò)程中，我們需要不斷去挖掘這些需求。

SCA 建設(shè)的過(guò)程

SCA 其實(shí)并不是一項(xiàng)很先進(jìn)的技術(shù)，只是在現(xiàn)代的研發(fā)過(guò)程中隨著流程的標(biāo)準(zhǔn)化、組件的豐富化、開(kāi)源社區(qū)的活躍以及開(kāi)發(fā)成本的降低等諸多原因，使得一個(gè)項(xiàng)目中純自己寫的代碼占整個(gè)項(xiàng)目中全部代碼的比例越來(lái)越低了。也就意味著供應(yīng)鏈的問(wèn)題產(chǎn)生的影響會(huì)越來(lái)越大，隨著 DevSecOps 的火爆，重新帶火了 SCA 這一傳統(tǒng)的技術(shù)。

根據(jù)很多企業(yè)內(nèi)部的實(shí)踐以及業(yè)界對(duì)于 SCA 技術(shù)的理解，我們認(rèn)為 SCA 比較核心的功能有以下幾點(diǎn)：

軟件資產(chǎn)的透視：企業(yè)內(nèi)部需要對(duì)所有的應(yīng)用系統(tǒng)引用了哪些組件這件事情有著非常清晰的認(rèn)知，在考慮盡量多的情況下覆蓋絕大多數(shù)的場(chǎng)景(業(yè)務(wù)應(yīng)用系統(tǒng)、Hadoop 作業(yè)等數(shù)據(jù)服務(wù)、Puppet 等運(yùn)維服務(wù)等)，并且研究他們的開(kāi)發(fā)流程，分析哪些階段可以引入 SCA 能力做風(fēng)險(xiǎn)發(fā)現(xiàn)。

風(fēng)險(xiǎn)數(shù)據(jù)的發(fā)現(xiàn)：現(xiàn)在是一個(gè)數(shù)據(jù)爆炸的時(shí)代，安全團(tuán)隊(duì)每天需要關(guān)注的安全風(fēng)險(xiǎn)信息來(lái)源五花八門，但是需要盡可能多地去收集風(fēng)險(xiǎn)相關(guān)的數(shù)據(jù)，并且做上下文整合，使之可以自動(dòng)化和半自動(dòng)化地運(yùn)營(yíng)起來(lái)。但仔細(xì)想一下，除了追求風(fēng)險(xiǎn)數(shù)量，能否更進(jìn)一步追求更強(qiáng)的實(shí)效性，達(dá)到先發(fā)制人的效果?通過(guò)企業(yè)內(nèi)部多年的安全威脅情報(bào)能力建設(shè)，同時(shí)追求實(shí)效性和可用性的雙重SLA是可行的。除此之外，需要關(guān)注的風(fēng)險(xiǎn)不能僅僅局限于漏洞和投毒這兩個(gè)場(chǎng)景，還需要對(duì)開(kāi)源軟件的基線信息也進(jìn)行收集。

風(fēng)險(xiǎn)與資產(chǎn)關(guān)聯(lián)基礎(chǔ)設(shè)施的建設(shè)：以上的兩個(gè)方向是在數(shù)據(jù)維度的需求，考慮 SCA 落地不單單是信息安全部門的事情，實(shí)際落地過(guò)程中需要與業(yè)務(wù)自己的質(zhì)量效率團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)建立良性的互動(dòng)機(jī)制，讓安全能力深入到業(yè)務(wù)，所以需要建設(shè)相關(guān)的基礎(chǔ)設(shè)施去實(shí)現(xiàn)核心API能力的建設(shè)，對(duì)業(yè)務(wù)賦能。雖然聽(tīng)上去很簡(jiǎn)單，但實(shí)際上開(kāi)發(fā)的東西可能是 UDF 函數(shù)，也可能是某些分析服務(wù)的插件，甚至可能是CEP(Complex Event Process復(fù)雜事件處理，一種應(yīng)用于實(shí)時(shí)計(jì)算的分析技術(shù))的規(guī)則。

可視化相關(guān)需求：既然有了風(fēng)險(xiǎn)，安全團(tuán)隊(duì)及業(yè)務(wù)相關(guān)團(tuán)隊(duì)的同學(xué)除了自己知道之外，還需要讓負(fù)責(zé)系統(tǒng)開(kāi)發(fā)相關(guān)同學(xué)也知道風(fēng)險(xiǎn)的存在，并且要及時(shí)給出解決方案，指導(dǎo)業(yè)務(wù)完成修復(fù)，同時(shí)安全團(tuán)隊(duì)也需要通過(guò)獲取運(yùn)營(yíng)數(shù)據(jù)知道風(fēng)險(xiǎn)的修復(fù)進(jìn)度。

正所謂羅馬不是一日建成的，雖然現(xiàn)在確定了 SCA 建設(shè)需求和建設(shè)的方向，但是落地起來(lái)的話仍然需要分階段完成。正如建設(shè)其他的安全子系統(tǒng)一樣，安全團(tuán)隊(duì)需要按照從基礎(chǔ)數(shù)據(jù)/SOP 建設(shè)到平臺(tái)化系統(tǒng)化的建設(shè)來(lái)完成整個(gè) SCA 能力的落地。所以在實(shí)際操作過(guò)程中，應(yīng)該將整體建設(shè)分成三個(gè)階段進(jìn)行：

第一階段：數(shù)據(jù)盤點(diǎn)與收集，在項(xiàng)目建設(shè)前期，信息安全團(tuán)隊(duì)?wèi)?yīng)當(dāng)和企業(yè)內(nèi)部的基礎(chǔ)架構(gòu)相關(guān)的團(tuán)隊(duì)，完成企業(yè)內(nèi)部基礎(chǔ)組件的數(shù)據(jù)資產(chǎn)盤點(diǎn)，旨在從基礎(chǔ)技術(shù)和信息安全的視角實(shí)現(xiàn)對(duì)研發(fā)技術(shù)棧、研發(fā)流程鏈路的摸排，在合適的位置進(jìn)行數(shù)據(jù)卡點(diǎn)獲取相關(guān)數(shù)據(jù)，完成對(duì)資產(chǎn)數(shù)據(jù)的采集。另一方面，信息安全部門在現(xiàn)有的威脅情報(bào)經(jīng)驗(yàn)和數(shù)據(jù)上，對(duì)組件數(shù)據(jù)進(jìn)行數(shù)據(jù)封裝和整合，建立一個(gè)單獨(dú)的開(kāi)源組件風(fēng)險(xiǎn)數(shù)據(jù)庫(kù)，旨在收集來(lái)自于全量互聯(lián)網(wǎng)上披露的風(fēng)險(xiǎn)，方便與后面的資產(chǎn)數(shù)據(jù)進(jìn)行聯(lián)動(dòng)。

第二階段：SOP(Standard Operating Procedure，標(biāo)準(zhǔn)運(yùn)營(yíng)流程)和概念驗(yàn)證建設(shè)，信息安全團(tuán)隊(duì)通過(guò)自己的漏洞修復(fù)經(jīng)驗(yàn)進(jìn)行SOP的固化，通過(guò)不斷地調(diào)優(yōu)，完成一個(gè)通用的漏洞修復(fù) SOP，通過(guò)實(shí)際的演練和概念驗(yàn)證(PoC，即Proof-of-Concept)證明該 SOP 可以在現(xiàn)有的技術(shù)條件下很好地完成風(fēng)險(xiǎn)修復(fù)這一部分工作。同時(shí)結(jié)合 SOP，對(duì)之前收集的資產(chǎn)數(shù)據(jù)和風(fēng)險(xiǎn)數(shù)據(jù)進(jìn)行查漏補(bǔ)缺，完成對(duì)數(shù)據(jù)和數(shù)據(jù)鏈路的校驗(yàn)工作，保證系統(tǒng)高可用。在這個(gè)階段，SCA 的服務(wù)提供方需要開(kāi)放部分的核心API給部分業(yè)務(wù)的質(zhì)量效率團(tuán)隊(duì)，幫助進(jìn)行測(cè)試并收集使用反饋，讓其融入自己的風(fēng)險(xiǎn)治理環(huán)節(jié)。

第三階段：平臺(tái)化及配套穩(wěn)定工作的建設(shè)：當(dāng) SOP 初步成型并且完成了概念驗(yàn)證之后，應(yīng)當(dāng)需要建設(shè)對(duì)應(yīng)的平臺(tái)和子系統(tǒng)，讓這一部分工作脫離手動(dòng)統(tǒng)計(jì)，使其接近 100% 線上化。得益于內(nèi)部 SOC 的模塊化設(shè)計(jì)，可以在現(xiàn)有的平臺(tái)上輕松構(gòu)建出 SCA 相關(guān)的子系統(tǒng)，完成能力的數(shù)據(jù)。針對(duì)終端用戶可視化風(fēng)險(xiǎn)這一問(wèn)題，SCA 子系統(tǒng)會(huì)提供核心的 APIs 給面向研發(fā)同學(xué)端的 SOC 完成風(fēng)險(xiǎn)信息的同步。為了保證服務(wù)的高可用，后續(xù)還會(huì)建設(shè)配套的數(shù)據(jù)鏈路檢查機(jī)制，不斷完善數(shù)據(jù)可用性。

一些比較重要的工作如上圖所示。三個(gè)階段完成之后，SCA 的能力大概就建設(shè)好了，但在建設(shè)過(guò)程中，安全團(tuán)隊(duì)需要考慮很多東西。筆者個(gè)人認(rèn)為如果說(shuō)安全廠商的安全產(chǎn)品和服務(wù)可以被認(rèn)為是問(wèn)題解決的分子的話，甲方安全團(tuán)隊(duì)的工作更多的是做大做全分母，要把各種情況都考慮面面俱到，才能保證風(fēng)險(xiǎn)不被遺漏。

首先來(lái)說(shuō)在資產(chǎn)建設(shè)方面，企業(yè)內(nèi)部的安全團(tuán)隊(duì)、質(zhì)量效率團(tuán)隊(duì)以及數(shù)據(jù)平臺(tái)團(tuán)隊(duì)等存在研發(fā)流程的技術(shù)團(tuán)隊(duì)，需要配合完成自己所轄的 CI/CD 系統(tǒng)數(shù)據(jù)和數(shù)據(jù)服務(wù)構(gòu)建數(shù)據(jù)的采集工作，同時(shí)也在為IDE插件團(tuán)隊(duì)提供了 SCA 的 API，完成了從代碼開(kāi)發(fā)環(huán)節(jié)到應(yīng)用上線環(huán)節(jié)的數(shù)據(jù)采集。但是我們?cè)趹?yīng)用這一部分?jǐn)?shù)據(jù)之后發(fā)現(xiàn)了很多問(wèn)題，除開(kāi)數(shù)據(jù)本身質(zhì)量和準(zhǔn)確度不談(不談不代表重要，相反這一部分很重要，后面會(huì)介紹這一部分)，按照前面提到的場(chǎng)景，還會(huì)有很多額外場(chǎng)景，比如說(shuō)業(yè)務(wù)在灰度了一部分之后就忘掉了還沒(méi)灰度完，導(dǎo)致一個(gè)服務(wù)下面只修復(fù)了一部分機(jī)器，再比如有很多的“小可愛(ài)”會(huì)繞過(guò)企業(yè)本身的 CI/CD 流程進(jìn)行部署操作(有些甚至還是自己人)。為了考慮到這些額外的情況，我們應(yīng)該從主機(jī)的粒度重新考慮這件事情，也就是說(shuō)通過(guò)主機(jī)實(shí)例(docker容器、虛擬機(jī)、物理機(jī))本地的 HIDS agent ，完成文件信息、進(jìn)程信息、環(huán)境變量、shell-log 等信息的分析，確定主機(jī)實(shí)例修復(fù)完畢了。這樣我們就建立了一個(gè)構(gòu)建鏈路-主機(jī)維度的數(shù)據(jù)正反校驗(yàn)機(jī)制，理論上講主機(jī)端 HIDS agent 覆蓋度和存活率都達(dá)標(biāo)的話，我們幾乎可以得到一份詳細(xì)的軟件資產(chǎn)的數(shù)據(jù)(當(dāng)然數(shù)據(jù)不準(zhǔn)、延遲這些問(wèn)題是肯定還會(huì)有的)，詳細(xì)的落地核心工程和結(jié)構(gòu)關(guān)系看下圖：

在數(shù)據(jù)確定覆蓋的差不多的時(shí)候，我們需要通過(guò)數(shù)據(jù)總線傳遞給數(shù)據(jù)倉(cāng)庫(kù)和計(jì)算引擎，完成數(shù)據(jù)的交叉和分析工作，得出的結(jié)果便是存在哪些風(fēng)險(xiǎn)和風(fēng)險(xiǎn)進(jìn)度。在這里實(shí)時(shí)引擎一方面需要承擔(dān)增量資產(chǎn)數(shù)據(jù)的分析，另一方面也會(huì)保存很多聚合的 CEP 規(guī)則進(jìn)行分析。離線引擎則是完成存量風(fēng)險(xiǎn)的周期性發(fā)現(xiàn)和治理工作。

討論完資產(chǎn)數(shù)據(jù)的采集之后，我們來(lái)談?wù)擄L(fēng)險(xiǎn)數(shù)據(jù)的收集。早在威脅情報(bào)體系化建設(shè)階段，組件漏洞情報(bào)就作為基礎(chǔ)安全情報(bào)應(yīng)用場(chǎng)景下漏洞情報(bào)的一個(gè)子集一直存在，但由于之前局限于“漏洞=風(fēng)險(xiǎn)”的觀念，導(dǎo)致實(shí)際執(zhí)行過(guò)程中只存放了組件漏洞相關(guān)的風(fēng)險(xiǎn)信息，在綜合評(píng)估完現(xiàn)有的需求和實(shí)際情況之后，發(fā)現(xiàn)當(dāng)前組件漏洞數(shù)據(jù)，只能承擔(dān)一部分研發(fā)安全風(fēng)險(xiǎn)的治理工作，而像對(duì)于供應(yīng)鏈投毒、開(kāi)源組件基線情況等其他類型的風(fēng)險(xiǎn)數(shù)據(jù)，由于當(dāng)時(shí)還沒(méi)有數(shù)據(jù)能夠提供成熟的能力輸出給業(yè)務(wù)方使用，經(jīng)歷過(guò)充分的討論和調(diào)研之后，決定將組件相關(guān)的漏洞數(shù)據(jù)獨(dú)立出來(lái)，并且新增采集供應(yīng)鏈安全的其他風(fēng)險(xiǎn)數(shù)據(jù)，重新建立一個(gè)組件安全相關(guān)的數(shù)據(jù)庫(kù)，完成風(fēng)險(xiǎn)數(shù)據(jù)的存儲(chǔ)和應(yīng)用。通過(guò)結(jié)合自身威脅情報(bào)的實(shí)踐和業(yè)界關(guān)于組件風(fēng)險(xiǎn)收集的最佳實(shí)踐來(lái)看，打算從5個(gè)維度實(shí)現(xiàn)對(duì)組件相關(guān)的風(fēng)險(xiǎn)進(jìn)行收集和存儲(chǔ)：

NVD/CNVD/GitHub-GHSA 等通用漏洞數(shù)據(jù)庫(kù)：這個(gè)是基本操作，旨在收集漏洞風(fēng)險(xiǎn)，結(jié)合漏洞實(shí)際情況進(jìn)行人工和研判。

開(kāi)源組件提供商的 Jira、Commit、Release 和 Bugzilia 等 Pull-Request 相關(guān)的數(shù)據(jù)：通過(guò)獲取相關(guān)的數(shù)據(jù)，結(jié)合自研的 NLP(Natural Language Process，自然語(yǔ)言分析)分析引擎對(duì)內(nèi)容進(jìn)行傾向性判斷，過(guò)濾并輸出安全相關(guān)的信息，然后組織人工或自動(dòng)化研判，通過(guò)實(shí)踐發(fā)現(xiàn)可以大幅度提前發(fā)現(xiàn)風(fēng)險(xiǎn)(筆者在 ISC2019 上曾經(jīng)闡述過(guò)風(fēng)險(xiǎn)發(fā)現(xiàn)前置的必要性和落地經(jīng)驗(yàn))。

組件專用風(fēng)險(xiǎn)庫(kù)：經(jīng)過(guò)我們對(duì)于漏洞數(shù)據(jù)相關(guān)的調(diào)研，諸如 Github 和 Snyk 這些機(jī)構(gòu)會(huì)有專門的組件風(fēng)險(xiǎn)庫(kù)對(duì)外提供，通過(guò)獲取并分析這些信息，經(jīng)過(guò)加工后可以得到可用性極高的組件風(fēng)險(xiǎn)庫(kù)，可按需研判。

軟件風(fēng)險(xiǎn)相關(guān)的新聞資訊和 RSS 訂閱：這類源主要是解決 0day 和被 APT 組織在野利用等特殊披露的漏洞，同 Pull-Request 數(shù)據(jù)一樣，該類型的絕大部分風(fēng)險(xiǎn)數(shù)據(jù)都是需要通過(guò)NLP分析引擎進(jìn)行情報(bào)數(shù)據(jù)分析，進(jìn)一步進(jìn)行情感推斷后才達(dá)到可用標(biāo)準(zhǔn)。

手動(dòng)錄入：也是常規(guī)操作，雖然采集了很多類型的風(fēng)險(xiǎn)，但的確受限于供應(yīng)鏈攻擊的多種多樣和發(fā)展，所以不可能考慮的面面俱到，所以仍舊需要手動(dòng)接口補(bǔ)充需要運(yùn)營(yíng)的風(fēng)險(xiǎn)。但安全團(tuán)隊(duì)仍希望將手動(dòng)錄入的風(fēng)險(xiǎn)占全部風(fēng)險(xiǎn)的比例，控制到一個(gè)合理的范圍，保證這部分能力不會(huì)因?yàn)檫\(yùn)營(yíng)人員的問(wèn)題(如經(jīng)驗(yàn)不足、離職等)而導(dǎo)致能力的閃崩性缺失。

通過(guò)上面的信息，我們發(fā)現(xiàn)這里面絕大部分?jǐn)?shù)據(jù)都是非結(jié)構(gòu)化的，換句話說(shuō)就是不可以直接拿來(lái)使用，需要處理(異構(gòu)數(shù)據(jù)、自然語(yǔ)言數(shù)據(jù))后才可以使用，所以我們?cè)谔幚頃r(shí)會(huì)引入 NLP 分析引擎并且對(duì)漏洞風(fēng)險(xiǎn)數(shù)據(jù)打標(biāo)后(主要工作是添加 RepoID 用來(lái)和資產(chǎn)數(shù)據(jù)聯(lián)動(dòng))，才可以向下傳遞給數(shù)據(jù)引擎和 APIs 。(從威脅情報(bào)數(shù)據(jù)建設(shè)的角度來(lái)看，2019 年前后，基礎(chǔ)安全相關(guān)的威脅情報(bào)實(shí)現(xiàn)了結(jié)構(gòu)情報(bào)和非結(jié)構(gòu)情報(bào)約為 1:1 ，現(xiàn)在非結(jié)構(gòu)的情報(bào)數(shù)據(jù)遠(yuǎn)高于結(jié)構(gòu)化的情報(bào)數(shù)據(jù)，這也越來(lái)越接近于設(shè)計(jì)的目標(biāo))，具體的落地核心工作內(nèi)容和關(guān)系結(jié)構(gòu)如下圖所示：

在風(fēng)險(xiǎn)信息處置環(huán)節(jié)，實(shí)時(shí)計(jì)算引擎和離線引擎的作用與資產(chǎn)數(shù)據(jù)處理的時(shí)候是一致的，主要解決增量和存量的問(wèn)題。同時(shí)考慮到業(yè)務(wù)自身會(huì)有自助排查風(fēng)險(xiǎn)的需求，SCA 平臺(tái)也會(huì)提供一些核心的 APIs 給業(yè)務(wù)方。

在開(kāi)始著手建設(shè)這些數(shù)據(jù)相關(guān)的基礎(chǔ)設(shè)施時(shí)，需要提出一些建設(shè)指標(biāo)，防止一些關(guān)鍵的功能因?yàn)槠脚_(tái)本身的問(wèn)題，導(dǎo)致服務(wù)大規(guī)模不可用。在資產(chǎn)方面，目前資產(chǎn)數(shù)據(jù)庫(kù)的基礎(chǔ)設(shè)施可以支持 TB 級(jí)別資產(chǎn)數(shù)據(jù)的檢索能力，返回時(shí)間不超過(guò) 100 毫秒;而在風(fēng)險(xiǎn)數(shù)據(jù)建設(shè)方面，目前覆蓋了共計(jì) 10 個(gè)技術(shù)棧(包含主流的 Maven/Gradle、PyPi、NPM、SPM、APT/Yum、CocoaPods 在內(nèi))共計(jì)約 59 萬(wàn)條風(fēng)險(xiǎn)數(shù)據(jù)，更新周期在兩小時(shí)以內(nèi)，通過(guò)計(jì)算引擎可以和資產(chǎn)數(shù)據(jù)進(jìn)行快速匹配，節(jié)省了將近 95% 的受影響資產(chǎn)排查時(shí)間，大大提升了運(yùn)營(yíng)效率。

在匹配規(guī)則建設(shè)方面，因?yàn)閿?shù)據(jù)來(lái)源較多且雜亂，通過(guò)自研的NLP分析引擎進(jìn)行大規(guī)模的訓(xùn)練和處理數(shù)據(jù)之后，可以統(tǒng)一到一個(gè)比較固定的數(shù)據(jù)結(jié)構(gòu)里面，在打標(biāo)處理后可以實(shí)現(xiàn)和資產(chǎn)數(shù)據(jù)的高效聯(lián)動(dòng)。鑒于 NLP 模型的訓(xùn)練過(guò)程和訓(xùn)練方法不屬于 SCA 建設(shè)過(guò)程中比較重要的技術(shù)，所以本文中不會(huì)展開(kāi)敘述詳細(xì)的訓(xùn)練過(guò)程和情感推斷訓(xùn)練過(guò)程。除了資產(chǎn)信息關(guān)聯(lián)之外，風(fēng)險(xiǎn)數(shù)據(jù)庫(kù)可以同時(shí)實(shí)現(xiàn)對(duì) CVSS(即 Common Vulnerability Scoring System，即通用脆弱性評(píng)分系統(tǒng))的匹配，及時(shí)推送滿足 CVSS 影響范圍(這里不是指 CVSS 分?jǐn)?shù)，而是指 CVSS 的描述表達(dá)式)的漏洞信息，提醒安全運(yùn)營(yíng)的同學(xué)關(guān)注相關(guān)風(fēng)險(xiǎn)并及時(shí)進(jìn)行研判。

對(duì)于風(fēng)險(xiǎn)的基線數(shù)據(jù)，目前基線建設(shè)數(shù)據(jù)沒(méi)有一個(gè)相對(duì)完整的參考標(biāo)準(zhǔn)，但是 Google 推動(dòng)成立的 OpenSSF基金會(huì)(Open Source Security Foundation，在 Google 等互聯(lián)網(wǎng)企業(yè)和美國(guó)政府的推動(dòng)下成立的開(kāi)源組件安全基金會(huì))在 2021 年下旬發(fā)布的 ScoreCard 功能是一個(gè)很好的參考標(biāo)準(zhǔn)，結(jié)合同樣是 OpenSSF 推出的 AllStar 基線檢測(cè)工具，可以完美補(bǔ)充組件基線相關(guān)的數(shù)據(jù)。

SCA 建設(shè)中遇到的問(wèn)題

在 SCA 建設(shè)過(guò)程中，實(shí)際上并不是一帆風(fēng)順的，總結(jié)一下困難的地方，有以下幾個(gè)方面：

漏洞-資產(chǎn)關(guān)聯(lián)規(guī)則缺乏一個(gè)成熟且有效的行業(yè)標(biāo)準(zhǔn)：在 SCA 領(lǐng)域，目前沒(méi)有一個(gè)成熟的可以匹敵 NVD 相關(guān)的生態(tài)環(huán)境，在 NVD 體系下，有用來(lái)描述漏洞信息的 CVE ，有描述資產(chǎn)影響范圍的 CPE(Common Product Enumunation)，有描述攻擊路徑的 CAPEC(Common Attack Pattern Enumeration and Classification)，還有描述風(fēng)險(xiǎn)類型的 CWE(Common Weakness Enumunation)，但是在組件安全領(lǐng)域，由于各家公司的基礎(chǔ)設(shè)施建設(shè)成熟度和技術(shù)選型差異巨大，所以沒(méi)有一個(gè)可用的完整生態(tài)可以做到開(kāi)箱即用，所以我們需要基于現(xiàn)有的技術(shù)架構(gòu)和基礎(chǔ)設(shè)施來(lái)設(shè)計(jì)自己的規(guī)則，同時(shí)推廣這套標(biāo)準(zhǔn)在安全運(yùn)營(yíng)工作中落地。

數(shù)據(jù)質(zhì)量與數(shù)據(jù)鏈路的可靠性：數(shù)據(jù)質(zhì)量和可用問(wèn)題是自打立項(xiàng)開(kāi)始一直到后期運(yùn)營(yíng)都會(huì)出現(xiàn)的問(wèn)題，問(wèn)題可能來(lái)自于上游采集邏輯不完備或采集錯(cuò)了的原因，還有數(shù)據(jù)鏈路不穩(wěn)定導(dǎo)致寫入計(jì)算引擎出現(xiàn)大批量丟失的問(wèn)題，還有數(shù)據(jù)鏈路沒(méi)有檢查機(jī)制導(dǎo)致不知道具體問(wèn)題出在哪里，甚至由于使用的數(shù)據(jù)分析技術(shù)棧的原因，導(dǎo)致打過(guò)來(lái)的數(shù)據(jù)是錯(cuò)亂的，錯(cuò)亂的數(shù)據(jù)有可能會(huì)影響CEP規(guī)則的準(zhǔn)確性和有效性。這當(dāng)中的有些問(wèn)題不是偶發(fā)的，甚至有些問(wèn)題是在真實(shí)應(yīng)用的場(chǎng)景下仍舊會(huì)高頻出現(xiàn)，所以建立一個(gè)長(zhǎng)效的數(shù)據(jù)撥測(cè)機(jī)制和數(shù)據(jù)污點(diǎn)追蹤能力是必要且必須的。

風(fēng)險(xiǎn)數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)與準(zhǔn)確度：由于在風(fēng)險(xiǎn)數(shù)據(jù)中引入了過(guò)多的來(lái)源，且大量引入了機(jī)器學(xué)習(xí)和NLP技術(shù)把非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換成結(jié)構(gòu)化數(shù)據(jù)，考慮到模型訓(xùn)練的精度、訓(xùn)練樣本數(shù)據(jù)、訓(xùn)練網(wǎng)絡(luò)等問(wèn)題，導(dǎo)致平臺(tái)提取出來(lái)的漏洞信息很多時(shí)候會(huì)有一定的出入，并且由于風(fēng)險(xiǎn)情報(bào)數(shù)據(jù)比較依賴上下文和實(shí)效性，所以需要在各方面做取舍，這個(gè)問(wèn)題其實(shí)和數(shù)據(jù)的問(wèn)題一樣，不是一朝一夕能解決的，需要大量的實(shí)踐運(yùn)營(yíng)和撥測(cè)機(jī)制case by case地去推動(dòng)解決。

CI/CD管制與非標(biāo)準(zhǔn)資產(chǎn)的治理：這一方面實(shí)際上與 SCA 落地的關(guān)系不是很大，但是拿出來(lái)的原因是 SCA 本身是一個(gè)需要強(qiáng)關(guān)聯(lián)研發(fā)流程的能力，好的 SCA 平臺(tái)除了可以提供標(biāo)準(zhǔn)化的APIs和GUI讓用戶快捷操作，同時(shí)也需要兼容非標(biāo)準(zhǔn)的發(fā)布流程和上線標(biāo)準(zhǔn)，這就是為什么除了主要的幾個(gè)技術(shù)棧之外仍舊覆蓋了一些偏小眾的技術(shù)棧，如C#/Powershell的NuGet、ErLang的Hex包管管理等。

資產(chǎn)透視深度：這一部分其實(shí)是 SCA 核心能力的體現(xiàn)，從理論上講，SCA 是有能力分析諸如FatJar這種開(kāi)源組件嵌套的jar包，但實(shí)際上受制于數(shù)據(jù)質(zhì)量和技術(shù)能力，往往無(wú)法分析到一個(gè)非常細(xì)的粒度，所以這一部分需要去設(shè)計(jì)一個(gè)MTI(maximum tolerate index在這里表示可接受的最粗分析粒度)指標(biāo)去指導(dǎo)相關(guān)的設(shè)計(jì)。

SCA 技術(shù)未來(lái)的展望

在建設(shè)過(guò)程中，我們參考了很多公司和商業(yè)產(chǎn)品對(duì)于組件風(fēng)險(xiǎn)分析和治理的最佳實(shí)踐，翻閱了大量與軟件成分分析技術(shù)以及軟件供應(yīng)鏈安全治理相關(guān)的論文文獻(xiàn)、公開(kāi)的專利以及企業(yè)的博客。其中 OpenSSF 基金會(huì)的一些研究成果讓人印象深刻。在2021年6月份 OpenSSF 發(fā)布 SLSA (Supply chain Levels for Software Artifacts，即軟件供應(yīng)鏈安全等級(jí))之后，圍繞 SLSA 這一套標(biāo)準(zhǔn)陸續(xù)發(fā)布了很多有助于我們分析的數(shù)據(jù)服務(wù)和產(chǎn)品，比如準(zhǔn) SCA 產(chǎn)品 Open Source Insight，漏洞風(fēng)險(xiǎn)庫(kù) OSV(Open Source Vulnerabilities，開(kāi)源組件風(fēng)險(xiǎn)數(shù)據(jù))，軟件安全基線檢查工具 AllStar 和 ScoreCard，開(kāi)源組件風(fēng)險(xiǎn)獎(jiǎng)勵(lì)計(jì)劃 SOS Rewards(可以理解為是開(kāi)源組件的漏洞獎(jiǎng)勵(lì)計(jì)劃)。可以初步看到未來(lái) SCA 的建設(shè)路線一定是三個(gè)方向：追求足夠細(xì)粒度的資產(chǎn)和風(fēng)險(xiǎn)透視能力，風(fēng)險(xiǎn)的主動(dòng)識(shí)別能力和開(kāi)源軟件的基線檢查能力。換句話說(shuō)，SCA如果想做到足夠有效，需要覆蓋從軟件開(kāi)發(fā)到上線的所有環(huán)節(jié)，包括代碼完整性、流程完整性和基線巡檢功能，都會(huì)需要 SCA 的核心能力。

除了 SCA 提供的風(fēng)險(xiǎn)透視能力，在整個(gè)DevSecOps環(huán)節(jié)，安全團(tuán)隊(duì)、質(zhì)量效率團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)需要非常默契的配合，大家各司其職共同解決研發(fā)方面的風(fēng)險(xiǎn)，在這其中，安全團(tuán)隊(duì)能夠提供的，除了風(fēng)險(xiǎn)數(shù)據(jù)和修復(fù)建議之外，還需要提供一些對(duì)應(yīng)的基礎(chǔ)設(shè)施幫助業(yè)務(wù)團(tuán)隊(duì)更高效地處置風(fēng)險(xiǎn)。擴(kuò)展到整個(gè)開(kāi)源軟件風(fēng)險(xiǎn)治理方面，也可以給大家一個(gè) cheatsheet 做參考。

當(dāng)然想要做到以上所有的項(xiàng)目，實(shí)際上對(duì)于企業(yè)的基礎(chǔ)架構(gòu)和基礎(chǔ)設(shè)施有一定的要求，但好在目前開(kāi)源社區(qū)對(duì)于供應(yīng)鏈安全治理提供了一些安全的解決方案，諸如國(guó)外由 OpenSSF 或者商業(yè)公司牽頭設(shè)計(jì)開(kāi)發(fā)的一系列工具鏈，如 ChainGuard.dev，SigStore，Anchore 等，當(dāng)然國(guó)內(nèi)也有很多優(yōu)秀的開(kāi)源解決方案?？梢栽谶M(jìn)行一定修改之后，集成到現(xiàn)有的基礎(chǔ)架構(gòu)中。

考慮到安全的對(duì)抗屬性在里面，SCA 工具如果融合進(jìn)企業(yè)內(nèi)的研發(fā)流程中，必然會(huì)引發(fā)很多對(duì)抗 SCA 檢測(cè)的路子，況且在調(diào)研過(guò)程和實(shí)際處置過(guò)程中，繞過(guò)固有研發(fā)流程的情況是比較常見(jiàn)的，所以后續(xù)在繼續(xù)建設(shè) SCA 能力的過(guò)程中會(huì)逐步加入對(duì)抗的檢測(cè)和加固，防止漏網(wǎng)之魚(yú)。

結(jié)語(yǔ)

以上為在整個(gè) SCA 能力建設(shè)過(guò)程中的一些想法和實(shí)踐，在建設(shè) SCA 能力的過(guò)程中，通過(guò)與各團(tuán)隊(duì)的協(xié)同工作和溝通，了解了很多業(yè)務(wù)對(duì)于組件安全方面的想法和真實(shí)需求，通過(guò)需求得出需要建設(shè)的能力，在技術(shù)方案落地中，企業(yè)內(nèi)部部署的很多安全產(chǎn)品，諸如HIDS Agent和RASP等，可以從主機(jī)的角度去反向驗(yàn)證建設(shè)的過(guò)程是否正確。SCA 能力的落地離不開(kāi)安全團(tuán)隊(duì)與業(yè)務(wù)團(tuán)隊(duì)的配合。實(shí)際上在 SCA 的建設(shè)過(guò)程中，我們?nèi)绻偻顚哟稳タ?，?huì)發(fā)現(xiàn)諸如閉源軟件、開(kāi)源軟件的跨架構(gòu)、跨編譯器的識(shí)別、其他載體(比如容器鏡像、軟件成品)的安全分析等，這些技術(shù)挑戰(zhàn)對(duì)于實(shí)際企業(yè)內(nèi)落地 SCA 能力而言還是蠻高的，考慮到目前的解決方案還停留在 PoC 階段，故不在本文中提及。

如果拋開(kāi)整個(gè)落地的過(guò)程，考慮到各家在基礎(chǔ)設(shè)施、核心技術(shù)棧、主機(jī)信息監(jiān)控能力的參差不齊，所以必定會(huì)有不能落地的地方。而站在安全服務(wù)提供商的角度上看，SCA 相關(guān)的產(chǎn)品未來(lái)建設(shè)的過(guò)程中可能需要更加輕量化和開(kāi)放協(xié)同化。所謂輕量化，是指產(chǎn)品的核心功能可以在脫離基礎(chǔ)設(shè)施多種多樣的前提下，能夠穩(wěn)定高效的去提供核心能力，做到很好地與客戶的研發(fā)流程完美銜接，從調(diào)研結(jié)果來(lái)看，目前市面上所有的 SCA 產(chǎn)品，基本上都存在一個(gè)架構(gòu)設(shè)計(jì)比較重的問(wèn)題，不能很好去融入現(xiàn)有的CI/CD流程。所謂開(kāi)放協(xié)同化是指，可以通過(guò)多種方式去和其他的安全產(chǎn)品和安全能力提供數(shù)據(jù)的共享機(jī)制，實(shí)現(xiàn)與其他安全設(shè)備在數(shù)據(jù)上的聯(lián)動(dòng)，互相補(bǔ)齊對(duì)應(yīng)的風(fēng)險(xiǎn)發(fā)現(xiàn)能力，做到簡(jiǎn)潔和高效。

以上是我們對(duì) SCA 能力建設(shè)過(guò)程當(dāng)中的想法。