百度、騰訊、小米、OPPO……似乎今年談起開發安全，不說自己從傳統SDL轉型到DevSecOps就不能稱為創新。

的確，DevSecOps越來越受到周期短、迭代快的互聯網業務的歡迎，也成為安全界的流行趨勢。但在筆者看來，“一個好、另一個不好”的思想是不成熟的。軟件開發過程的目標是多樣性的，有些是質量、人員效率優先，有些是速度優先，也有些是安全優先，由此可見目標決定過程。因此，需要根據不同的目標來有機整合相關的實踐以實現目標。

作為專業人員，我們必須從更高階與成熟的軟件工程管理角度考慮如何做好軟件安全開發。國際標準最廣泛采用的基于WSR軟系統工程方法論告訴我們：要解決組織的問題需要基于戰略方向，從人、流程、技術與工具、方法等多個維度系統化思考。工具很重要，但也不是解決問題的萬能藥，用什么工具，不是看是不是技術先進，而是在戰略指導下，從成本效益角度綜合考慮的結果。

SDL與DevSecOps對比又進入了歷史誤區

“DevSecOps”被評為年度網絡安全行業熱點詞匯，然而歷史似乎總在重演。正如當年在軟件工程領域爆發“CMMI與敏捷開發”的爭論一樣，現在安全領域出現了類似的爭議。

現在網絡上很多文章，開始宣傳DevSecOps優于SDL，甚至出現 SDL已死的論調。其實SDL是一種安全開發模型，其對應的所謂實踐，實際就是模型的要求，用什么方法滿足這個要求，組織可以根據具體情況決定，SDL目前實際已經涵蓋DevSecOps。而DevOps是軟件敏捷開發方法的發展，DevSecOps是基于DevOps的軟件安全開發方法。因此，如果作類比，SDL相當于CMMI ，而 DevSecOps相當于敏捷開發方法，總而言之：

SDL是一種模型，DevSecOps是一種具體的方法，兩者相輔相成，一起進步，而不是對立的；

SDL本身也在演進中，并已經涵蓋了DevSecOps方法；

解決安全運維一體化的并非只有DevSecOps一種選擇，S-SDLC也行；

DevSecOps與傳統瀑布模式的S-SDLC方法相比，也沒有優劣之說，只是解決問題場景不同，DevSecOps也不能替代瀑布式S-SDLC。

從軟件工程學的角度看軟件安全開發

軟件安全開發的本質目標，是開發出安全的軟件。“安全”即保密性、可用性、完整性。基于軟件工程管理“過程控制、預防為主”的原則，應該在軟件開發過程中內建，而不是“亡羊補牢”：先開發、再檢驗、最后修補。

根據《GB/T 11457-2006 軟件工程術語》的定義，“軟件開發過程（2.1491）”是把用戶要求轉化為軟件產品的過程，此過程包括：把用戶要求轉換為軟件需求，把軟件需求轉化為設計，用代碼來實現設計，對代碼進行測試，有時包括安裝和驗收。因此，軟件開發生命周期（SDLC）通常定義為：需求、設計、實現、驗證、發布、運維6個生命周期階段。

軟件開發的過程階段可以遵循不同的“軟件開發生命周期模型”，也被稱為“軟件開發過程模型”。每個過程模型都遵循其在軟件開發生命周期所獨有的一系列階段, 以確保軟件開發成功。不同的軟件開發生命周期類型，本質是為了應對不同問題域。目前行業最主流的SDLC是瀑布與敏捷，而選擇哪一種SDLC開發軟件，需要根據不同場景的特征。見下表。

為了實現軟件的安全特性，需要在軟件開發生命周期的各階段融入安全實踐過程，以保障開發過程能產出安全的軟件，也就構成了安全軟件開發生命周期S-SDLC。因此，在瀑布型SDLC 或敏捷型SDLC融入相應的安全實踐過程就可以衍生出安全的瀑布開發生命周期與安全的敏捷開發生命周期。因此，S-SDLC實際是泛指安全軟件開發生命周期，可以是瀑布模式，也可以是敏捷模式。

