1. 前言

SCA 概念出現(xiàn)其實(shí)很久了。簡(jiǎn)單來說，就是針對(duì)現(xiàn)有的軟件系統(tǒng)生成粒度非常細(xì)的 SBOM（Software Bill of Materials 軟件物料單）清單，然后通過?險(xiǎn)數(shù)據(jù)去匹配有沒有存在?險(xiǎn)組件被引用。目前，市面上比較出色的商業(yè)產(chǎn)品包括 Synopsys 的 Blackduck 、Snyk 的 SCA 、HP 的 Fortify SCA 等，開源產(chǎn)品包括國內(nèi)懸鏡的 OpenSCA 。

但是，通過對(duì)這些產(chǎn)品調(diào)研和分析后我們發(fā)現(xiàn)，它們由于諸如?險(xiǎn)數(shù)據(jù)庫完整度、與現(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ì)于?險(xiǎn)的理解，企業(yè)內(nèi)部的研發(fā)流程現(xiàn)狀，以及現(xiàn)有的技術(shù)與數(shù)據(jù)能力、應(yīng)用成本和 ROI 等現(xiàn)狀和問題進(jìn)行綜合考慮，打造屬于自己的 SCA 能力，從而幫助業(yè)務(wù)團(tuán)隊(duì)多、快、好、省地解決軟件供應(yīng)鏈層面上的信息安全問題，安全團(tuán)隊(duì)也可以更好地對(duì)組件?險(xiǎn)問題實(shí)現(xiàn)全局的治理。

從上述的內(nèi)容可以得知，在企業(yè)內(nèi)部建設(shè) SCA 能力的過程中，會(huì)涉及到很多的產(chǎn)品和運(yùn)營方面的問題，諸如跨部?協(xié)作、系統(tǒng)穩(wěn)定性、業(yè)務(wù)和安全部?對(duì)于?險(xiǎn)的定義不一致等問題。本文主要介紹 SCA 能力在企業(yè)內(nèi)部實(shí)際落地的過程、遇到的問題以及對(duì) SCA 技術(shù)的看法和展望，希望可以為業(yè)界同仁提供一個(gè)可以參考的解決方案和范本。

2. 安全視?下的研發(fā)?險(xiǎn)

從企業(yè)內(nèi)部的信息安全團(tuán)隊(duì)的視角看來，企業(yè)內(nèi)部在整個(gè)研發(fā)流程當(dāng)中遇到的?險(xiǎn)點(diǎn)還是比較多的，通過對(duì)于各種攻擊面的梳理和分析之后，我們?cè)谘邪l(fā)流程中被經(jīng)常提及的?險(xiǎn)主要包含以下通用漏洞風(fēng)險(xiǎn)、供應(yīng)鏈相關(guān)的風(fēng)險(xiǎn)以及過期維護(hù)的組件等三類，下文將逐一展開。

2.1 通用漏洞?險(xiǎn)

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

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

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

2.2 供應(yīng)鏈相關(guān)的?險(xiǎn)

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

開源軟件作者完成代碼編寫后 Push 到源代碼管理平臺(tái)（ 包括GitHub、碼云、Gitlab私服平臺(tái)）等；然后在CI/CD 平臺(tái)上發(fā)起構(gòu)建編譯打包的流程，在這個(gè)過程中，CI/CD 平臺(tái)會(huì)從組件依賴平臺(tái)（Sonatype Nexus私服或是 MVNRepository 官方源）上獲取需要依賴的包；在 CI/CD 平臺(tái)完成打包/鏡像封裝過程后，通過項(xiàng)目分發(fā)平臺(tái)分發(fā)到生產(chǎn)環(huán)境上，更為現(xiàn)代的方法是直接拉取 Docker 鏡像做部署，完成系統(tǒng)的上線。這個(gè)過程看似簡(jiǎn)單，但是實(shí)際上環(huán)節(jié)還是有不少的，我們把每個(gè)環(huán)節(jié)拆解來看，實(shí)際上每個(gè)環(huán)節(jié)都是會(huì)有很多?險(xiǎn)的，如下圖所示：

