4637字，看懂從DevOps到DevSecOps的進化之路

作者：周紀海 周一帆 馬鬆鬆 陶芬 楊偉強 程勝聰 陳亞平

來源：華章科技

維基百科上，DevOps（Development和Operations的組合詞）是指一種重視軟體開發人員（Dev）和IT運維技術人員（Ops）之間溝通合作的文化、運動或慣例。通過自動化軟體交付和架構變更的流程，使構建、測試、發布軟體能夠更加快捷、頻繁和可靠。

現在，即使對了解過DevOps甚至是已經在使用這種研發模式的人來說，也難以定義到底什麼是DevOps。有些觀點認為，DevOps區別於傳統的瀑布模式，基於敏捷模式，並將敏捷思想和實踐從開發擴展到運維（也有激進的觀點認為它完全不同於這兩種研發模式），是一種新的思維模式和行動方法。

01 DevOps發展簡史

在2008年舉辦的敏捷大會上，Patrick Debois和Andrew Clay Shafer首次提議討論了「敏捷基礎架構」這個話題。在第二年的敏捷大會上，兩名Flickr員工做了題為「10+ Deploys per Day: Dev and Ops Cooperation at Flickr」（「每天10次部署」）的演講，這可以看作開創了我們現在所說的DevOps的概念。

之後它激發著Patrick在同年10月於比利時根特市舉辦了第一屆DevOpsDays，這代表著DevOps推廣的開始。

從那以後，DevOps藉助DevOpsDays在全球範圍內傳播，並於2019年達到頂峰—全球有80座城市在2019年舉辦了DevOpsDays。2019年10月28日到30日，全球各個國家和城市的DevOps活動組織者和推廣者齊聚比利時根特市，舉辦了DevOpsDays十周年慶典。

相比歐美國家，DevOpsDays進入中國相對較晚，2017年3月18日北京舉辦了第一屆中國DevOpsDays，並於接下來幾年陸續在上海和深圳也分別舉辦了DevOpsDays峰會。

由於DevOpsDays對中國DevOps行業的影響，2018年7月22日，中國DevOps社區成立，並迅速發展到全國18個城市，通過本地化的DevOps Meetup等小型活動在各個城市繼續推廣DevOps。

除了DevOpsDays，另一個標誌性事件是Alanna Brown在2012年起草了第一版年度 《DevOps現狀報告》。從2012年起，這份年度報告就被DevOps業界和從業人士作為了解DevOps現狀的參考以及DevOps發展方向的風向標。

另外，2013年Gene Kim出版了小說體的《鳳凰項目》一書，通過描述一家正在經歷DevOps轉型的企業，生動形象地向讀者介紹了轉型過程中的思想碰撞，以及各種問題和相關的解決方法。

2016年，Gene Kim聯合Jez Humble、Patrick Debois和John Wills合力出版了DevOps業界最具權威的經典著作：《DevOps實踐指南》。圖1-1給出了DevOps 10多年的發展歷程。

▲圖1-1 DevOps發展史

02 DevOps理念

DevOps的目標是提升整個研發效能，進行更便捷、更快速、更可靠的交付，從而提高產品競爭優勢。DevOps模糊了以往研發模式中開發、測試、運維等崗位和角色的界限，加強了他們之間的協作，甚至鼓勵將各個角色從傳統的專家團隊的組織結構，重新編製成全功能團隊，用以加強協作（如圖1-2所示）。

▲圖1-2 DevOps組織結構轉變

技術層面上，則通過流水線和一系列自動化機制、成熟可伸縮的基礎設施（如雲）等，使開發人員獲得更高的效能，從而更加頻繁且快速地將代碼變為產品，並從這種快速中獲得持續不斷的反饋和驗證，以獲得更高的可靠性。

為了能夠達到DevOps的目標：更便捷、更頻繁地進行更可靠的交付，除了思維模式和文化以外，DevOps也需要一些技術和工具來支撐。也是得益於一些基礎設施和工具的發展和成熟，才使得越來越多的公司能夠踐行DevOps。

從目前業界的最佳實踐來看，DevOps技術和理念主要包括幾個關鍵的要素：持續集成（Continuous Integration，CI）、持續交付（Continuous Delivery，CD）、微服務（Microservice）、自動化測試、基礎設施即代碼（Infrastructure as Code，隱含了虛擬化、容器、自動編排、配置即代碼等技術和理念）、監控和日誌（Monitoring and Logging）等。業界圍繞DevOps已經形成了一系列的工具集合和解決方案。

最終，通過文化意識的改變和自動化工具的使用，DevOps能夠帶來的價值也是很明顯的，包括更快的研發交付速度、更快的產品創新和嘗試速度；有效地管理了更大規模的系統，並能夠提供更可靠的質量；從文化角度，深化了研發各角色之間的協作。不僅僅是互聯網行業，包括很多傳統的金融、零售、製造等行業也在嘗試DevOps。

