開源對軟件的發(fā)展可以說具有深遠的意義，它幫助我們共享成果，重復使用其他人開發(fā)的軟件庫，讓我們能夠專注于我們自己的創(chuàng)新，它推進了技術的快速發(fā)展。據不完全統計78% 的企業(yè)都在使用開源，但是其中有多少企業(yè)關注第三方開園依賴的安全呢？其中僅有13% 將安全作為第一考慮因素。可喜的是仍然有50% 的企業(yè)將安全列為第二或第三位考慮因素，越來越多的公司開始重視第三方依賴的安全性。
想象我們交付的軟件 Application 是一張餅，我們自己開發(fā)的代碼僅占其中很小一部分，見下圖：
而開源依賴并不等于是安全的，當然也不等于不安全，自2000年，僅有幾家大廠貢獻開源，其中有Apache, Linux, IBM, OpenSSL等，而到了2015年之后，任何人都在貢獻開源社區(qū)，下圖是主流軟件庫的發(fā)展 ，數量龐大
而我們在使用這些依賴的時候，一定要意識到：
1. 開源依賴往往很少有進行安全性測試的
2. 開源軟件開發(fā)人源對安全意識普遍不高
3. 開源軟件提供方沒有多余的預算進行安全性測試
4. 黑客的主要攻擊目標是開源，因為攻擊一個，影響范圍很大
讓我們一起看幾組第三方依賴安全的調查數據：
我們看到第三方依賴是存在非常大的安全隱患的，那我們應該如何做呢？不使用第三方依賴顯然是不現實的，我們總結了四個步驟
1. 了解你都使用了哪些依賴
2. 刪除你不需要的依賴
3. 查找并修復當前已知的漏洞
4. 持續(xù)監(jiān)聽新發(fā)現的漏洞，重復前三個步驟
相對簡單，我們使用目前的依賴管理工具可以輕松做到，如maven的dependency tree
我們發(fā)現很對開發(fā)人員在維護依賴的時候，即使該依賴已經不適用，但不會刪除，這顯然會擴大黑客的攻擊范圍，因此我們需要定期檢查刪除不需要的依賴
第三步開始較為復雜，所幸已有很多開源組織提供了免費的漏洞庫，如US-CERT，NVD，OSVDB等漏洞廣播源，該類組織集中維護發(fā)現的已知漏洞，對外提供表述漏洞數據描述以及漏洞廣播，為開源社區(qū)安全提供數據支持，有了漏洞數據源之后，判斷我們的依賴中是否有依賴就簡單了，我們僅需要根據我們的依賴包與漏洞數據庫進行對比，就可以發(fā)現我們發(fā)布的應用中是否包含已知的漏洞，甚至有些開源組織會在漏洞庫的基礎上提供關于漏洞的修復建議，如 Synk.io，JFrog 和 Sync 合作貢獻了一個漏洞數據源（JXray），其中包含主流漏洞數據源，包括剛才提到的幾個，這樣我們就可以對我們包含對漏洞進行漏洞升級。
我們知道漏洞是持續(xù)增長的，近幾年每年平均都有900左右的新漏洞，我們需要持續(xù)監(jiān)聽這些新產生的漏洞，并與我們內部軟件生命周期集成，與DevOps有機結合（DevSecOps），這顯然需要一套平臺或系統幫助我們系統的管理第三方漏洞安全，下面我們整理了一個漏洞掃描平臺技術需求設計
能力分類 | 技術指標 | 指標需求描述 | 價值描述 |
掃描能力 | 多語言支持 | 支持主流語言漏洞掃描能力，如war，jar，docker，npm，python，debian，rpm等 | 統一監(jiān)管企業(yè)各種技術棧的開發(fā)，漏洞風險與License合規(guī)分析，全面避免漏洞上線到生產環(huán)境 |
深度掃描能力 | 對二進制包深入逐層進行漏洞掃描，如war包中包含jar包 | 細粒度，深層次發(fā)現可能的漏洞，處理混合式軟件發(fā)布體系，如Docker鏡像，rpm等 | |
分析能力 | 正向依賴分析 | 能夠分析定位出掃描目標漏洞包所在位置，標出具體哪個依賴出現漏洞 | 為企業(yè)快速定位問題及恢復提供數據依據 |
反向依賴分析 | 能夠自動化分析出漏洞包的影響范圍 | 快速分析漏洞問題的影響范圍，加速線上漏洞的恢復，大程度降低企業(yè)風險 以及評估風險成本 | |
漏洞庫 | 開源漏洞數據集成 | 集成NVD等漏洞數據中心 | 針對第三方依賴包，對外部依賴包進行統一監(jiān)管 |
商業(yè)漏洞數據集成 | 集成第三方商業(yè)漏洞工具能力，如 BlackDuck ， WhiteSource 等 | 豐富漏洞數據庫，大程度降低第三方依賴漏洞風險 | |
本地漏洞數據中心 | 對第三方依賴或企業(yè)自研件添加自定義漏洞，如與Jira等缺陷管理系統的集成 | 針對企業(yè)內部構建的軟件監(jiān)管，避免團隊內部漏洞包進一步擴散到其他團隊 | |
其他漏洞掃描工具集成 | 通過API，自定義擴展對接第三方漏洞數據庫，如病毒掃描工具集成 | 進一步豐富漏洞掃描范圍，加強漏洞掃描能力，如木馬病毒等 | |
告警 | 自定義告警規(guī)則 | 不同項目管理人員可以監(jiān)聽各自項目或軟件制品 | 同時提供全局監(jiān)管與分級監(jiān)管機制，提高項目團隊自主安全意識 |
告警通知，自動化 | 郵件通知及webhook支持， 發(fā)現漏洞可以與自動化任務集成，如高危漏洞觸發(fā)回滾任務 | 提高企業(yè)漏洞快速相應能力，甚至漏洞自修復能力，降低企業(yè)風險 | |
生態(tài)，CI／CD | 作為CI/CD軟件交付質量關卡 | 可以在軟件交付流水線中集成，根據掃描結果，繼續(xù)或阻止流水線運行 | 多維度加強軟件交付質量，增加流水線質量關卡，保證軟件交付質量 |
RestAPI 支持 | 提供RestFul方式對接漏洞掃描平臺 | 方便企業(yè)與內部工具鏈集成 | |
可視化 | 漏洞分析報表 | 漏洞掃描趨勢圖 漏洞頻率top圖 | 可視化漏洞監(jiān)管能力 提供決策依據 |
License 報表 | License 分布圖 License 兼容性分析圖 | 可視化企業(yè)在用License 提供決策依據 |
JFrog Xray 是一個通用的漏洞掃描平臺，可以滿足我們對第三方漏洞安全管理的所有需求，其主要有以下幾個特性
Java，Docker，Npm，Python，Ruby Gems，Nuget，Rpm，Debian等主流語言漏洞掃描，統一對所有開發(fā)技術棧進行安全管理
我們會深入分析軟件的依賴及其傳遞依賴，甚至是Docker 鏡像中的操作系統層，如Docker 鏡像中ubuntu操作系統Layer中某一個debian包存在漏洞。下圖是一個Docker 鏡像中包含的一個基礎maven jar包含漏洞的分析圖
當我們監(jiān)聽到一個新的漏洞后，我們往往很難定為其被哪些項目依賴并試用，極為耗時，且總會有遺漏的情況出現，提高了企業(yè)損失的幾率。
JFrog Xray 會根據所有收集到的依賴拓撲，進行反向依賴性分析，逐層找到所有包含漏洞包的上層應用?？焖俜治雎┒吹挠绊懛秶?，評估漏洞上線風險，指導企業(yè)進行漏洞修復
可以擴展與其他第三方漏洞數據平臺集成，如Whitesource，Blackduck等，通過Xray 平臺提供的Rest Api，甚至可以與企業(yè)自己漏洞數據源進行集成，形成企業(yè)安全的統一管理閉環(huán)。
我們可以在軟件持續(xù)交付流水線中集成漏洞掃描能力，將安全機制集成進來，作為企業(yè)軟件質量關卡中的一部分，當發(fā)現漏洞的時候，阻止漏洞包交付到生產環(huán)境，如下圖
JFrog Xray 采用微服務架構設計，其中主要包含以下幾個微服務，
l Server，主服務，UI
l Indexer，索引層，進行軟件包索引
l Persist，持久層，存儲漏洞及掃描結果
l Analysis，分析層，分析依賴拓撲及反向依賴，發(fā)現漏洞并告警
JFrog Xray同時支持高可用集群方式，針對企業(yè)級安全管理，提高漏洞掃描的效率及穩(wěn)定性，并且與 JFrog Artifactory 通用二進制包管理系統原生集成，共同組成制品管理統一管理方案。
本次分享，介紹了在使用第三方依賴時的安全隱患，以及針對該類問題，我們應該如何管理第三方依賴的安全，同時介紹了JFrog Xray 的安全管理特性，幫助企業(yè)輕松管理第三方漏洞，降低企業(yè)安全風險，避免含有漏洞的包上線到生產環(huán)境或客戶環(huán)境中。
重慶分公司
重慶分公司