• IDE 插件投毒?：為了更高效率地開發(fā)軟件，開發(fā)人員往往會(huì)在自己的 IDE 當(dāng)中引入各種各樣的插件來提升自己的開發(fā)體驗(yàn)與效率。這是一件看起來非常正常的事情，但是軟件開發(fā)人員往往沒有足夠的安全意識(shí)，導(dǎo)致自己的 IDE 中可能會(huì)安裝了一些有問題的組件，甚至 IDE 本身也出現(xiàn)了供應(yīng)鏈“投毒”的情況，這種 Case 數(shù)不勝數(shù)。比較出名的是在 2021 年 5 月份， Snyk 披露的一份安全報(bào)告中顯示攻擊者在 VSCode 的插件市場(chǎng)發(fā)起了“投毒”行為，一些有問題的擴(kuò)展是“LaTeX Workshop”、“Rainbow Fart”、“在默認(rèn)瀏覽器中打開”和“Instant Markdown”，所有這些有問題的擴(kuò)展累計(jì)安裝了大約 200 萬次，此次事件所造成的影響也是非常廣泛的。
• 提交缺陷代碼?：在軟件開發(fā)環(huán)節(jié)，開發(fā)人員因?yàn)樗?、安全意識(shí)的諸多原因，往往會(huì)在開發(fā)過程中引入漏洞，這本身是一件十分正常的事情。但對(duì)于開源軟件而言，因?yàn)閹缀跛腥硕伎梢韵蜷_源項(xiàng)目提交代碼，并且通過審核后就可以 Merge 進(jìn)項(xiàng)目，所以總會(huì)有不懷好意的人故意引入有問題的代碼，比較典型的 Case 是 2021 年 4 月，明尼蘇達(dá)大學(xué) Kangjie Lu?教授帶領(lǐng)的研究團(tuán)隊(duì)因故意向 Linux?引入漏洞，導(dǎo)致整所大學(xué)被禁止參與 Linux 內(nèi)核開發(fā)。拋開道德問題不談，這種?險(xiǎn)實(shí)際上有可能因?yàn)閷徍说氖韬鰧?dǎo)致?險(xiǎn)直接被引入。
• 源代碼平臺(tái)被攻陷?：其實(shí) Git 平臺(tái)本身由于保護(hù)不當(dāng)，也有極大的概率被攻陷。雖然說攻陷 GitHub 這種平臺(tái)本身不太現(xiàn)實(shí)，但是有很多開源項(xiàng)目都是自己搭設(shè)的 Git 平臺(tái)，再加上一些眾所周知的原因，Git 平臺(tái)本身缺乏保護(hù)是一件較大概率發(fā)生的事情。在 2021 年 3 月，PHP 的官方 Git 就遇到了類似的 Case，由于 PHP 官方團(tuán)隊(duì)在 git.php.net?服務(wù)器上維護(hù)的 php-src Git 倉庫中被推送了兩個(gè)惡意提交。攻擊者在上游提交了一個(gè)神秘的改動(dòng)，稱其正在“修復(fù)排版”，假裝這是一個(gè)小的排版更正，并且偽造簽名，讓人以為這些提交是由已知的 PHP 開發(fā)者和維護(hù)者 Rasmus Lerdorf 和 Nikita Popov 完成的。所以 Git 平臺(tái)的安全保護(hù)本身也是需要被提高重視的。
• 代碼 branch 被篡改導(dǎo)致打包結(jié)果不一致?：由于開源項(xiàng)目的 Git 倉庫是向所有人開放的，有些攻擊者會(huì)嘗試新建不同的 branch 植入代碼然后進(jìn)行發(fā)布，雖然編譯過后的包帶有 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，后來經(jīng)過調(diào)查后發(fā)現(xiàn)，是代碼倉庫沒有添加分支保護(hù)機(jī)制，從動(dòng)導(dǎo)致出現(xiàn)問題，引發(fā)了此類的安全?險(xiǎn)。
• CI/CD 體系被攻陷?：研發(fā)前期，如果我們完成了代碼完整性檢測(cè)的話，如果流程沒有被篡改或者構(gòu)建平臺(tái)都運(yùn)行正常的話，一般情況下，出現(xiàn)問題的幾率很低。但如果 CI/CD 平臺(tái)和前面的 Git 一樣被惡意篡改或是破壞，也會(huì)出現(xiàn)安全隱患，SolarWind 事件就是由于這一原因?qū)е碌模粽咴?CI/CD 過程中嵌入了“后?”，通過了簽名校驗(yàn)，再通過 OTA 分發(fā)補(bǔ)丁之后，導(dǎo)致出現(xiàn)了讓人震驚的供應(yīng)鏈攻擊事件。
• 不安全組件引入?：在依賴引入的過程中，如果引入了有問題的組件，則相當(dāng)于引入了?險(xiǎn)，這也是目前最典型的供應(yīng)鏈攻擊手段，通過我們對(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í)庫相當(dāng)豐富，加上機(jī)器學(xué)習(xí)配套的計(jì)算環(huán)境性能強(qiáng)悍，導(dǎo)致“挖礦”的收益會(huì)比入侵普通 IDC 主機(jī)更高）。由于例子較多，這里就不一一列舉了。
• 外部 CI/CD 流程構(gòu)建?：因?yàn)?CI/CD 平臺(tái)有時(shí)候不能滿足需求，或開發(fā)者出于其他因素考量，會(huì)使用非官方的 CI/CD 進(jìn)行構(gòu)建，而是自己上傳打包好的 JAR 或者 Docker 鏡像來部署，更有甚者會(huì)同時(shí)把打包工具鏈和源代碼一起打包上傳到容器實(shí)例，然后本地打包（極端情況下，有些“小可愛”的依賴倉庫都是自己搭建的 Sonatype Nexus 源管理系統(tǒng)）。因?yàn)楹芏嚅_源軟件的使用者不會(huì)去做 CI/CD 的簽名校驗(yàn)（比如說簡(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ā)，造成的安全問題也越來越廣泛。
• 直接部署有問題的包?：有些打包好的成品在使用的時(shí)候，因?yàn)闆]有做校驗(yàn)和檢查，導(dǎo)致可能會(huì)部署一些有問題的包，最典型的例子是 Sonatype 之前披露的 Web-Broserify 包的事件，雖然這個(gè)包是使用了數(shù)百個(gè)合法軟件開發(fā)的，但它會(huì)對(duì)收集目標(biāo)系統(tǒng)的主機(jī)信息進(jìn)行偵查，所以造成了相當(dāng)大規(guī)模的影響。

