DevSecOps在百度的實踐

本文將從傳統 SDL 開始，介紹百度從 SDL 到DevSecOps的演進歷程。全文涉及 SDL 的痛點、DevSecOps 建設初衷、實踐形式、落地思路，以及落地後的效果與收益，也會介紹DevSecOps在雲原生時代的探索思路與落地場景。若是你正準備或者已經參與到企業DevSecOps建設的相關工做中，這篇文章或許可以給你的工做帶來一些啓發。

1、輕量級SDL，百度的前DevSecOps時代

做爲一家大型互聯網公司，百度具有着全部大型公司和互聯網公司的典型特色，業務體系繁多、業務數量龐大，業務迭代迅速。

在百度內部，業務研發模式有別於傳統的SDLC模型，更接近於DevOps 模式，CI/CD工具集成和自動化程度高，產品迭代頻次多、週期短。

面對這樣的業務研發場景，傳統經過輸出人力到業務團隊，全流程跟進和解決業務研發生命週期的安全問題的方式已經再也不適合。安全團隊不能，也不可能將人力覆蓋到全部業務。所以，安全團隊勢必須要構建通用性的產品安全基礎設施，將其嵌入到產品研發流程中，而後配合重點業務的小範圍安全評估，來實現高可用、高自動化的軟件研發生命週期安全保障。

在百度，咱們將這種方式稱之爲輕量級 SDL，即經過少許的人力投入，以高自動化、高 CI/CD 集成的方式解決業務產品的安全問題。在輕量級 SDL 建設初期，咱們根據實際業務場景，構建了百度的自動化漏洞檢測系統，並將其嵌入到業務測試上線流程中，具體圖示以下：

經過輕量級 SDL 建設，咱們以不足 10 人的團隊規模，支撐百度 80% 以上業務的上線前安全檢查，並在過去的幾年時間，保證百度線上業務安全問題數量每一年下降30% 以上。

固然，上圖中描述的輕量級 SDL架構也存在一些問題和痛點。

雖然經過在測試上線階段嵌入了自動化安全測試流程，可以幫助業務在上線以前提早發現安全問題，下降安全風險。可是因爲業務團隊相對缺乏安全意識和視野，常常誤認爲保障業務安全只是安全團隊的工做，認爲自動化安全測試是安全團隊給業務團隊增長的額外負擔。在這種狀況下，業務團隊在面對自動化安全測試流程檢查出的問題時，也經常是 case by case 的解決，並無深層次的解決安全意識和安全編碼相關的問題。

對此，咱們整理了輕量級 SDL 初期建設完成後亟待解決的一些問題，並決心解決：

1. 自動化安全工具很難覆蓋到產品的需求設計階段。
2. 安全只覆蓋了產品研發的編碼和測試階段，並無實現全鏈條覆蓋。
3. 絕大多數產品的安全措施集中在測試階段，流程滯後、修復成本高、效率低。
4. 僅經過自動化安全工具的嵌入，很難與業務團隊創建安全協同機制。
5. 很是規型安全漏洞，很難在測試階段進行自動化發現和收斂。

2、構建DevSecOps的初衷

針對上述問題，咱們指望對輕量級 SDL 架構進一步完善，建設一個產品研發全流程覆蓋、高自動化集成、強調安全與業務協同的業務安全保障框架。

咱們指望經過產品研發全流程的安全措施建設，持續提高業務團隊相關人員的安全意識、安全編碼習慣以及對安全場景的理解，讓業務在產品研發的各個階段都能實現高效、安全、可靠的交付，將安全漏洞和缺陷消滅在問題的根源。

這些都與 DevSecOps 的理念不謀而合，因此咱們決定在輕量級 SDL 的基礎上，構建百度的 DevSecOps。

3、百度DevSecOps實踐

咱們在建設DevSecOps時，主要側重如下方面：