SDL的誕生和演進

微軟在21世紀初期的軟件產品開發實踐中，就意識到無法通過技術層面徹底解決軟件面臨的安全風險。因此，微軟嘗試從流程和管理的角度解決這個問題，并探索在各軟件開發環節加入安全過程、把控安全風險，確保每個環節交付到下一環節的交付物都安全可控。于是，微軟產生了“SDL軟件安全開發周期（Security Development Lifecycle）”。

2004年，微軟的SDL安全開發生命周期模型（見下圖）并作為軟件開發的強制策略開始在公司實行。該模型幫助開發人員構建高安全性的軟件，并取得了巨大成功。應該說早期的這個模型，確實沒有將運維層面的實踐納入該模型。

早期的微軟SDL

2019年，隨著移動、云計算、大數據、物聯網、人工智能和其他新技術的興起，微軟對SDL進行調整，使得無論使用經典的瀑布或更新的敏捷方法（如DevSecOps），在開發的每個階段提高軟件應用程序的安全性。其中，適用于瀑布開發場景的SDL包括12個安全開發實踐，適用于敏捷開發場景的SDL包括8個安全開發實踐。

適用于瀑布開發場景的新版微軟SDL

適用于敏捷開發場景的新版微軟SDL

新版微軟SDL具有以下特征：

不再強調在哪個軟件開發階段執行哪個實踐，這使得模型能適用更廣泛的SDLC模式；

重視軟件開發過程中的自動化安全檢測，包含：靜態安全測試、動態安全測試、滲透測試；

不再關注軟件的發布過程；

加強開發過程中對有關人員、工具和組件的管理。

互聯網技術與應用創新推動敏捷開發向DevOps演進

隨著互聯網時代的到來，信息得以快速傳遞，并呈現出跨界融合、創新驅動、重塑結構、尊重人性、開放生態、連接一切等意識形態，對軟件開發管理帶來前所未有的沖擊。互聯網行業的軟件公司面臨更加復雜和快節奏的外部環境，之前在瀑布模型場景的假設被打破。創新業務場景多、客戶需求變化快，使得現有經驗積累很難借鑒。需要在成本可控情況下，不斷向市場交付、驗證、反饋、調整以找到準確的方向，此時準度比精度更重要，做錯方向的成本遠高于迭代修正的成本，更快的迭代速度可以獲得更快的反饋、更靈活調整，只有這樣更利于贏得市場競爭，速度成為首要考慮的因素。因此，擁抱變化、固定成本下迭代增量交付的敏捷方法應運而生。但由于敏捷方法應對的是快速變化的外部環境與不確定的問題，則更加依賴團隊的能力自組織、自適應外部變化，其存在的局限包括：

如果迭代成本極高，這個方法就無法實施；

對團隊成員的綜合素質和能力有較高門檻，很難適應大規模的軟件開發場景，因為一旦團隊規模變大，就必然需要層級管理模式；

由于擁抱變化，增加了短期的靈活性，這樣操作降低過程風險，則失去了對最終成本的預見性和可控性。

敏捷方法本身也在演進，開始敏捷方法主要是產品開發領域。隨著云計算應用的興起，軟件即服務也意味著為真正敏捷的交付軟件價值給客戶，必須將敏捷擴展至運維端，才能實現真正的端到端的價值流動和及時客戶反饋、快速迭代，持續集成、部署的自動化是這一方法體系的核心能力！我們稱之為DevOps。

持續開發、持續部署

下圖是Exin DevOps認證提出的知識體系。大家會發現，但其SDLC本質并沒有變化，采用敏捷方法進行管理，持續交付是其核心實踐。

Exin DevOps知識體系圖

DevOps催生DevSecOps

既然有了DevOps，那么DevOps場景下，如何實現安全開發呢？于是安全界提出DevSecOps的方法。

DevSecOps邏輯圖