2.3 過維護(hù)期的組件

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

• 維保問題?：因?yàn)殚_源社區(qū)的人力和精力有限，往往只能維護(hù)幾個(gè)比較主要的版本（類似于操作系統(tǒng)中的 LTS 版本，即 Long-Term Support，?期支持版本是有社區(qū)的?期支持的，但是非 LTS 版本則沒有），所以一旦使用過時(shí)很久的版本，在安全更新這一部分就會(huì)出現(xiàn)嚴(yán)重的斷層現(xiàn)象。如果出現(xiàn)了高危漏洞，官方不維護(hù)，要么就是自己編寫補(bǔ)丁修復(fù)，要么就是升級(jí)版本，達(dá)到“?痛不如短痛”的效果，要么就是像一顆定時(shí)炸彈一樣放在那里不管不問，祈求攻擊者或者“藍(lán)軍”的運(yùn)氣差一點(diǎn)。
• 安全基線不完整?：隨著信息安全技術(shù)的發(fā)展和內(nèi)生安全的推動(dòng)，版本越新的安全組件往往會(huì) Secure By Design，讓研發(fā)安全的要求貫穿整個(gè)研發(fā)設(shè)計(jì)流程。但早期由于技術(shù)、思路、攻擊面的局限性，這一部分工作往往做了跟沒做一樣。感觸特別深的兩個(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ī)制都沒有應(yīng)用。熟悉虛擬化漏洞挖掘的同學(xué)們可能知道，QEMU/KVM 環(huán)境中比較大的一個(gè)攻擊面是 QEMU 模擬出來的驅(qū)動(dòng)程序，因?yàn)?QEMU/KVM 模擬的驅(qū)動(dòng)很多都是老舊版本，所以會(huì)存在很多現(xiàn)代化的安全緩解技術(shù)沒有應(yīng)用到這些驅(qū)動(dòng)上面，從而引入了攻擊面。其實(shí)，在開源軟件的使用過程中也存在類似的情況，我們統(tǒng)稱為“使用不具備完整安全基線的開源軟件”。
• 未通過嚴(yán)謹(jǐn)?shù)陌踩珳y(cè)試?：現(xiàn)在的很多開源組件提供商，諸如 Sonatype 會(huì)在分發(fā)前進(jìn)行一定程度的安全檢測(cè)，但是時(shí)間越早，檢測(cè)的范圍越小。換句話說就是，組件越老出現(xiàn)的問題越多。畢竟之前不像現(xiàn)在一樣有好用的安全產(chǎn)品和安全思路，甚至開發(fā)的流程也沒有嵌入安全要求。而這樣就會(huì)導(dǎo)致很多時(shí)候，新發(fā)布的版本在修復(fù)了一個(gè)漏洞的同時(shí)又引入了一個(gè)更大的漏洞，導(dǎo)致?險(xiǎn)越來越大，越來越不可控。

綜上所述，從安全團(tuán)隊(duì)的視?看來，?險(xiǎn)無處不在。但是在一個(gè)非安全業(yè)務(wù)的安全公司，往往業(yè)務(wù)對(duì)于?險(xiǎn)的理解和要求，跟安全團(tuán)隊(duì)的看法可能大相逕庭。

3. 業(yè)務(wù)視?下的安全研發(fā)?險(xiǎn)

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

• 兼容性問題?：在推動(dòng)以版本升級(jí)為主要收斂手段的?險(xiǎn)修復(fù)中，業(yè)務(wù)提出最多質(zhì)疑的往往是兼容性問題，畢竟穩(wěn)定性對(duì)于業(yè)務(wù)來說非常重要。所以一般情況下，我們?cè)谕苿?dòng)升級(jí)時(shí)，往往會(huì)推送安全穩(wěn)妥且穩(wěn)定性最高的修復(fù)版本，作為主要的升級(jí)版本。但這種問題不是個(gè)例，每次遇到此類型推修的時(shí)候，業(yè)務(wù)都會(huì)問到類似問題。考慮到本文篇幅原因，這里就不再進(jìn)行展開。
• 安全版本的問題?：跟上一個(gè)問題類似，業(yè)務(wù)同學(xué)在引入組件時(shí)也會(huì)考慮安全性的問題，但業(yè)務(wù)同學(xué)由于缺乏一些安全知識(shí)，導(dǎo)致自己對(duì)于“安全版本“的判斷存在一定的出入，所以業(yè)務(wù)同學(xué)會(huì)把這個(gè)問題拋給安全同學(xué)。但是安全同學(xué)很難100%正確回答這個(gè)問題，因?yàn)殚_源組件太多，絕大多數(shù)企業(yè)不能像Google、微軟一樣把市面上所有的組件安全性全都分析一遍，所以一般只能現(xiàn)用現(xiàn)查。一來一去，會(huì)拉低這一部分的質(zhì)量和效率。所以這一部分需求也是重要且急迫的。
• 追求“絕對(duì)安全”?：有些業(yè)務(wù)同學(xué)也會(huì)直接問，到底該怎么做，才能安全地使用各種組件？話雖直接，但是能夠體現(xiàn)出背后的問題：安全的尺度和評(píng)價(jià)標(biāo)準(zhǔn)不夠透明。讓安全問題可量化，并且追求標(biāo)準(zhǔn)透明也是非常急迫的工作，考慮到這更像是運(yùn)營層面的問題，在此也不展開敘述了。
• 合規(guī)問題?：很多業(yè)務(wù)因不了解開源協(xié)議，導(dǎo)致違反了開源協(xié)議的約束，引發(fā)了法務(wù)或者知識(shí)產(chǎn)權(quán)問題。

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

