百度、騰訊、小米、OPPO似乎今年談起開發(fā)安全，不說自己從傳統(tǒng)SDL轉(zhuǎn)型到DevSecOps就不能稱為創(chuàng)新。

的確，DevSecOps越來越受到周期短、迭代快的互聯(lián)網(wǎng)業(yè)務(wù)的歡迎，也成為安全界的流行趨勢。但在筆者看來，“正如喜茶好還是普洱好”一樣，將DevSecOps和SDL二元化盲目對立起來也是不成熟的想法。軟件開發(fā)過程的目標是多樣性的，有些是質(zhì)量、人員效率優(yōu)先，有些是速度優(yōu)先，也有些是安全優(yōu)先，由此可見目標決定過程。因此，需要根據(jù)不同的目標來有機整合相關(guān)的實踐以實現(xiàn)目標。

[[361141]]

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

SDL與DevSecOps對比又進入了歷史誤區(qū)

“DevSecOps”被評為年度網(wǎng)絡(luò)安全行業(yè)熱點詞匯，然而歷史似乎總在重演。正如當(dāng)年在軟件工程領(lǐng)域爆發(fā)“CMMI與敏捷開發(fā)”的爭論一樣，現(xiàn)在安全領(lǐng)域出現(xiàn)了類似的爭議。

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

• SDL是一種模型，DevSecOps是一種具體的方法，兩者相輔相成，一起進步，而不是對立的;
• SDL本身也在演進中，并已經(jīng)涵蓋了DevSecOps方法;
• 解決安全運維一體化的并非只有DevSecOps一種選擇，S-SDLC也行;
• DevSecOps與傳統(tǒng)瀑布模式的S-SDLC方法相比，也沒有優(yōu)劣之說，只是解決問題場景不同，DevSecOps也不能替代瀑布式S-SDLC。

從軟件工程學(xué)的角度看軟件安全開發(fā)

軟件安全開發(fā)的本質(zhì)目標，是開發(fā)出安全的軟件。“安全”即保密性、可用性、完整性?；谲浖こ坦芾?ldquo;過程控制、預(yù)防為主”的原則，應(yīng)該在軟件開發(fā)過程中內(nèi)建，而不是“亡羊補牢”：先開發(fā)、再檢驗、最后修補。

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

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

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

SDL的誕生和演進

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

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

早期的微軟SDL

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

適用于瀑布開發(fā)場景的新版微軟SDL

適用于敏捷開發(fā)場景的新版微軟SDL

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

• 不再強調(diào)在哪個軟件開發(fā)階段執(zhí)行哪個實踐，這使得模型能適用更廣泛的SDLC模式;
• 重視軟件開發(fā)過程中的自動化安全檢測，包含：靜態(tài)安全測試、動態(tài)安全測試、滲透測試;
• 不再關(guān)注軟件的發(fā)布過程;
• 加強開發(fā)過程中對有關(guān)人員、工具和組件的管理。

互聯(lián)網(wǎng)技術(shù)與應(yīng)用創(chuàng)新推動敏捷開發(fā)向DevOps演進

隨著互聯(lián)網(wǎng)時代的到來，信息得以快速傳遞，并呈現(xiàn)出跨界融合、創(chuàng)新驅(qū)動、重塑結(jié)構(gòu)、尊重人性、開放生態(tài)、連接一切等意識形態(tài)，對軟件開發(fā)管理帶來前所未有的沖擊。互聯(lián)網(wǎng)行業(yè)的軟件公司面臨更加復(fù)雜和快節(jié)奏的外部環(huán)境，之前在瀑布模型場景的假設(shè)被打破。創(chuàng)新業(yè)務(wù)場景多、客戶需求變化快，使得現(xiàn)有經(jīng)驗積累很難借鑒。

需要在成本可控情況下，不斷向市場交付、驗證、反饋、調(diào)整以找到準確的方向，此時準度比精度更重要，做錯方向的成本遠高于迭代修正的成本，更快的迭代速度可以獲得更快的反饋、更靈活調(diào)整，只有這樣更利于贏得市場競爭，速度成為首要考慮的因素。因此，擁抱變化、固定成本下迭代增量交付的敏捷方法應(yīng)運而生。但由于敏捷方法應(yīng)對的是快速變化的外部環(huán)境與不確定的問題，則更加依賴團隊的能力自組織、自適應(yīng)外部變化，其存在的局限包括：

• 如果迭代成本極高，這個方法就無法實施;
• 對團隊成員的綜合素質(zhì)和能力有較高門檻，很難適應(yīng)大規(guī)模的軟件開發(fā)場景，因為一旦團隊規(guī)模變大，就必然需要層級管理模式;
• 由于擁抱變化，增加了短期的靈活性，這樣操作降低過程風(fēng)險，則失去了對最終成本的預(yù)見性和可控性。

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