業內首次對該模型及配套解決方案進行詳細的分析，核心理念為：“安全是整個IT團隊（包括開發、測試、運維及安全團隊）所有成員的責任，需要貫穿整個業務生命周期的每一個環節。“每個人都對安全負責"，安全工作前置，柔和嵌入現有開發流程體系。

RSA2018大會上出現的一個熱詞“Golden Pipeline（黃金管道）”，特指一套通過穩定的、可預期的、安全的方式自動化地進行應用持續集成/部署的軟件流水線。相比復雜的雙環模型，Golden Pipeline無疑是一種便于理解和落地的實現方式：

CI/CD邏輯圖

在整體方案中，綠色部分為安全相關的工作內容。與傳統SDL不同的是，除了CD后期的安全檢測，其它階段的安全工作通常為開發團隊負責或干脆實現了完全自動化。主要是將部分測試相關的安全實踐通過工具化實現了自動化。

正確認識瀑布模式的S-SDLC與DevSecOps

1、敏捷模式是特種兵作戰，瀑布模式是集團軍作戰

現在網上經常被人拿來與DevSecOps做對比的SDL，主要被認為SDL代表的是以瀑布模式的S-SDLC，而當時SDL主要基于微軟的軟件產品開發場景。我們知道微軟此前產品主要是系統級軟件或者工具軟件，開發周期相對較長、需求范圍相對明確，而且變化相對可控并不會太頻繁。同時，系統復雜性和團隊規模很大，每次軟件系統進行迭代和返工的成本極高，必須保證每個階段交付的正確性。據說，微軟為此當時軟件開發工程師與軟件測試工程師的配比為1:1甚至1:2，而且這類軟件，并不需要密集的部署和交付，在開發與運維之間是有明顯階段的。DevOps開發運維一體化，根本沒有必要。這種場景下，是比較適合采用瀑布模式的。由于整個項目周期較長，軟件質量是首要考慮的因素，實施安全實踐對項目的效率和進度影響并不明顯。因此，以SDL為指導模型的瀑布模式的S-SDLC方法可以很好的在這樣的場景落地，并取得實際的成功。

如果說敏捷是特種兵作戰模式強調靈活應變，那么瀑布模式就是集團軍作戰模式，要求周密的計劃和控制。全球95%的500強企業采用的IPD產品開發體系，其生命周期模型也主要是采用的瀑布開發模式。

2、全量與增量的區別是人員和時間的投入產出比

從實際情況來看，無論是瀑布模式還是敏捷模式，在需求價值這個顆粒度上的生命周期其實是一致的，只是瀑布模式是全量而敏捷模式是迭代增量。但是對于安全實踐的落實卻造成了影響，見下圖。

全量與增量的區別邏輯圖

假定我們同時有10條需求，如果按瀑布全量交付方式，安全實踐只需要一次集中處理10條，再轉給下一個環節。這樣對團隊的人員效率是最優的。但在增量交付時，我們會發現，安全實踐同樣要處理10條需求，但必須要在不確定的時間點去完成。價值流動效率最優，但人員效率就不高了。如果在DevSecOps環境下，安全實踐由安全人員來支撐，理論上需要的安全團隊會更為龐大，這在許多公司顯然是不可接受的。

另外，由于每次交付的周期變短了，速度成為關鍵制勝因素，任何對速度的影響都會對業務造成明顯的阻礙。速度與安全都是業務的屬性，都需要投入成本，速度與安全的“沖突”，本質是對各維度投入產出的綜合考量。要實現魚與熊掌兼得，除了在更高一級維度平衡外，唯有通過自動化工具才能緩解但并不能完全消除。

如果從開發安全軟件的核心要素考量，其實本身并不在于全量交付還是增量交付，而在于在每個給客戶的可交付增量的開發各階段是否有融入合適的安全實踐。舉個例子，如果你沒有對需求進行安全需求的識別和分解，后面設計與測試工具再快，同樣無法實現預期的安全目標。同樣，沒有進行安全設計，后面測試做的再好、再快，也無法有效實現預期安全目標。