4. SCA 建設(shè)的過程

其實(shí)，SCA 并不是一項(xiàng)很先進(jìn)的技術(shù)，只是在現(xiàn)代的研發(fā)過程中隨著流程的標(biāo)準(zhǔn)化、組件的豐富化、開源社區(qū)的活躍以及開發(fā)成本的降低等諸多原因，使得一個(gè)項(xiàng)目中純自己寫的代碼占整個(gè)項(xiàng)目中全部代碼的比例變得越來越低了。也就意味著供應(yīng)鏈問題產(chǎn)生的影響會(huì)越來越大，隨著 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ù)等），并且研究它們的開發(fā)流程，分析哪些階段可以引入 SCA 能力做?險(xiǎn)發(fā)現(xiàn)。
• ?險(xiǎn)數(shù)據(jù)的發(fā)現(xiàn)?：現(xiàn)在是一個(gè)數(shù)據(jù)爆炸的時(shí)代，安全團(tuán)隊(duì)每天需要關(guān)注的安全?險(xiǎn)信息來源五花八?，但是需要盡可能多地去收集?險(xiǎn)相關(guān)的數(shù)據(jù)，并且做上下文整合，使之可以自動(dòng)化和半自動(dòng)化地運(yùn)營起來。但仔細(xì)想一下，除了追求?險(xiǎn)數(shù)量，能否更進(jìn)一步追求更強(qiáng)的實(shí)效性，達(dá)到先發(fā)制人的效果？通過企業(yè)內(nèi)部多年的安全威脅情報(bào)能力建設(shè)，同時(shí)追求實(shí)效性和可用性的雙重 SLA 是可行的。除此之外，需要關(guān)注的?險(xiǎn)，不能僅僅局限于漏洞和“投毒”這兩個(gè)場(chǎng)景，還需要對(duì)開源軟件的基線信息進(jìn)行收集。
• ?險(xiǎn)與資產(chǎn)關(guān)聯(lián)基礎(chǔ)設(shè)施的建設(shè)：前面的兩個(gè)方向是數(shù)據(jù)維度的需求，考慮 SCA 落地不單單是信息安全部?的事情，在實(shí)際落地過程中，還需要跟業(yè)務(wù)的質(zhì)量效率團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)建立良性的互動(dòng)機(jī)制，才能讓安全能力深入到業(yè)務(wù)，所以需要建設(shè)相關(guān)的基礎(chǔ)設(shè)施去實(shí)現(xiàn)核心 APIs 能力的建設(shè)，對(duì)業(yè)務(wù)進(jìn)行賦能。雖然聽上去很簡(jiǎn)單，但實(shí)際上開發(fā)的東?可能是 UDF 函數(shù)，也可能是某些分析服務(wù)的插件，甚至可能是 CEP（Complex Event Process 復(fù)雜事件處理，一種應(yīng)用于實(shí)時(shí)計(jì)算的分析技術(shù)）的規(guī)則。
• 可視化相關(guān)需求?：既然有了?險(xiǎn)，安全團(tuán)隊(duì)及業(yè)務(wù)相關(guān)團(tuán)隊(duì)的同學(xué)除了自己知道之外，還需要讓負(fù)責(zé)系統(tǒng)開發(fā)相關(guān)同學(xué)也了解?險(xiǎn)的存在，并且要及時(shí)給出解決方案，指導(dǎo)業(yè)務(wù)完成修復(fù)，同時(shí)安全團(tuán)隊(duì)也需要通過獲取運(yùn)營數(shù)據(jù)，了解?險(xiǎn)的修復(fù)進(jìn)度。

