本文將從傳統 SDL 開始，介紹百度從 SDL 到DevSecOps的演進歷程。全文涉及 SDL 的痛點、DevSecOps 建設初衷、實踐形式、落地思路，以及落地後的效果與收益，也會介紹DevSecOps在雲原生時代的探索思路與落地場景。如果你正準備或者已經參與到企業DevSecOps建設的相關工作中，這篇文章或許能夠給你的工作帶來一些啟發。
一、輕量級SDL，百度的前DevSecOps時代
作為一家大型網際網路公司，百度具備著所有大型公司和網際網路公司的典型特點，業務體系繁多、業務數量龐大，業務迭代迅速。
在百度內部，業務研發模式有別於傳統的SDLC模型，更接近於DevOps 模式，CI/CD工具整合和自動化程度高，產品迭代頻次多、週期短。
面對這樣的業務研發場景，傳統通過輸出人力到業務團隊，全流程跟進和解決業務研發生命週期的安全問題的方式已經不再適合。安全團隊不能，也不可能將人力覆蓋到所有業務。因此，安全團隊勢必需要構建通用性的產品安全基礎設施，將其嵌入到產品研發流程中，然後配合重點業務的小範圍安全評估，來實現高可用、高自動化的軟體研發生命週期安全保障。
在百度，我們將這種方式稱之為輕量級 SDL，即通過少量的人力投入，以高自動化、高 CI/CD 整合的方式解決業務產品的安全問題。在輕量級 SDL 建設初期，我們根據實際業務場景，構建了百度的自動化漏洞檢測系統，並將其嵌入到業務測試上線流程中，具體圖示如下：
通過輕量級 SDL 建設，我們以不足 10 人的團隊規模，支撐百度 80% 以上業務的上線前安全檢查，並在過去的幾年時間，保證百度線上業務安全問題數量每年降低30% 以上。
當然，上圖中描述的輕量級 SDL架構也存在一些問題和痛點。
雖然通過在測試上線階段嵌入了自動化安全測試流程，能夠幫助業務在上線之前提前發現安全問題，降低安全風險。但是由於業務團隊相對缺少安全意識和視野，經常誤認為保障業務安全只是安全團隊的工作，認為自動化安全測試是安全團隊給業務團隊增加的額外負擔。在這種情況下，業務團隊在面對自動化安全測試流程檢查出的問題時，也常常是 case by case 的解決，並沒有深層次的解決安全意識和安全編碼相關的問題。
對此，我們整理了輕量級 SDL 初期建設完成後亟待解決的一些問題，並決心解決：
- 自動化安全工具很難覆蓋到產品的需求設計階段。
- 安全只覆蓋了產品研發的編碼和測試階段，並沒有實現全鏈條覆蓋。
- 絕大多數產品的安全措施集中在測試階段，流程滯後、修復成本高、效率低。
- 僅通過自動化安全工具的嵌入，很難與業務團隊建立安全協同機制。
- 非常規型安全漏洞，很難在測試階段進行自動化發現和收斂。
二、構建DevSecOps的初衷
針對上述問題，我們期望對輕量級 SDL 架構進一步完善，建設一個產品研發全流程覆蓋、高自動化整合、強調安全與業務協同的業務安全保障框架。
我們期望通過產品研發全流程的安全措施建設，持續提升業務團隊相關人員的安全意識、安全編碼習慣以及對安全場景的理解，讓業務在產品研發的各個階段都能實現高效、安全、可靠的交付，將安全漏洞和缺陷消滅在問題的根源。
這些都與 DevSecOps 的理念不謀而合，所以我們決定在輕量級 SDL 的基礎上，構建百度的 DevSecOps。
三、百度DevSecOps實踐
我們在建設DevSecOps時，主要側重以下方面：
- 打造高自動化的產品安全工具鏈： 利用產品安全工具在產品研發的各個階段進行自動化漏洞挖掘，快速發現漏洞的同時確保不會降低研發效率
- 在全公司範圍內的落地：設計普適性的、能夠覆蓋百度所有業務並真正落地的 DevSecOps 框架
- DevSecOps安全運營：對各個產品安全工具進行安全能力建設與工程化運營，並支援特定業務線的定製化需求
- 雲原生場景的探索：在雲原生基礎架構變革大趨勢下，討論百度DevSecOps與雲原生場景的融合與落地措施。
後邊的章節會按照這個順序逐一闡述。
3.1 產品安全工具鏈打造
業務安全保障的核心工作之一就是降低線上漏洞數量。在 DevSecOps 的建設中，想要大幅度降低線上漏洞數量，其核心是構建和利用好各種自動化漏洞發掘工具，並將其與CI/CD進行自動化整合，確保執行漏洞發掘的時機準確、及時，並且不會影響研發效率。
在我們的解決方案中，主要涉及到DAST、SAST、IAST、RASP等工具的設計與實現，感興趣的同學可以閱讀之前發過的相關文章：
- DAST
分散式Web漏洞掃描服務建設實踐系列——掃描架構演進及要點問題解決實踐
- SAST
- IAST/FAST
- RASP
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 開發/程式碼准入階段
- 供應鏈安全檢測
供應鏈安全檢測主要聚焦第三方程式碼引入公司內部的安全性檢測。
百度的產品程式碼託管在內部程式碼託管平臺，因此供應鏈安全檢測也應該圍繞程式碼託管平臺展開，除了在研發流程中嵌入新增程式碼檢測以外，我們還針對存量的程式碼實現檢測與工單追蹤閉環，為第三方程式碼風險快速、有效收斂提供最便捷的通道。
整體檢測架構為：
供應鏈檢測系統中的第三方高危軟體識別主要依託於指紋匹配技術，主要分為程式碼指紋識別與包管理解析兩種。程式碼指紋識別類似於傳統的正則匹配；包管理解析則是針對不同包管理檔案，例如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應用到雲原生化架構中，讓安全與業務更加緊密地聯絡在一起，將會是雲原生時代提升業務安全質量、降低業務安全風險和後期安全成本的最優解，也可能是唯一解。
四、DevSecOps建設收益
通過DevSecOps的落地，我們從過去僅在測試階段檢查轉變為產品研發全流程的安全保障，進一步提升了研發效率、安全問題檢出效率，降低了安全問題的修復成本，並提升了產品安全質量以及業務團隊的安全素養。
此外，業務線在各個研發階段都能看到安全相關的措施，安全措施和研發措施進行融合，增進安全協同，更能夠讓業務線意識到產品安全並不只是安全團隊的事情，而是產品線、安全團隊一起協同的結果，Sec和Dev、Ops一樣，都是研發過程中必須要做的工作。
總的來說，通過DevSecOps的落地，我們獲得了：
- 打造了覆蓋研發全鏈條的產品安全框架，後續可以基於這個框架進行產品安全措施擴充套件，比如將隱私合規要求融入DevSecOps需求階段中
- 提升了研發效率、安全問題檢出效率，降低了修復成本
- 提升了產品安全質量以及業務團隊的安全素養
- 大幅度降低線上漏洞風險，自DevSecOps落地後，線上風險得到了進一步收斂
五、文章總結
本文從傳統SDL時代的痛點出發，闡述了我們建設DevSecOps的初衷，並分享了百度DevSecOps在各個研發階段的建設、落地思路與安全實踐，以及相關工具鏈打造經驗。最後介紹了我們建設DevSecOps的相關收益與效果。
希望本文對讀者有所幫助。