DevSecOps 增量持續交付，具體微觀到每個需求單件流，也是一個典型的瀑布，也可以應用SDL（瀑布模式），因為SDL提出的安全實踐要求依然適用，只是實現這些要求的具體方法需要根據開發目標做調整。

3、DevSecOps不是唯一的選擇

DevOps強調相對之前敏捷開發方法，重點解決了開發與運維的沖突。

明智的解決方法不外乎三點：

 相互理解各自的利益關注點；

在更高一級統一優先級；

通過自動化和文化理念解決二者的沖突。

DevOps解決沖突實際是采用的第3種方法，但第2中方法同樣可以解決問題。

Netflix（奈飛）的專家在一次DevOps大會發言，值得我們思考和借鑒。Netflix的業務場景需要面臨每天數千次的變化與上線壓力，絕對非常適合采用DevOps，而Netflix的軟件開發實踐絕對是業界的標桿，但他們專家卻在報告中多次強調 “Netflix不關注DevOps，因為通過公司文化、過程、技術工具、信任，我們已經避免了開發和運維的沖突。沒有沖突，也就不需要DevOps”。

開發樂于創新、變革，而運維則希望持續穩定。如果不在更高一級的公司領導層面確定優先級的話，必然導致僵局。奈飛選擇了創新，他們不追求完美的7×24小時系統的可靠，愿意承受一些招致可靠性風險的問題也要鼓勵產品的創新優化。這個共識滲透了開發團隊和運維團隊，二者的沖突根本就沒有機會造成傷害。因此，也就不需要DevOps了，自然也就不需要DevSecOps了。

正在導入DevOps的組織應該借鑒Netflix的經驗：從組織戰略層面平衡好產品創新優化和產品穩定運維的矛盾；最大化實現測試自動化；全面形成責任感文化。而不是糊里糊涂推動DevOps以及DevSecOps運動。你可以把馬帶到河邊，但不能逼著它們飲水。你可以去說服開發和運維合力同心，但組織文化不改，僅僅變化工具不會有實質的改進。

開發運維一體化的安全開發，除了DevSecOps，企業通過整合S-SDLC、戰略文化、組織流程、工具方法，也同樣可以找到更適合自己的方法，Netflix給我們提供一個很好的案例。

最后的一些建議

如果要粗略給企業建議是用瀑布式S-SDLC方法（下面簡稱“瀑布模式”）還是DevSecOps的話，行業較為普遍的做法可供借鑒：

1.需求范圍明確的軟件開發用瀑布模式更合適，即使是互聯網軟件也是如此。比如：大家可能覺得游戲開發往往采用敏捷模式，但大家參加一些行業分享大會時會發現，有很多大型游戲開發如果在需求明確的情況下，企業依然會采用瀑布模式；

2.迭代修復成本巨大的軟件開發過程用瀑布式更合適。比如，與硬件結合的專用系統軟件底層軟件，一旦有哪個部分出現考慮不周問題，將導致系統推翻重來、前期成本投入浪費的情況；

3.對于IoT類智能終端軟硬件結合產品，通常會混合采用瀑布模式與DevSecOps。相對確定的嵌入式系統部分軟件采用SDL，相對用戶端的云或者APP可以采用DevSecOps；

4.無法對系統拆分成可交付增量的，只能用瀑布模式；

5.需求范圍經常變化，面臨密集部署的場景用DevSecOps更合適；

6.需求不確定，但開發與部署有明顯階段區別，很難持續端到端價值流動的，采用通常的敏捷方法就好，也沒必要采用DevSecOps。

所以，如果從實際應用場景來看，SDL主要用于指導企業研發管理體系的完善和融合，而具體瀑布模式S-SDLC和DevSecOps是解決問題域的方法，在企業策略指導下可以選擇性采用。

SDL與DevSecOps有各自的適用場景，對軟件安全開發的發展都有著重要的貢獻。特別進入產業互聯時代，工業4.0、基礎工業與系統軟件、大量IoT終端設備等都會有大量涌現，均會給SDL與DevSecOps帶來更廣闊的應用場景。（開源網安 宋荊漢）