正所謂“羅?不是一日建成的”。雖然現(xiàn)在確定了 SCA 建設(shè)需求和建設(shè)的方向，但落地仍然需要分階段完成。正如建設(shè)其他的安全子系統(tǒng)一樣，安全團(tuán)隊(duì)需要按照從基礎(chǔ)數(shù)據(jù)/SOP 開始建設(shè)，然后是平臺(tái)化系統(tǒng)化的建設(shè)，進(jìn)而完成整個(gè) SCA 能力的落地。所以在實(shí)際操作過程中，應(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ú)的開源組件?險(xiǎn)數(shù)據(jù)庫，旨在收集來自于全量互聯(lián)網(wǎng)上披露的?險(xiǎn)，方便與后面的資產(chǎn)數(shù)據(jù)進(jìn)行聯(lián)動(dòng)。
• 第二階段?：SOP（Standard Operating Procedure，標(biāo)準(zhǔn)運(yùn)營流程）和概念驗(yàn)證建設(shè)，信息安全團(tuán)隊(duì)通過自己的漏洞修復(fù)經(jīng)驗(yàn)進(jìn)行 SOP 的固化，通過不斷地調(diào)優(yōu)，完成一個(gè)通用的漏洞修復(fù) SOP，通過實(shí)際的演練和概念驗(yàn)證（PoC，即Proof-of-Concept）證明，該 SOP 可以在現(xiàn)有的技術(shù)條件下很好地完成?險(xiǎn)修復(fù)這一部分工作。同時(shí)結(jié)合 SOP，對(duì)之前收集的資產(chǎn)數(shù)據(jù)和?險(xiǎn)數(shù)據(jù)進(jìn)行查漏補(bǔ)缺，完成對(duì)數(shù)據(jù)和數(shù)據(jù)鏈路的校驗(yàn)工作，保證系統(tǒng)高可用。在這個(gè)階段，SCA 的服務(wù)提供方需要開放部分的核心 API 給部分業(yè)務(wù)的質(zhì)量效率團(tuán)隊(duì)，幫助他們進(jìn)行測(cè)試并收集反饋，讓其融入到自己的?險(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ì)終端用戶可視化?險(xiǎn)這一問題，SCA 子系統(tǒng)會(huì)提供核心的 APIs 給面向研發(fā)同學(xué)端的 SOC 平臺(tái)完成?險(xiǎn)信息的同步。為了保證服務(wù)的高可用，后續(xù)還會(huì)建設(shè)配套的數(shù)據(jù)鏈路檢查機(jī)制，不斷完善數(shù)據(jù)的可用性。

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

首先，在資產(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，完成從代碼開發(fā)環(huán)節(jié)到應(yīng)用上線環(huán)節(jié)的數(shù)據(jù)采集。

但是，我們?cè)趹?yīng)用這一部分?jǐn)?shù)據(jù)之后發(fā)現(xiàn)了很多問題，除開數(shù)據(jù)本身質(zhì)量和準(zhǔn)確度不談（不談不代表重要，相反這一部分很重要，后面會(huì)介紹這一部分），按照前面提到的場(chǎng)景，還會(huì)有很多額外場(chǎng)景。比如說，業(yè)務(wù)在灰度了一部分之后就忘掉了還沒灰度完，導(dǎo)致一個(gè)服務(wù)下面只修復(fù)了一部分機(jī)器；再比如有很多“小可愛”會(huì)繞過企業(yè)本身的 CI/CD 流程進(jìn)行部署操作（有些甚至還是自己人）。為了考慮到這些例外的情況，我們應(yīng)該從主機(jī)的粒度重新考慮這件事情，也就是說通過主機(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)、延遲這些問題肯定還是會(huì)有的）。詳細(xì)的落地核心工程和結(jié)構(gòu)關(guān)系，大家可以參考下圖：

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

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

通過結(jié)合自身威脅情報(bào)的實(shí)踐，以及業(yè)界關(guān)于組件?險(xiǎn)收集的最佳實(shí)踐，我們打算從 5 個(gè)維度對(duì)組件相關(guān)?險(xiǎn)進(jìn)行收集和存儲(chǔ)：

• NVD/CNVD/GitHub-GHSA 等通用漏洞數(shù)據(jù)庫：這個(gè)是基本操作，旨在收集漏洞?險(xiǎn)，結(jié)合漏洞實(shí)際情況進(jìn)行人工和研判。
• Jira、Commit、Release 和 Bugzilia 等 Pull-Request 相關(guān)的數(shù)據(jù)?：通過獲取相關(guān)的數(shù)據(jù)，結(jié)合自研的 NLP（Natural Language Process，自然語言分析）分析引擎對(duì)內(nèi)容進(jìn)行傾向性判斷，過濾并輸出安全相關(guān)的信息，然后組織人工或自動(dòng)化研判，通過實(shí)踐，我們發(fā)現(xiàn)可以大幅度提前發(fā)現(xiàn)?險(xiǎn)（筆者在 ISC2019 上曾經(jīng)闡述過?險(xiǎn)發(fā)現(xiàn)前置的必要性和落地經(jīng)驗(yàn)）。
• 組件專用?險(xiǎn)庫：經(jīng)過我們對(duì)于漏洞數(shù)據(jù)相關(guān)的調(diào)研，諸如 Github 和 Snyk 這些機(jī)構(gòu)會(huì)有專?的組件?險(xiǎn)庫對(duì)外提供，通過獲取并分析這些信息，經(jīng)過加工后可以得到可用性極高的組件?險(xiǎn)庫，可按需研判。
• 軟件風(fēng)險(xiǎn)相關(guān)的新聞資訊和 RSS 訂閱?：這類源主要是解決 0day 和被 APT 組織在野利用等特殊披露的漏洞，同 Pull-Request 數(shù)據(jù)一樣，該類型的絕大部分?險(xiǎn)數(shù)據(jù)都是需要通過 NLP 分析引擎進(jìn)行情報(bào)數(shù)據(jù)分析，進(jìn)一步進(jìn)行情感推斷后才達(dá)到可用的標(biāo)準(zhǔn)。
• 手動(dòng)錄入?：這也是常規(guī)操作，雖然采集了很多類型的?險(xiǎn)，但的確受限于供應(yīng)鏈攻擊的多種多樣和發(fā)展，所以不可能考慮得面面俱到，仍舊需要手動(dòng)接口補(bǔ)充需要運(yùn)營的?險(xiǎn)。但安全團(tuán)隊(duì)仍希望將手動(dòng)錄入的?險(xiǎn)占全部?險(xiǎn)的比例，控制到一個(gè)合理的范圍，保證這部分能力不會(huì)因?yàn)檫\(yùn)營人員的問題（如經(jīng)驗(yàn)不足、離職等），而導(dǎo)致能力的閃崩性缺失。