在如圖1-3所示的傳統模式下，在整個研發流程（需求、開發和測試）完成之後和上線前需要進行安全評審，以保證應用的安全性。因此，簡單來說，整個軟體開發的交付周期就是研發時長加上安全評估的時長。

▲圖1-3 從傳統模式到DevOps模式

在DevOps模式下，我們通過自動化、敏捷開發、團隊協作、微服務設計等DevOps理念和技術手段，提高了研發效能。研發階段的時長縮短了，從而也減少了整個交付周期的時長，提高了交付速度和效率。

然而，由於傳統的DevOps模式沒有考慮安全，因此上線前的安全評審時長並沒有改變。從圖1-3可以清晰地看出，在DevOps成熟的情況下，團隊繼續提高研發效能的瓶頸已經不在研發階段，而是在上線前的安全評審階段。

那麼，如何在DevOps模式下進一步改進研發效能，提高交付效率呢？另外，從安全的角度考慮，瀑布模式下的傳統應用安全模式（比如SDL）已經無法跟上DevOps模式下越來越快的交付速度了，因此需要摸索出一套適合不停迭代和快速交付的全新應用安全模式的方法論。

03 從DevOps到DevSecOps

上一節我們用一個圖簡單描述了從傳統研發模式到DevOps模式的轉變。然而，傳統DevOps主要考慮速度和質量，並沒有考慮信息安全。所以，在DevOps比較成熟的情況下，信息安全就變成了研發效能繼續改進的瓶頸。

DevSecOps的最終目的就是通過安全左移到開發測試團隊，使安全評審階段的時長變短，從而進一步縮短交付周期（如圖1-4所示）。並且它可以在更早的階段發現並修復安全漏洞，從而減少上線前發現安全漏洞的返工成本。

▲圖1-4 從DevOps模式到DevSecOps模式

DevSecOps是Gartner在2012年就提出的概念，其原始術語是DevOpsSec。2017年RSA峰會之後，DevSecOps開始成為世界熱門話題。DevSecOps延續了DevOps的理念，其設計與執行仍然處於Agile的框架之下。

DevSecOps的目標是將安全嵌入到DevOps的各個流程中（需求、架構、開發、測試等），從而實現安全的左移，讓所有人為安全負責，將安全性從被動轉變為主動，最終讓團隊可以更快、更安全地開發出質量更好的產品。

所謂安全左移，在實踐中就是為了讓團隊對他們開發的內容負責，通過將安全等工作（比如測試安全）從部署前的安全評審階段左移到更早的階段，從而更早、更快地發現並解決安全問題，而不是等到幾天後部署時才發現，或者幾個月後再發出滲透測試報告。

DevSecOps的出現並非偶然，它是軟體持續交付演進的必然產物。在這種新型軟體交付模式下，安全行為會散落在軟體交付的各個階段，而安全的職責也會落在各個階段的參與者身上，而不再是主責落在安全團隊身上。DevSecOps可以給研發效能提供諸多好處，主要表現在以下三個方面（見圖1-5）：

▲圖1-5 DevSecOps相比DevOps的好處

1. 交付更快

DevSecOps通過自動化安全工具掃描，無感地左移了部分傳統模式中在上線前最後階段進行的安全掃描工作，使整個交付周期變得更短，交付速度因此變得更快。比如在圖1-5中，由於安全評審階段時長的減少（T7），交付周期從DevOps模式下的T1，變成了DevSecOps模式下的「T1–T7」。

2. 節省成本

DevSecOps由於在SDLC前期階段發現並且修正安全隱患和漏洞，避免了傳統模式中在上線前最後階段進行安全掃描發現高危安全漏洞後進行的返工，從而從流程上節省了成本。

比如在圖1-5中，在上線前發現高危安全漏洞返工修復安全漏洞後，整個開發、測試和安全評審流程又要重新走一遍，因此額外消耗的成本就是T2時間下的人力。

在DevSecOps模式下，由於安全左移到了開發或者測試階段，因此，如果高危安全漏洞在開發階段被發現，那麼額外耗費的人力也僅僅是開發時長T4下的人力，節省下來的是「T2–T4」時長下的人力。

而如果高危安全漏洞是在測試階段被發現的，那麼返工額外消耗的人力就是「T4 + T5」下的人力，因此節省下來的就是「T2–T4–T5」下的人力。

3. 控制風險

DevSecOps減少了開發團隊對安全部門/團隊的依賴，通過安全左移讓開發團隊具備發現和修正部分安全隱患和漏洞的能力。

另外，在傳統模式下，安全部門/團隊往往扮演「警察」的角色為企業的安全提供保障，因此有時會因為安全隱患或者風險從而阻止或者延遲開發團隊交付上線。基於這種關係，因為大家的目的不同，開發團隊和安全團隊的關係往往並不是那麼融洽，有時甚至會產生矛盾。

