前言

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

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

安全視角下的研發(fā)風險

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

通用漏洞風險

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

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

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

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

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

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

這個過程看似簡單，但是實際上環(huán)節(jié)還是有不少的，我們把每個環(huán)節(jié)拆解來看，實際上每個環(huán)節(jié)都是會有很多風險的，如下圖所示：

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

提交缺陷代碼：在軟件開發(fā)環(huán)節(jié)，開發(fā)人員因為水平、安全意識的諸多原因，往往會在開發(fā)過程中引入漏洞，這本身是一件十分正常的事情，但是對于開源軟件而言，因為幾乎是所有人都可以向開源項目提交代碼，并且通過審核后就可以merge進項目，所以總會有不懷好意的人故意引入有問題的代碼，比較典型的 case 是2021年4月，明尼蘇達大學 Kangjie Lu 教授帶領(lǐng)的研究團隊因故意向 Linux 引入漏洞，導(dǎo)致整所大學被禁止參與 Linux 內(nèi)核開發(fā)。除開道德問題，這種風險實際上有可能因為審核的疏忽導(dǎo)致風險直接被引入。

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

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

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

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

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

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

過維護期的組件

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

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

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

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

綜上，在安全團隊的視角看來，風險無處不在。但是在一個非安全業(yè)務(wù)的安全公司，往往業(yè)務(wù)對于風險的理解和要求與安全團隊可能大相逕庭。

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

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

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

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

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

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

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

SCA 建設(shè)的過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)語

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

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

以上是我們對 SCA 能力建設(shè)過程當中的想法。