通過上述內(nèi)容，我們發(fā)現(xiàn)這里面絕大部分?jǐn)?shù)據(jù)都是非結(jié)構(gòu)化的，換句話來講，我們不可以直接拿來使用，需要處理（異構(gòu)數(shù)據(jù)、自然語言數(shù)據(jù)）后才可以使用，所以我們?cè)谔幚頃r(shí)會(huì)引入 NLP 分析引擎，并且對(duì)漏洞?險(xiǎn)數(shù)據(jù)打標(biāo)后（主要工作是添加 RepoID 用來和資產(chǎn)數(shù)據(jù)聯(lián)動(dòng)），才可以向下傳遞給數(shù)據(jù)引擎和 APIs 。

從威脅情報(bào)數(shù)據(jù)建設(shè)的?度來看，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ù)，這也越來越接近于設(shè)計(jì)的目標(biāo)，具體的落地核心工作內(nèi)容和關(guān)系結(jié)構(gòu)如下圖所示：

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

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

在匹配規(guī)則建設(shè)方面，因?yàn)閿?shù)據(jù)來源較多且雜亂，我們通過自研的 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)練過程和訓(xùn)練方法不屬于 SCA 建設(shè)過程中比較重要的技術(shù)，所以本文中不會(huì)展開敘述詳細(xì)的訓(xùn)練過程和情感推斷訓(xùn)練過程。除了資產(chǎn)信息關(guān)聯(lián)之外，?險(xiǎn)數(shù)據(jù)庫可以同時(shí)實(shí)現(xiàn)對(duì) CVSS（即 Common Vulnerability Scoring System，即通用脆弱性評(píng)分系統(tǒng)）的匹配，及時(shí)推送滿足 CVSS 影響范圍（這里不是指 CVSS 分?jǐn)?shù)，而是指 CVSS 的描述表達(dá)式）的漏洞信息，提醒安全運(yùn)營的同學(xué)關(guān)注相關(guān)?險(xiǎn)并及時(shí)進(jìn)行研判。

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

5. SCA 建設(shè)中遇到的問題

當(dāng)然，在 SCA 建設(shè)過程中也不是一帆?順的，我們總結(jié)一下比較困難的地方，主要包括以下幾個(gè)方面：

• 漏洞-資產(chǎn)關(guān)聯(lián)規(guī)則缺乏一個(gè)成熟且有效的行業(yè)標(biāo)準(zhǔn)：在 SCA 領(lǐng)域，目前沒有一個(gè)成熟的可以匹敵 NVD 相關(guān)的生態(tài)環(huán)境，在 NVD 體系下，有用來描述漏洞信息的 CVE ，有描述資產(chǎn)影響范圍的 CPE（Common Product Enumunation），有描述攻擊路徑的 CAPEC（Common Attack Pattern Enumeration and Classification），還有描述?險(xiǎn)類型的 CWE（Common Weakness Enumunation）。但是在組件安全領(lǐng)域，由于各家公司的基礎(chǔ)設(shè)施建設(shè)成熟度和技術(shù)選型差異巨大，所以沒有一個(gè)可用的完整生態(tài)可以做到“開箱即用”，所以我們需要基于現(xiàn)有的技術(shù)架構(gòu)和基礎(chǔ)設(shè)施來設(shè)計(jì)自己的規(guī)則，同時(shí)推廣這套標(biāo)準(zhǔn)在安全運(yùn)營工作中落地。
• 數(shù)據(jù)質(zhì)量與數(shù)據(jù)鏈路的可靠性：數(shù)據(jù)質(zhì)量和可用性問題是從立項(xiàng)開始一直到后期運(yùn)營階段都會(huì)出現(xiàn)的問題，問題可能來自于上游采集邏輯不完備或采集錯(cuò)誤，還有數(shù)據(jù)鏈路不穩(wěn)定導(dǎo)致寫入計(jì)算引擎出現(xiàn)大批量丟失的問題，還有數(shù)據(jù)鏈路沒有檢查機(jī)制，導(dǎo)致不知道具體問題出在哪里，甚至由于使用的數(shù)據(jù)分析技術(shù)棧的原因，導(dǎo)致打過來的數(shù)據(jù)是錯(cuò)亂的，錯(cuò)亂的數(shù)據(jù)有可能會(huì)影響 CEP 規(guī)則的準(zhǔn)確性和有效性。這當(dāng)中的有些問題不是偶發(fā)的，甚至有些問題在真實(shí)應(yīng)用的場(chǎng)景下會(huì)高頻出現(xiàn)，所以建立一個(gè)?效的數(shù)據(jù)撥測(cè)機(jī)制和數(shù)據(jù)污點(diǎn)追蹤能力是必要且必須的。
• ?險(xiǎn)數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)與準(zhǔn)確度：由于在?險(xiǎn)數(shù)據(jù)中引入了過多的來源，且大量引入了機(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ò)等問題，導(dǎo)致平臺(tái)提取出來的漏洞信息很多時(shí)候會(huì)有一定的出入，并且由于?險(xiǎn)情報(bào)數(shù)據(jù)比較依賴上下文和實(shí)效性，所以需要在各方面做取舍，這個(gè)問題其實(shí)和數(shù)據(jù)的問題一樣，不是一朝一夕能解決的，需要大量的實(shí)踐運(yùn)營和撥測(cè)機(jī)制 Case by Case 地去推動(dòng)解決。
• CI/CD 管制與非標(biāo)準(zhǔn)資產(chǎn)的治理：這一方面實(shí)際上與 SCA 落地的關(guān)系不是很大，但是提及的原因是 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 這種開源組件嵌套的 JAR 包，但實(shí)際上受制于數(shù)據(jù)質(zhì)量和技術(shù)能力，往往無法分析到一個(gè)非常細(xì)的粒度，所以這一部分需要去設(shè)計(jì)一個(gè) MTI（Maximum Tolerate Index 在這里表示可接受的最粗分析粒度）指標(biāo)去指導(dǎo)相關(guān)的設(shè)計(jì)。

