前言

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

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

安全視角下的研發風險

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

通用漏洞風險

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

而根據 2020 年 Snyk 發布的另一份開源組件與供應鏈安全的報告顯示，漏洞的數量仍然需要提高警惕，XSS 漏洞仍然占據數量榜首，緊隨其后的是命令執行類漏洞，這些漏洞會嚴重影響系統的穩定性。

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

供應鏈相關的風險

開源組件的生產-構建-發布過程其實是與企業內部常規的系統研發上線的流程是一致的，簡單來說可以抽象成下圖中的樣子：

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

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

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

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

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

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

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

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

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

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

過維護期的組件

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

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

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

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

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

業務視角下的安全研發風險

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

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

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

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

合規問題：很多業務會不了解開源協議導致不小心違反了開源協議的約束，引發法務問題。

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

SCA 建設的過程

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

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

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

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

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

可視化相關需求：既然有了風險，安全團隊及業務相關團隊的同學除了自己知道之外，還需要讓負責系統開發相關同學也知道風險的存在，并且要及時給出解決方案，指導業務完成修復，同時安全團隊也需要通過獲取運營數據知道風險的修復進度。

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

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

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

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

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

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

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

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

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

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

組件專用風險庫：經過我們對于漏洞數據相關的調研，諸如 Github 和 Snyk 這些機構會有專門的組件風險庫對外提供，通過獲取并分析這些信息，經過加工后可以得到可用性極高的組件風險庫，可按需研判。

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

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

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

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

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

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

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

SCA 建設中遇到的問題

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

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

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

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

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

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

SCA 技術未來的展望

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

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

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

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

結語

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

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

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