1. 打造高自動化的產品安全工具鏈： 利用產品安全工具在產品研發的各個階段進行自動化漏洞挖掘，快速發現漏洞的同時確保不會下降研發效率
2. 在全公司範圍內的落地：設計普適性的、可以覆蓋百度全部業務並真正落地的 DevSecOps 框架
3. DevSecOps安全運營：對各個產品安全工具進行安全能力建設與工程化運營，並支持特定業務線的定製化需求
4. 雲原生場景的探索：在雲原生基礎架構變革大趨勢下，討論百度DevSecOps與雲原生場景的融合與落地措施。

後邊的章節會按照這個順序逐一闡述。

3.1 產品安全工具鏈打造

業務安全保障的核心工做之一就是下降線上漏洞數量。在 DevSecOps 的建設中，想要大幅度下降線上漏洞數量，其核心是構建和利用好各類自動化漏洞發掘工具，並將其與CI/CD進行自動化集成，確保執行漏洞發掘的時機準確、及時，而且不會影響研發效率。

在咱們的解決方案中，主要涉及到DAST、SAST、IAST、RASP等工具的設計與實現，感興趣的同窗能夠閱讀以前發過的相關文章：

1. DAST

分佈式Web漏洞掃描服務建設實踐系列——掃描架構演進及要點問題解決實踐

分佈式Web漏洞掃描服務建設實踐—衡量指標及解決實踐（2）

1. SAST

企業級自動化代碼安全掃描實戰

構建企業級研發安全編碼規範

1. IAST/FAST

灰盒自動化漏洞挖掘實踐

1. RASP

開源應用運行時自我保護解決方案 - OpenRASP

3.2 公司範圍落地實踐

3.2.1 整體落地思路

在百度，產品研發流程被抽象成「需求」、「開發」、「代碼准入」、「測試」、「上線&驗證」五個階段。每一個階段都有完善且嚴格的規範和要求，例如在代碼准入階段，要求正式提交的代碼必須嚴格遵循百度代碼風格規範，不然不容許提交代碼。這些規範保證了百度的產品可以優質、高效和穩定的交付，咱們稱之爲研發工程規範性模型，下文簡稱工程規範性模型。

百度工程規範性模型將產品研發各個階段的規範和措施的完成度量化爲分數，以產品和代碼倉庫的維度進行統計和公示，並在公司層面創建了工程規範性評分基準線。

咱們在思考如何設計和落地 DevSecOps在各個研發階段的安全能力時，發現 DevSecOps 的內核與工程規範性模型是高度類似的，都是經過在產品研發的各個階段設計規範、工具、檢查，來提高研發效率、產品質量、工程師素養。

再一次的不謀而合，促使咱們決定依託於百度工程規範性模型構建百度的 DevSecOps 模型，推進DevSecOps工具鏈與相關規範的落地實施，並藉助於百度工程規範實現快速推廣 DevSecOps 到全公司的效果。

百度工程規範性模型要求全部接入的規範、工具、方法都要具有高自動化以及高 CI/CD 集成的能力，這一點實際咱們在SDL時代就已經完成。因此在落地DevSecOps時，咱們只須要按照該模型的標準，將各項產品安全工具、產品安全措施轉換爲可量化、分步實施的安全檢查項。

經過將安全檢查項合理放置在產品研發的各個階段中，咱們實現了研發全鏈條覆蓋：

同時得益於高度自動化的安全工具鏈支撐，雖然咱們在研發流程中深度嵌入了不少安全檢查項，可是依然能夠知足DevOps時代產品快速迭代的需求。例如，咱們將第三方高危組件、安全編碼規範等安全檢查項嵌入到代碼准入階段，自動化掃描任務能夠在分鐘級完成，徹底不會影響代碼的正常提交。

下面的章節，咱們會介紹在 DevSecOps 落地過程當中，在各個研發階段涉及到的一些具體安全措施和安全工具。

3.2.2 需求階段

- 需求設計安全解決方案

在DevOps模式下，需求、設計階段一般是整個研發週期中最靈活且難以控制的。因爲業務量龐大、業務快速迭代的特色，不少傳統產品安全措施如：威脅建模、安全設計評審、業務設計安全評估等工做難以覆蓋到全部業務。