6. SCA 技術(shù)未來的展望

在建設(shè)過程中，我們參考了很多公司和商業(yè)產(chǎn)品對(duì)于組件?險(xiǎn)分析和治理的最佳實(shí)踐，翻閱了大量與軟件成分分析技術(shù)，以及軟件供應(yīng)鏈安全治理相關(guān)的論文文獻(xiàn)、公開的專利以及企業(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，漏洞?險(xiǎn)庫 OSV（Open Source Vulnerabilities，開源組件?險(xiǎn)數(shù)據(jù)），軟件安全基線檢查工具 AllStar 和 ScoreCard，開源組件?險(xiǎn)獎(jiǎng)勵(lì)計(jì)劃 SOS Rewards（可以理解為是開源組件的漏洞獎(jiǎng)勵(lì)計(jì)劃）。

我們初步看到未來 SCA 的建設(shè)路線應(yīng)該是三個(gè)方向：?追求足夠細(xì)粒度的資產(chǎn)和?險(xiǎn)透視能力，?險(xiǎn)的主動(dòng)識(shí)別能力和開源軟件的基線檢查能力。換句話講，SCA 如果想做到足夠有效，需要覆蓋從軟件開發(fā)到上線的所有環(huán)節(jié)，包括代碼完整性、流程完整性和基線巡檢功能，這些都需要 SCA 的核心能力。

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

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

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

7. 結(jié)語

以上是我們?cè)谡麄€(gè) SCA 能力建設(shè)過程中積累的一些想法和實(shí)踐。在建設(shè) SCA 能力的過程中，通過與各團(tuán)隊(duì)的協(xié)同工作和溝通，了解了很多業(yè)務(wù)對(duì)于組件安全方面的想法和真實(shí)需求，通過需求得出需要建設(shè)的能力。在技術(shù)方案落地中，企業(yè)內(nèi)部部署的很多安全產(chǎn)品，諸如 HIDS Agent 和 RASP 等，可以從主機(jī)的?度去反向驗(yàn)證建設(shè)的過程是否正確。

此外，SCA 能力的落地離不開安全團(tuán)隊(duì)與業(yè)務(wù)團(tuán)隊(duì)的配合。實(shí)際上在 SCA 的建設(shè)過程中，我們?nèi)绻偻顚哟稳タ?，?huì)發(fā)現(xiàn)諸如閉源軟件、開源軟件的跨架構(gòu)、跨編譯器的識(shí)別、其他載體（比如容器鏡像、軟件成品）的安全分析等，這些技術(shù)挑戰(zhàn)對(duì)于實(shí)際企業(yè)內(nèi)落地 SCA 能力而言還是蠻高的，考慮到目前的解決方案還停留在 PoC 階段，就不在這里進(jìn)行過多的闡述了。

當(dāng)然，拋開整個(gè)落地的過程，考慮到各家在基礎(chǔ)設(shè)施、核心技術(shù)棧、主機(jī)信息監(jiān)控能力的參差不?，所以必定會(huì)有不能落地的地方。而站在安全服務(wù)提供商的?度上看，SCA 相關(guān)產(chǎn)品未來的建設(shè)可能需要更加輕量化、開放協(xié)同化。