然而，DevSecOps的目的是通過將安全左移最終讓所有人為安全負責。因此，將不再有安全「警察」的角色來監督開發團隊，而是開發團隊為自己開發的產品的安全性負責。

雖然DevSecOps是DevOps演進的必然結果，但是在DevSecOps實踐落地的過程中，仍然面臨來自技術、流程、人和文化諸多方面的困難和挑戰（如圖1-6所示）。其中技術挑戰主要來源於兩個方面：

1. 由於DevSecOps是一個全新的概念，因此市場上可選擇的開源和商用工具並不太多。
2. 現有的很多DevSecOps工具也並不成熟（比如誤報率、專業性要求高等問題），所以也增加了DevSecOps工具在推廣和使用過程中的難度。

▲圖1-6 實現DevSecOps的挑戰

相比來自技術的挑戰，人和文化方面的挑戰則影響更大。對於程序員來說，他們的主要工作是寫代碼，所以很多程序員可能缺乏相關的安全意識，並且簡單地認為安全不是他們的職責，而是安全團隊的職責。

美國威脅檢測公司Threat Stack針對北美大中小企業200多名安全、開發和運維專業人員的一項調查和報告表明，DevSecOps仍然停留在理論階段。造成這種情況的主要原因一是信息安全知識和能力並沒有得到普及，二是缺少高層的支持，業務領導者甚至對此並不鼓勵。

報告中指出，只有27%的運維團隊和18%的開發團隊配備了安全專家；超過44%的開發人員沒有接受過任何安全編碼的培訓；42%的運維人員沒有接受過基本安全實踐方面的培訓。

因此，就算有些開發人員有安全方面的意識，但他們可能不具備安全編碼和修復安全漏洞的能力，所以需要相關的安全培訓。然而，信息安全畢竟是一門獨立的學科，因此也增加了程序員的學習成本。

最後，與DevOps剛出現時一樣，作為一個全新的概念，DevSecOps的理念還沒有得到普及，因此很多時候得不到高級管理層的支持。

報告中也指出，52%的公司承認會削減安全措施，以便在截止日期前完成業務目標。68%的受訪企業CEO不允許因為安全問題讓業務交付變慢。從這個報告可以看出，如果沒有管理層自上而下的支持，DevSecOps的推動會非常緩慢，甚至停滯不前。

針對以上種種挑戰，DevSecOps也給出了對應的最佳實踐（見圖1-7），以便進一步在企業里進行推廣。比如在技術層面，DevSecOps最佳實踐強調自動化信息安全，甚至將安全掃描進一步左移到IDE階段，更早發現並修復問題，從而節省成本。

▲圖1-7 DevSecOps最佳實踐

另外，安全指標也可以作為質量門禁，用來保障交付的安全性。人和文化層面強調持續培訓和安全意識的培養，以及DevSecOps負責人和開發團隊里DevSecOps「專家」等新角色的定義。流程層面強調定期的代碼審查、紅藍對抗，通過DevSecOps度量發現研發過程中的瓶頸，以及評估DevSecOps改進的效果。

關於作者：周紀海，英國倫敦帝國理工學院博士，擁有10年以上多家國際大型銀行(巴克萊銀行、滙豐銀行等)和騰訊的DevOps/DevSecOps轉型和落地的工作經驗。從2018-2021年，在國內外30多個技術峰會、論壇和社區上分享過DevOps和DevSecOps經驗。

周一帆，滙豐科技中國高級信息安全分析師、註冊信息安全工程師、雲安全工程師。在中國和新加坡擁有多年的金融科技與信息安全行業工作經驗。目前主要從事應用系統架構安全審查、安全風險評估和DevSecOps的實施與落地工作。

馬鬆鬆，騰訊安全專家，擁有13年基礎安全領域的工作經驗。目前團隊主要負責研發漏洞管控相關的規範、流程以及自動化系統的建設和運營工作。自2019年開始關注和推動 DevSecOps在騰訊內部的探索和落地。

陶芬，武漢大學信息安全專業碩士，在國內大型互聯網公司百度工作十餘年，負責企業內DevSecOps落地和數據安全能力建設以及運營實踐。

楊偉強，滙豐科技中國信息安全部門總負責人，在大型跨國金融信息安全領域工作15年，主要研究方向包括安全開發、安全架構以及威脅建模等。

本文摘編自《DevSecOps實戰》，經出版方授權發布。

延伸閱讀《DevSecOps實戰》

推薦語：本書通過描述一家大型互聯網企業和一家大型傳統銀行的DevSecOps轉型的過程，幫助讀者淺顯易懂並且有代入感地了解如何將DevSecOps在企業內部落地和實踐。基於各類行業特點的DevSecOps實施與落地方法，是本書的主要技術要點。