對此，在百度DevSecOps方案中，咱們針對不一樣業務場景提供了一系列安全解決方案，覆蓋Web業務、App業務、IoT業務、toB私有化、用戶隱私等業務場景，基於多年SDL安全經驗積累，對各個業務中容易出現風險的地方提供了統一化的安全解決方案，這些方案有的是規範約定，有的是bad case枚舉，還有的是基於安全SDK的解決方案。

同時將其集成到百度工程規範指定的需求管理產品iCafe中。當業務線研發人員、PM建立需求卡片時，能夠根據自身的業務場景選擇對應的安全解決方案，並在研發前完成規範、安全方案的學習，從而在研發編碼階段儘量避免這些問題。

3.2.3 開發/代碼准入階段

1. 供應鏈安全檢測

供應鏈安全檢測主要聚焦第三方代碼引入公司內部的安全性檢測。

百度的產品代碼託管在內部代碼託管平臺，所以供應鏈安全檢測也應該圍繞代碼託管平臺展開，除了在研發流程中嵌入新增代碼檢測之外，咱們還針對存量的代碼實現檢測與工單追蹤閉環，爲第三方代碼風險快速、有效收斂提供最便捷的通道。

總體檢測架構爲：

供應鏈檢測系統中的第三方高危軟件識別主要依託於指紋匹配技術，主要分爲代碼指紋識別與包管理解析兩種。代碼指紋識別相似於傳統的正則匹配；包管理解析則是針對不一樣包管理文件，例如java的pom.xml、gradle，nodejs的package.json等，作語法解析，獲取到引入的包名與版本號。代碼指紋識別漏報率相對更高，包管理解析獲取的包名一般爲類庫名，與第三方軟件的通用名稱存在差別，須要根據實際應用場景作進一步的適配和兼容。

第三方軟件的漏洞被外界爆出後，攻擊者可能在短期內進行攻擊，若是供應鏈檢測沒法作到快速響應，將會使得整個供應鏈安全檢測的效果大大折扣，所以咱們同步建設了實時指紋掃描與軟件查詢能力。經過打通線上工單系統，咱們能夠在分鐘級完成漏洞代碼定位與推送，並實現80% 以上代碼庫在一天內更新修復。以fastjson組件爲例，在19年和20年的幾回漏洞爆發中，咱們在分鐘級便完成大量使用fastjson組件的代碼庫定位與工單推送，並在天級的時間內推進業務代碼完成修復，閉環效果十分明顯。

• 安全編碼規範檢查

安全編碼規範檢查主要聚焦於百度內部生產的代碼的安全性檢測。

區別于于傳統白盒安全掃描，安全編碼規範檢查治理白盒漏洞的思路是先經過制定相關的基於安全基礎庫的安全編碼規範，要求業務摒棄一些危險的編碼習慣，好比各類拼接寫法、調用不安全的默認API等，使用安全SDK中的API實現相關的功能，從而下降寫出漏洞的風險。

與供應鏈安全檢測相似，百度安全編碼規範檢查也集成在公司內部研發工具鏈中。

在這種模式下，一條規範檢查規則是這樣的：

關於該治理措施和安全工具的構建，能夠閱讀：構建企業級研發安全編碼規範

3.2.4 測試階段

在測試階段，咱們主要嵌入了上線前安全基準測試，也就是市面上DevSecOps方案主要宣傳的部分，即各類安全工具鏈的使用，做爲產品上線前的最後一個兜底工做。

在百度，咱們構建了：黑盒掃描（DAST）、白盒掃描（SAST）、灰盒掃描（IAST/FAST）、RASP等產品安全工具鏈，並將這些工具作到自動化程度極高，減小業務參與的難度，實現一次配置永久運行的效果。

值得注意的是，RASP技術（https://rasp.baidu.com）除了在遭受外部攻擊時能夠進行攻擊識別，還能夠從一些程序錯誤中有效識別出漏洞。所以在咱們的實踐中，RASP產品被大量部署在測試環境中，在對業務線徹底透明的狀況下，幫助業務線提早發現漏洞、風險。