持續(xù)開發(fā)、持續(xù)部署

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

Exin DevOps知識體系圖

DevOps催生DevSecOps

既然有了DevOps，那么DevOps場景下，如何實現(xiàn)安全開發(fā)呢?于是安全界提出DevSecOps的方法。

DevSecOps邏輯圖

業(yè)內(nèi)首次對該模型及配套解決方案進行詳細的分析，核心理念為：安全是整個IT團隊(包括開發(fā)、測試、運維及安全團隊)所有成員的責(zé)任，需要貫穿整個業(yè)務(wù)生命周期的每一個環(huán)節(jié)。每個人都對安全負責(zé)，安全工作前置，柔和嵌入現(xiàn)有開發(fā)流程體系。

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

CI/CD邏輯圖

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

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

1. 敏捷模式是特種兵作戰(zhàn)，瀑布模式是集團軍作戰(zhàn)

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

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

2. 全量與增量的區(qū)別是人員和時間的投入產(chǎn)出比

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

全量與增量的區(qū)別邏輯圖

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

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

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

DevSecOps增量持續(xù)交付，具體微觀到每個需求單件流，也是一個典型的瀑布，也可以應(yīng)用SDL(瀑布模式)，因為SDL提出的安全實踐要求依然適用，只是實現(xiàn)這些要求的具體方法需要根據(jù)開發(fā)目標做調(diào)整。

3. DevSecOps不是唯一的選擇

DevOps強調(diào)相對之前敏捷開發(fā)方法，重點解決了開發(fā)與運維的沖突。明智的解決方法不外乎三點：

• 相互理解各自的利益關(guān)注點;
• 在更高一級統(tǒng)一優(yōu)先級;
• 通過自動化和文化理念解決二者的沖突。

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

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

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

正在導(dǎo)入DevOps的組織應(yīng)該借鑒Netflix的經(jīng)驗：從組織戰(zhàn)略層面平衡好產(chǎn)品創(chuàng)新優(yōu)化和產(chǎn)品穩(wěn)定運維的矛盾;最大化實現(xiàn)測試自動化;全面形成責(zé)任感文化。而不是糊里糊涂推動DevOps以及DevSecOps運動。你可以把馬帶到河邊，但不能逼著它們飲水。你可以去說服開發(fā)和運維合力同心，但組織文化不改，僅僅變化工具不會有實質(zhì)的改進。

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

最后的一些建議

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

• 需求范圍明確的軟件開發(fā)用瀑布模式更合適，即使是互聯(lián)網(wǎng)軟件也是如此。比如：大家可能覺得游戲開發(fā)往往采用敏捷模式，但大家參加一些行業(yè)分享大會時會發(fā)現(xiàn)，有很多大型游戲開發(fā)如果在需求明確的情況下，企業(yè)依然會采用瀑布模式;
• 迭代修復(fù)成本巨大的軟件開發(fā)過程用瀑布式更合適。比如，與硬件結(jié)合的專用系統(tǒng)軟件底層軟件，一旦有哪個部分出現(xiàn)考慮不周問題，將導(dǎo)致系統(tǒng)推翻重來、前期成本投入浪費的情況;
• 對于IoT類智能終端軟硬件結(jié)合產(chǎn)品，通常會混合采用瀑布模式與DevSecOps。相對確定的嵌入式系統(tǒng)部分軟件采用SDL，相對用戶端的云或者APP可以采用DevSecOps;
• 無法對系統(tǒng)拆分成可交付增量的，只能用瀑布模式;
• 需求范圍經(jīng)常變化，面臨密集部署的場景用DevSecOps更合適;
• 需求不確定，但開發(fā)與部署有明顯階段區(qū)別，很難持續(xù)端到端價值流動的，采用通常的敏捷方法就好，也沒必要采用DevSecOps。

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

SDL與DevSecOps有各自的適用場景，對軟件安全開發(fā)的發(fā)展都有著重要的貢獻。特別是進入產(chǎn)業(yè)互聯(lián)時代，工業(yè)4.0、基礎(chǔ)工業(yè)與系統(tǒng)軟件、大量IoT終端設(shè)備等都會大量涌現(xiàn)，均會給SDL與DevSecOps帶來更廣闊的應(yīng)用場景。

【本文是51CTO專欄作者“安全牛”的原創(chuàng)文章，轉(zhuǎn)載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權(quán)】

戳這里，看該作者更多好文