所謂輕量化，是指產(chǎn)品的核心功能可以在脫離基礎(chǔ)設(shè)施多種多樣的前提下，能夠穩(wěn)定高效地去提供核心能力，能很好地與客戶的研發(fā)流程完美銜接。從調(diào)研結(jié)果來看，目前市面上所有的 SCA 產(chǎn)品，基本上都存在一個(gè)架構(gòu)設(shè)計(jì)比較重的問題，不能很好去融入現(xiàn)有的 CI/CD 流程。所謂開放協(xié)同化，是指可以通過多種方式去和其他的安全產(chǎn)品和安全能力提供數(shù)據(jù)的共享機(jī)制，實(shí)現(xiàn)與其他安全設(shè)備在數(shù)據(jù)上的聯(lián)動(dòng)，互相補(bǔ)?對(duì)應(yīng)的?險(xiǎn)發(fā)現(xiàn)能力，做到簡(jiǎn)潔、高效。

以上就是我們 SCA 能力建設(shè)過程當(dāng)中的一些想法。從?遠(yuǎn)的?度看，我們希望從源端建立起一套完整的零信任供應(yīng)鏈?險(xiǎn)管控體系，覆蓋從引入-開發(fā)-編譯-部署-使用的全生命流程，做到真正意義上的 Secure-by-Default。

從縱向來看，我們需要在研發(fā)流程的框架下盡可能全地理清整個(gè)系統(tǒng)的 SBOM 級(jí)的數(shù)據(jù)依賴情況。同時(shí)從橫向來看，我們還需要保證目前收集到的組件相關(guān)的?險(xiǎn)數(shù)據(jù)和極限數(shù)據(jù)所覆蓋的技術(shù)棧足夠的全面和準(zhǔn)確。恰好這兩部分能力是 SCA 能力中比較核心的兩個(gè)能力，也就說明了 SCA 能力是這一體系當(dāng)中比較重要的一環(huán)，可以為整個(gè)體系提供一套完整的知識(shí)庫，為后續(xù)供應(yīng)鏈?險(xiǎn)檢測(cè)邏輯提供一套完整的數(shù)據(jù)。

最后，特別感謝美團(tuán)質(zhì)量效率團(tuán)隊(duì)、基礎(chǔ)技術(shù)團(tuán)隊(duì)、到店事業(yè)群技術(shù)部餐飲的測(cè)試團(tuán)隊(duì)在整個(gè) SCA 能力建設(shè)過程中提供幫助和建議。同時(shí)，也歡迎大家在文末留言評(píng)論。

8. 本文作者

李中文（e1knot），美團(tuán)安全高級(jí)工程師。

9. 參考文獻(xiàn)

• Software Composition Analysis (SCA) reviews Reviews and Ratings
• Deep dive into Visual Studio Code extension security vulnerabilities
• That Time Linux Banned the University of Minnesota
• PHP’s Git server hacked to add backdoors to PHP source code
• Webmin backdoor blamed on software supply chain breach
• Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor
• Open Source Software Is Under Attack; New Event-Stream Hack Is Latest Proof
• Stork: Package Management for Distributed VM Environments
• Hello open source security! Managing risk with software composition analysis
• Introducing Microsoft Application Inspector
• Cyber Supply Chain Risk Management
• THE SOFTWARE BILL OF MATERIALS AND ITS ROLE IN CYBERSECURITY
• Cybersecurity Supply Chain Risk Management C-SCRM
• Introducing the Open Source Insights Project
• Announcing a unified vulnerability schema for open source
• Google stakes new Secure Open Source rewards program for developers with $1M seed money
• Introducing SLSA, an End-to-End Framework for Supply Chain Integrity
• Binary Authorization for Borg: how Google verifies code provenance and implements code identity
• A Kubernetes CI/CD Pipeline with Asylo as a Trusted Execution Environment Abstraction Framework
• AllStar: Continuous Security Policy Enforcement for GitHub Projects
• Google open-sources Allstar, a tool to protect GitHub repos
• Measuring Security Risks in Open Source Software: Scorecards Launches V2
• 2022 OPEN SOURCE SECURITY AND RISK ANALYSIS REPORT
• Focus on the Stability of Large Systems: Toward Automatic Prediction and Analysis of Vulnerability Threat Intelligence
• Open Source Security Explained
• CycloneDX Specification
• 4 Key Sigstore Takeaways: Recap of Twitter Space with Kelsey Hightower
• SLSA vs. Software Supply Chain Attacks
• The State of Open Source Vulnerabilities 2021
• GitHub 2020 Digital Insight Report
• 2020 State of the Software Supply Chain
• Making Sense of Unstructured Intelligence Data Using NLP
• OpenSCA-Cli
• MurphySec Code Scan
• Method and system for monitoring a software artifact
• Method and system for monitoring metadata related to software artifacts
• Method and system for evaluating a software artifact based on issue tracking and source control information
• sigstore - A non-profit, public good software signing & transparency service

來自：如何應(yīng)對(duì)開源組件?險(xiǎn)？軟件成分安全分析（SCA）能力的建設(shè)與演進(jìn) - 美團(tuán)技術(shù)團(tuán)隊(duì)?文章來源地址http://www.zghlxwxcb.cn/news/detail-565825.html

到了這里，關(guān)于信息安全-應(yīng)用安全-軟件成分安全分析（SCA）能力的建設(shè)與演進(jìn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！