3.2.5 上線&驗證階段

目前上線&驗證階段主要是要求業務線進行安全產品、安全防禦能力的接入，主要涉及到：日誌備份、線上版RASP、集團WAF等，確保產品線上運行時安全。

3.3 DevSecOps安全運營

當咱們完成整個研發全鏈條的覆蓋以後，後續的工做變得相對比較簡單，能夠將有限的人力投入到工具鏈安全能力建設、產品線DevSecOps定製化需求、重點業務場景安全解決方案制定與實施中。經過精細化的安全運營，確保DevSecOps得以準確、高質量的實施。

3.4 DevSecOps雲原生場景探索

CNCF將雲原生定義爲致力於幫助企業在公有云、私有云和混合雲等新型動態環境中構建與運行可彈性擴展應用的一種技術，包括容器、微服務以及不可變基礎設施等。

相比於傳統的基礎架構模型，構建於雲原生技術之上的研發模型可以實現應用彈性、可擴展部署，而且開發和交付也更加敏捷。但與此同時，因爲基礎軟件自由引入，應用快速迭代，鏡像的獲取、容器的部署更加靈活，雲原生產品研發過程當中實際上具備更多潛在的安全風險。好比當基礎鏡像中引入了惡意組件或者高危組件這種場景，傳統的產品安全措施與工具鏈很難對其進行風險治理與收斂。

所以，咱們須要將DevSecOps與雲原生深度結合，對雲原生技術下構建的研發流程進行持續管控，更好地在研發鏈條中保護業務安全。

雲原生時代下，咱們在DevSecOps方案中增長了鏡像安全掃描、安全分發、鏡像簽名與運行時監控等產品安全措施，這些與原有的應用層DevSecOps共同構成了一條完整的DevSecOps安全管控鏈路。鏡像掃描能夠經過配置是否阻斷，來限制包含高危漏洞的鏡像上線；安全分發能夠保證鏡像分發安全，而運行時監控則能針對線上容器危險操做、非法網絡鏈接等進行阻斷。具體的管控方案以下：

除了增長一些自動化的檢查和監控之外，咱們還在着力推進鏡像倉庫統一化、基礎鏡像標準化等，避免線上運行時環境過於分散，下降後期治理與管控成本。

除了上述內容，咱們也在關注K8s等編排工具自己的安全性，宿主機上容器軟件權限設置，以及內核安全等。

將DevSecOps應用到雲原生化架構中，讓安全與業務更加緊密地聯繫在一塊兒，將會是雲原生時代提高業務安全質量、下降業務安全風險和後期安全成本的最優解，也多是惟一解。

4、DevSecOps建設收益

經過DevSecOps的落地，咱們從過去僅在測試階段檢查轉變爲產品研發全流程的安全保障，進一步提高了研發效率、安全問題檢出效率，下降了安全問題的修復成本，並提高了產品安全質量以及業務團隊的安全素養。

此外，業務線在各個研發階段都能看到安全相關的措施，安全措施和研發措施進行融合，增進安全協同，更可以讓業務線意識到產品安全並不僅是安全團隊的事情，而是產品線、安全團隊一塊兒協同的結果，Sec和Dev、Ops同樣，都是研發過程當中必需要作的工做。

總的來講，經過DevSecOps的落地，咱們得到了：

1. 打造了覆蓋研發全鏈條的產品安全框架，後續能夠基於這個框架進行產品安全措施擴展，好比將隱私合規要求融入DevSecOps需求階段中
2. 提高了研發效率、安全問題檢出效率，下降了修復成本
3. 提高了產品安全質量以及業務團隊的安全素養
4. 大幅度下降線上漏洞風險，自DevSecOps落地後，線上風險獲得了進一步收斂

5、文章總結

本文從傳統SDL時代的痛點出發，闡述了咱們建設DevSecOps的初衷，並分享了百度DevSecOps在各個研發階段的建設、落地思路與安全實踐，以及相關工具鏈打造經驗。最後介紹了咱們建設DevSecOps的相關收益與效果。

但願本文對讀者有所幫助。