前言  

隨著 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 版本則沒有），所以一旦使用過時很久的版本，在安全更新這一部分就會出現嚴重的斷層現象，如果出現了高危漏洞，官方不維護，要麼就是自己編寫補丁修復，要麼就是升級版本達到長痛不如短痛的效果，要麼就是像一顆定時炸彈一樣放在那裡，祈求攻擊者或者藍軍的運氣差一點。
• 安全基線不完整：隨著資訊保安技術的發展和內生安全的推動，版本越新的安全元件往往會 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 能力建設過程當中的想法。從長遠的角度看，我們是希望從源端建立起一套完整的零信任供應鏈風險管控體系，覆蓋從引入-開發-編譯-部署-使用的全生命流程，做到真正意義上的 secure-by-default，從縱向來看，我們需要在研發流程的框架下儘可能全的理清整個系統的 SBOM 級的資料依賴情況，同時從橫向來看，我們還需要保證目前收集到的元件相關的風險資料和極限資料所覆蓋的技術棧足夠的全面和準確。恰好這兩部分能力是 SCA 能力中比較核心的兩個能力，也就說明了 SCA 能力這是這一體系當中比較重要的一環，可以為整個體系提供一套完整的知識庫，為後續供應鏈風險檢測邏輯提供一套完整的資料。最後，特別感謝質量效率團隊、基礎技術團隊、到店事業群技術部餐飲的測試團隊在整個 SCA 能力建設過程中提供幫助和建議。如有興趣探討，可聯絡 SRC 運營同學索要我的微信，我們繼續可以討論。

參考文獻

• https://www.gartner.com/reviews/market/software-composition-analysis-sca
• https://snyk.io/blog/visual-studio-code-extension-security-vulnerabilities-deep-dive/
• https://www.reddit.com/r/HobbyDrama/comments/nku6bt/kernel_development_that_time_linux_banned_the/
• https://www.bleepingcomputer.com/news/security/phps-git-server-hacked-to-add-backdoors-to-php-source-code/
• https://portswigger.net/daily-swig/webmin-backdoor-blamed-on-software-supply-chain-breach
• https://www.mandiant.com/resources/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor
• https://blog.sonatype.com/open-source-software-is-under-attack-new-event-stream-hack-is-latest-proof
• https://www.cs.arizona.edu/sites/default/files/TR07-02.pdf
• https://www.microsoft.com/security/blog/2020/07/20/open-source-security-managing-risk-software-composition-analysis/
• https://www.microsoft.com/security/blog/2020/01/16/introducing-microsoft-application-inspector/
• https://csrc.nist.gov/CSRC/media/Projects/cyber-supply-chain-risk-management/documents/C-SCRM_Fact_Sheet_Draft_May_25.pdf
• http://go.anchore.com/rs/603-AEB-887/images/Anchore%20Software%20Bill%20of%20Materials%202021.pdf?mkt_tok=NjAzLUFFQi04ODcAAAGD5M9YCkwNcfKEavmNJ2xAVSBbU6YN6NBY7Er1PH6DD81eqWLXigqRla69Zy3jJFDbhLmPe4t4iMiTwcOm648mXy2ytLVplQi5Tg0tIQ
• https://csrc.nist.gov/Projects/cyber-supply-chain-risk-management
• https://opensource.googleblog.com/2021/06/introducing-open-source-insights-project.html
• https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html
• https://www.techrepublic.com/article/google-stakes-new-secure-open-source-rewards-program-for-developers-with-1m-seed-money/
• https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html
• https://cloud.google.com/docs/security/binary-authorization-for-borg
• https://research.google/pubs/pub49962/
• https://security.googleblog.com/2021/08/allstar-continuous-security-policy.html
• https://therecord.media/google-open-sources-allstar-a-tool-to-protect-github-repos/
• https://security.googleblog.com/2021/07/measuring-security-risks-in-open-source.html
• https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
• https://snyk.io/open-source-security/
• https://github.com/CycloneDX/specification
• https://blog.chainguard.dev/4-key-sigstore-takeaways-recap-of-twitter-space-with-kelsey-hightower/
• https://blog.chainguard.dev/slsa-vs-software-supply-chain-attacks/
• https://www.whitesourcesoftware.com/resources/research-reports/the-state-of-open-source-vulnerabilities/
• http://oss.x-lab.info/github-insight-report-2020-en.pdf
• https://www.sonatype.com/resources/white-paper-state-of-the-software-supply-chain-2020
• https://www.trustar.co/blog/making-sense-of-unstructured-data-using-nlp
• https://github.com/XmirrorSecurity/OpenSCA-cli
• https://github.com/murphysecurity/murphysec-jetbrains-plugin
• https://patents.google.com/patent/US8627270B2
• https://patents.google.com/patent/US8473894B2
• https://patents.google.com/patent/US9141378B2
• https://medium.com/sigstore