作者 | liumiaocn
出品 | CSDN博客
封圖| CSDN 下載於視覺中國
2019年DORA發佈了DevOps的研究報告，迄今為止這已經是DORA的第八次報告的發佈。相較於往年的報告，2019年的報告全篇只聚焦於一個要素：安全。
在2018年DORA提供了一個包含五個步驟的模型來幫組企業更好地開展或者推進DevOps的實踐，而將安全與DevOps實踐進行融合的時候，往往發現會存在很多困難，這份報告將會從多個方面對安全的融入進行展開分析。接下來讓我們來看一下這份報告能夠給我們帶來哪些啟迪。
研究人員
隨著理念的推廣，DevOps不再只停留在詞彙和概念的程度上，已經得到了普遍的接受和認可。與2018年類似，這份報告的主導者仍然是puppet和splunk，除此之外加入了一個新的成員circleci，很有趣的事情是主要作者仍然是下面的四位，連頭像都沒有變化，唯一的區別是是Michael Stahnke從puppet的director of engineering變成了circleci的VP。不過這些對讀者來說並不那麼重要，大家所關心的是他們的產出所能帶給我們的啟發。
安全融入所帶來的挑戰
安全是一個非常重要的概念，需要給予足夠的重視，這個想法深入人心，但是在很多項目進行安全實踐相關的融合時，都會發現這個想法顯得過於理想化，觀念上的重視和事實上的輕視在實際的實踐中同時被展現了出來。
安全增強相較於功能特性的增強，對於企業來說，並不能時時清晰可感，它更像保險，只有安全事故出現的時候才會覺得後悔，所以特性增強一般會排在首位，其次才是安全增強，而實際上排名“其次”的第二名永遠都得不到足夠的重視，後面我們也將會使用一些數據來佐證這個觀點。
在這份報告中，對企業在實施DevOps轉型時如何進行安全融入、以及安全融入對企業的產出的影響，都在報告中給出了結論。
內容概要
1、DevOps的實施會對安全帶來正向影響
一般來說，需要在DevOps實踐中進行安全融入的企業都是那些已經走過初期階段企業，DevOps的實踐已初見成效，需要在整個企業內部進行展開，這種情況之下，自然需要在安全上進行進一步的強化。
解讀：在2019年的調查報告中，DevOps實踐很好的團隊之中有高達22%的比例達到了安全集成的最高級別。DevOps的CAMS在安全的融入方面同樣起效，可靠性、可預測性、可測量行和可觀測性不僅僅帶來了安全的環境，更為重要地是將這一切結合了自動化之後所帶來的安全事件響應速度的效率提升。
好的DevOps文化能夠支持更嚴格的安全策略的貫徹執行，在有著Sharing（分享）的文化的團隊之中，團隊使用通用的工具，合力完成共同的目標，安全也自然成為了一種共同的責任，在這種文化之下，“部門牆”會相對更為容易跨越，在問題出現的時候，自然也會得到最早地解決。
2、在軟件交付中深度集成安全使得團隊更加自信
根據調查報告顯示，安全級別達到最高級別的受訪者有82%對公司的安全有足夠信心，而沒有進行安全集成的受訪者中，這一比例僅達到38%，這一調查結果充分顯示在軟件交付中，深度集成安全使得團隊更加自信。
解讀：集成安全並不只是簡單的“左移”，而是需要從整體上進行解決，比如強調跨團隊的協作、增強自動化在檢測和預防方面起到的作用，同時需要打破部門之間的知識孤島，使得成員都能夠參與進來。在安全改進方面使用的最為廣泛的幾種實踐如下所示：
團隊協作：基於威脅模型分析，安全團隊和開發團隊增強合作應對安全威脅
工具集成：安全工具集成到開發的流水線中，可以增強開發工程師對於其開發的代碼中不會引入已知的安全問題的信心。
安全需求 ：從功能性和非功能性綜合考慮，將安全相關的需求列到產品任務清單中。
人工評審：從安全專家的角度對於自動化測試進行評估，重點包括那些具有較高風險的代碼變更內容，比如認證和加密相關部分。
基礎框架安全：與基礎框架相關的安全策略需要在部署之前進行評審。
重點：所有的這些內容大多數公司都知道應該做，但是往往因為種種原因卻沒有去做，這是一種普遍的情況。
3、在軟件交付生命週期集成安全會帶來積極結果
調查報告發現：
生產環境的按需部署效率提升：安全集成級別較高的受訪者所在公司在按需進行生產環境部署方便達到了61%的比率，而安全級別較低的受訪者所在公司在這一比例僅能達到49%。修復時間相差不大：調研之前的假定認為安全集成級別較高的公司能夠更快部署、更快修復安全性問題，但是實際反饋結果顯示在修復問題的時間方面目前相差無幾。
安全改善效率更高：安全集成級別較高的公司能夠在進行功能特性交付的時候更加有效的強化安全改善，在發現交付只生產環境處理安全問題時的處理更有效率。
解讀：在軟件交付生命週期中安全集成地越深入，交付團隊對於團隊共同安全責任的理解更加清晰，同時對於對於潛在的對於業務的風險也會降低地更多，安全問題也會得到更多的重視。
4、中間過程可能會是混亂和難熬的
正像DevOps個別的成功推廣開來碰到的問題一樣，中間的階段和過程可能是混亂無序、非常難熬的。在項目剛開始的時候，很多未知的問題和障礙還未出現，還沒有大面積普及的情況下，往往較為順利的看到了預定的結果，但是很快隨著集成的深入，很多問題就會出現，這就是非常難熬的中間階段。安全集成也是這樣，往往解決了一個問題，就會引入一個新的問題，我們不知道這漫長的中間階段到底有多長（不過根據經驗來看一般比想象的要短，但是難熬的日子往往覺得很漫長）。比如如下是2018-2019年的中間階段的企業的比例構成：
解讀：在難熬的中間階段，安全的融入所需要的協作、溝通甚至有時會拖慢交付的速度，安全審計的問題會增加，這些都會帶來額外的工作和注意力，需要組織級別同時相應地根據情況進行變化以適應，但是這都是中間階段所需要處理的細節問題。抱著必定得到拯救的信心堅持下去吧，光明就在前方，除此之外我們也別無選擇。
而從2018和2019年連續數據也能夠佐證這一觀點：雖然整體在不斷成熟，但是除去做的非常完善的和尚未起步的，連續兩年卡在中間的企業都高達79%，說明DevOps演化還將是一個長期的過程。
數據來源
1、區域
整個亞洲佔到整體調研數據的19%
解讀：按照國家來確認，中國的反饋佔到這19%的8%，所以這份調研報告所能體現出中國在其中的比例大概為1.5% （19% * 8 % ），所以這又是一份基本不能代表2019年中國DevOps最新發展狀況的數據，但是對於整體的發展趨勢可以有所瞭解。
2、行業與規模
科技與金融仍然撐起半壁江山，而零售/通信/教育/醫療/政務/健康/保險/製造等主要行業也達到40%左右，整體行業均有涵括，非盈利的機構依然能夠佔到1%的比例。
2019年對組織大小的判斷繼續延續2018年的方式，定義在年度營業收入，使用annual revenue將組織進行劃分，10億美元以上的組織佔到28%，相較於2018年略有提高，相較於2018年低於100M$營收的公司44%的比例下降至30%，其餘規模的組織比例也較為均衡。
3、角色
受訪者仍然以管理人員偏多，IC（Individual Contributor）僅佔26%，這一比例很巧合地跟2018年完全一致，其他成員的比例也大體相差無幾。
4、DevOps團隊
隨著DevOps理念和實踐的不斷推廣，與DevOps團隊相關的工作人員也開始逐年遞增，以下是到2018年DevOps團隊的佔比情況：
在2019年，由於團隊的人員的職責進一步細化，在2019年顯示的DevOps團隊僅佔22%。
解讀：看似下降的比例，但是考慮到如下三部分都屬於DevOps的範圍，比例已經為22% + 4% + 2% = 28%
Site reliability engineering：4%
Release engineering：2%
DevOps：22%
同時在2019年重點融合的安全相關的部分，也同樣可以認為是DevOps團隊的延伸，所以結合起來仍然在進一步上升，名稱可能有所變化，但是方式和職責明顯是更為細化和清晰。
Information security / security operations：6%
Compliance & audit：1%
DevOps實踐中的安全集成
1、DevOps的演進模型中的安全集成
在2018年的報告中提出了企業在DevOps演進時的5個階段的模型如下所示：
我們可以看到在第4階段中通過自動化安全策略配置來幫助DevOps在安全方面升至第5階段，而第5階段的一個關鍵實踐就是自動化的事件響應，同時安全團隊在設計和開發的階段都進行融入都是第5階段需要做的事情。
2、安全集成的模式和實踐經驗
DORA八年的DevOps調研結果顯示：當運維需求集成進軟件交付流程中，更快的部署、更少的錯誤、更省時的修復、更少的手工作業都是可以期待的，同樣在安全集成的時候在如下方面將會有哪些影響也是我們所關注的：
主要的軟件交付性能指標
安全問題的響應
組織發現安全問題的方式
對待審計的態度和方式
解讀：成功的DevOps實踐可以將本來形同水火的開發團隊和運維團隊變的親密無間，同樣事情在進行安全的集成也是類似的，好的安全集成可以將互相看不慣的開發運維團隊和安全團隊變得不分彼此，這樣安全問題才會真正成為每個人下意識會去關注的。
3、安全集成的困難之處
安全實踐在實際的項目中往往扮演著一個“麻煩製造者”的角色，安全往往被視作部署的瓶頸，它往往發生在交付週期的最後階段，這些檢查往往是手工的，所以往往是造成延遲的重要原因，而一旦查出安全問題，往回意味著開發、測試和運維團隊需要對應一些額外的未被計劃的工作，這往往使得已經延遲的交付進一步加深。在現實的世界中，往往新的特性快速地投放才是重中之重，帶著一些未解決的安全問題先行將特性上線的做法也並不罕見，這種情況下，當時的想法一般會是“在下一個版本中一定要堵住這個有風險的安全漏洞”，但是一旦上線，出於各種原因，就忘記了還有一個洞沒有補，導致安全相關的技術債務不斷積累。在加上漫長難熬的DevOps演進的中間階段，安全的集成在實踐中舉步維艱。但是在這個過程之中，我們還是能夠發現一些無論是DevOps演進還是安全集成時都會通用的實踐經驗：
逐步改善的中間過程：中間階段需要處理的問題非常廣泛和複雜，在流程上需要組織跨團隊協作以解決手工評審等步驟，同時需要通過自動化來增強管控和追蹤性。
協作和分享：早期可以通過協作與分享（不僅僅包括信息的分享，還包括責任的共擔）很好地進行改善的環節。
自動化：在演化的過程中，團隊可以使用自動化來解決很多痛點，比如自動部署、比如自動事件響應和自服務能力。
4、DevOps vs DevSecOps
這份調研報告中特意提到了一個詞：DevSecOps，但是DORA認為，安全應該只是DevOps實踐中的一個部分，但是通過DevSecOps能夠廣泛引起企業對於安全的重視是值得稱道的。
5、安全集成的現狀
2019年度對於統計的數據進行分析之後，發現處於非常低的階段Level 1（Level 1 ～ Level 5的說明在後續章節展開）的受訪者只有6%，達到最高安全級別Level 5的比例達到22%，而在通過對於DevOps演進進行分析，也能夠發現安全集成在整體起到越來越重要的作用。
6、DevOps演進 & 安全集成
2019年度關於安全集成和DevOps演進的結論:
DevOps演進能夠更好地推進安全實踐的落地，對於希望對於安全進行改善的組織，繼續踐行DevOps是一個不錯的主意。
安全集成級別
1、安全集成的級別界定方法
對於受訪者安全級別的界定，2019年度是通過對於問卷的內容進行設計來達到的，首先需要確認安全在軟件交付週期的哪些環節被引入：
需求
設計
構建
測試
部署
根據受訪者在上述環節安全被引入的狀況來界定安全集成的等級：
Level 1:無集成（在任何一個階段都未進行安全集成）
Level 2:較低程度集成（在一個階段集成了安全）
Level 3:一般程度集成（在兩個個階段集成了安全）
Level 4:較高程度集成（在三個或者四個階段集成了安全）
Level 5:最高程度集成（在所有階段集成了安全）
雖然重點研究落在了軟件交付之上，但是從運維角度關於生產環境中安全集成方面也在如下的一些環節進行了確認：
脆弱性管理與修復
安全策略自動化
審計發現與響應
2、安全集成現狀
通過對於受訪者的反饋進行分析，各個級別的比例分佈大體如下所示
注意：整體比例加起來是101，可能又是一個無傷大雅的小問題，對於整體狀況的把握沒有影響。
另外，從Level 2 ～ Level 4由於存在多種組合的可能性，經過調研發現如下模式在目前階段最為常見：
Level 1:僅在生產環境安全事件報告時或審計發生時才會驅動安全相關的工作
Level 2:在測試階段集成安全
Level 3: 在測試和部署階段集成安全
Level 4:在構建、測試和部署階段集成安全
Level 5:在需求、設計、構建、測試和部署階段集成安全
3、改善方式
大多數組織對於安全的改善使用了一種迂迴的策略，比如關於身份識別和權限控制等都是常見的實踐，但是很多企業都沒有嚴格地完整地去做這件事，因為在實際實施中非常困難，
這些嚴格的控制可能會拖慢所有事情的進度，在時間成本和效率上將會付出昂貴的代價。而經過調研也發現了真正有效並能夠帶來正向結果的改善方式：從軟件的規劃和設計開始，對每個階段進行安全相關的控制才能從整體上帶來正向的效果。但是如何才能使得安全能夠更容易地進行改善，能否以一種更為敏捷的方式進行，通過不斷地迭代來完成？答案也非常簡單，重點在於構建增強安全意識的文化，交付團隊的成員需要能夠具有足夠的知識和自動化的手段予以定位安全問題、瞭解安全問題的處理有限度、具有處理安全問題的足夠知識，在此基礎上對於安全意識的增強才能夠真正落到實處。
4、安全集成與信心的增強
在2019年度的調查問卷中設計了內容用來確認安全集成程度與團隊成員信心之間的關聯度，從下圖可以清晰地看出整體來說信心隨著級別的提升而提升。
解讀：在安全集成程度最高級別的受訪者中有82%的程度表達了他們的信心，而在沒有任何集成的階段這一比例只有38%。可以看到即使是隻有最簡單程度的集成也能在安全信心方面給團隊帶來明顯的效果。持久的信心非常只重要，因為它能真實體現團隊成員對於安全現狀的認識，虛幻的信心是無法經受實踐的檢驗的，團隊持久的信息實際來源於實際上真正安全的現狀，這樣在價值的交付時才能做到真正地安全、快速和穩定。
另外，需要意識到更為重要的是安全並不僅僅是將一些安全實踐比如滲透測試或者靜態代碼檢查等提前開始，需要改變和重點關注的是跨團隊的協作和責任的共擔。
5、行之有效的實踐建議
報告中還列出了一些對於安全集成有效的實踐建議，可以在使用時進行參照：
團隊協作：基於威脅模型分析，安全團隊和開發團隊增強合作應對安全威脅
工具集成：安全工具集成到開發的流水線中，可以增強開發工程師對於其開發的代碼中不會引入已知的安全問題的信心。
安全需求：從功能性和非功能性綜合考慮，將安全相關的需求列到產品任務清單中。
人工評審：從安全專家的角度對於自動化測試進行評估，重點包括那些具有較高風險的代碼變更內容，比如認證和加密相關部分。
基礎框架安全：與基礎框架相關的安全策略需要在部署之前進行評審
主要變更評審：對於主要的代碼變更在部署之前進行安全人員評審
安全特定的測試：對於安全相關的特定測試，比如測試應用的使用權限和數據訪問權限等。
自服務：開發者可以配置按需進行包含安全設定的基礎框架和環境
設計融合：安全需求被視作普通的設計需求進行處理
輕微變更評審：對於輕微的代碼變更在部署之前進行安全人員評審
安全評審：應用代碼發佈至生產環境後出發安全評審
滲透測試：包含並不僅限於脆弱性相關測試或者黑客工具測試等
基礎框架配置：基礎框架可以進行在安全審批的流程基礎上進行自動化配置
依賴檢查：對於應用和環境進行相關的依賴檢查以確認整體的安全性狀況
靜態代碼分析：使用靜態代碼分析工具對於應用進行安全性和脆弱性問題的檢查
6、經驗總結
基於威脅模型的團隊協作
來自於交付團隊、安全團隊和業務關係人等各方人員一同對於安全相關的威脅常見威脅模型，並進行分析，以確認應用和支持應用的基礎框架所潛在安全風險，以及出現問題時相關的應對措施。威脅模型有助於在項目最早期的階段進行規劃和設計，同時有助於在開發團隊、安全團隊以及業務團隊之間建立信任和同理心。
工具集成提升開發團隊的信心
工具並不能解決所有的安全問題，也不存在一個解決所有安全問題的工具，但是可以通過集成工具將例行繁瑣的任務進行自動化以提高效率和節省時間，比如可以將靜態安全工具的檢查對於安全相關的脆弱行的分析進行例行的集成，通過這些工具的集成使得開發成員在開發階段就可以快速定位可能存在的風險，而在這個階段進行修改的整體成本也是較低的。
在敏捷迭代過程融合安全
隨著敏捷理念的深入人心，代碼的發佈也正在使用一個小而快的方式在迭代週期中不斷進行。敏捷方式有助於持續學習和改進，但是對於傳統方式下的安全需求的實現則較為困難，因為傳統方式往往安全策略的檢查等都是手工方式，另外開發團隊內所缺少的安全相關知識和經驗才是最重要的問題，而實際上這也是融合時的難點所在，有了這樣的團隊成員在定義敏捷的DoD的時候才有可能將安全需求以可驗收的方式提前指定，才能真正地在敏捷開發中融合安全需求。由於大型企業往往是有一個統一的中心化的團隊來對所有應用開發團隊的交付安全進行統一管控，所有很難保證每個項目都有自己的專門安全人員，所以一個較為折中的方式則是鼓勵開發團隊成員或者運維團隊成員能夠具備這方面的知識以幫助團隊在快速的迭代中能夠進行性安全的融合。
基礎框架相關的安全評審
使用諸如CIS Benchmark這樣的參考，對於進行基礎框架相關的評審是一個不錯的想法，但這是一個開始，每個項目的基礎框架都有可能不同，這就需要安全團隊和運維團隊一同協作，在部署之前對於基礎框架的變更或者引入可能會導致的各種問題進行知識和經驗的交換，並在此基礎上進行深入探討和評審以保證部署的安全性。
對高風險的代碼變更進行安全專家的評估和自動化測試
傳統方式下，應用只有在UAT或者準生產環境中，可會受到安全團隊的手工確認，如果將此部分的內容進行左移，在更早的階段由開發這能夠通過檢查或者自動化測試確認這些風險和不合適的配置，修改的成本將會更低。由於脆弱性的存在有非常廣泛的可能性：三方組件、服務器、數據庫、網絡設備、防火牆、雲存儲等，為了防止被攻擊，我們需要跨團隊（比如包括開發、運維、網絡、存儲、中間件、雲計算等）進行深入的知識共享以確保我們的檢查和自動化測試是與時共進的，而這些自動化的檢查和測試也將安全人員從瑣碎的工作中解放出來，可以一起完成一些根據有意義的工作，比如：
和交付團隊一起協作確保和測試應用以保證安全性
給予錯誤的配置已反饋以避免類似的錯誤配置重複出現
對於高風險的代碼變更進行安全相關的評審
實踐經驗的頻度和影響度矩陣
根據經驗使用的頻度以及影響度進行劃分，上述列出的實踐建議的分類如下所示
7、軟件交付生命週期安全集成與正向效果
在軟件交付生命週期進行安全集成，會在多個方面帶來正向的效果，這包括
8、部署頻度
在2019年的調查研究中，設計了“部署能力”和“實際部署頻度”的問卷，主要用於確認技術和流程是否對於業務需求的部署有所限制。詳細的能力結果如下圖所示
解讀：從反饋的結果來看也能看到即使是沒有做任何安全集成的組織，也可以做到按需部署或者至少一天兩次的這種能力，相較於8年之前的調研結果已經發生了翻天覆地的變化，當時部署甚至仍然是按照月的單位來進行衡量的。部署頻度穩定地得到了提升，在2017年高能效的組織就可以實現一天多次的部署了，之前是等待部署能力是限制要素，而現在更多的情況已經發生變化，部署能力已經就緒，但是限制要素變成了實際的需求等依賴了。
需要注意的是Level 3，相較於Level 2，按需部署的能力有了明顯的下降，這也體現了我們所提到的“痛苦的中間階段”的描述，這可能是和安全集成交互在走向成熟的過程中的反覆，而在Level 4和Level 5就開始重新正向的提升了，而Level 5的按需部署能力更是達到了61%，而實際的按需部署也達到了34%之高。
9、重要安全問題的修復時長
調研之前的假定認為安全級別越高，修復重要安全問題的時長應該會非常明顯的降低，而2019年的調查結果卻顯示並非如此，首先很少有受訪者能夠在1小時之內修復安全問題，大多數會在一週之內修復安全問題，具體來說：
只有7%的受訪者能夠在1小時之內修復安全問題
32%的受訪者在1小時～1天之內修復安全問題
33%的受訪者在1天～一週之內修復安全問題
詳細按照各個安全級別對於重要安全問題修復的時長的比例統計，詳細信息如下圖所示
解讀:從這附圖中我們可以看到：
- Level 5的受訪者中11%可以在1個小時之內修復重要安全問題，相較於Level 2～Level 4的6%，由於目前整體水平不高，還是有較大差距的。
- 觀察修復時長在1小時～1天範圍之內的統計信息可以發現，Level 1的受訪者中有31%能達到此水平，而Level 4和Level 5分別能達到38%和39%，還是有些許的提升的，而中間的下降仍然考慮到是“中間階段”所帶來的反覆，同時也是由於更多溝通協作的引入，在成熟之前顯然後拖慢相應的速度，顯然自動化或者相應的流程改善還有很多餘地。
10、安全改善 vs 特性交付
安全改善肯定是需要做的，但是是不是立即要做，在現實的世界中往往需要和特性交付進行平衡，而需要交付的特性往往是那些已經承諾給客戶了的，在這種情況下，安全集成程度高的公司在這方面能更好地保證安全改善的切實執行，這很有可能是因為安全的重要性和其價值已經在這些組織中得到了廣泛的共識，而在整個DevOps演進的過程中也是這樣，只有DevOps演進程度更高的公司在實踐這些原則的時候才能做的更好。
但是這個數據顯然還有很多改善的餘地，
比如在安全等級最高的在抉擇的時候仍然是49%的選擇安全改善，51%的仍然會選擇特性交付，潛臺詞就是，我知道系統這種方式直接交付會有風險，但是不按時交付特性，我會有風險。特性的交付非常重要，忽視安全改善，忽視數據安全，往往會帶來巨大的損失，比如美國徵信巨頭Equifax，洩露了高達1.47億用戶的信息，被洩漏的信息包括姓名、社會安全號碼（SSN）、出生日期、地址、駕駛證號碼等，賠償達到7億美元。市場競爭激烈，當然儘早進行特性的交付能夠更好地佔得一席之地，但是安全同樣不容忽視，如何進行平衡是需要考慮的重點內容，否則一旦出現安全問題，也會出現巨大損失，同時對口碑也將會有不小的影響。
11、為安全改善停止部署
經過調研發現，安全集成程度較高的公司可以為了對應額各種類型的安全問題更好地停止部署，詳細信息可以參看下圖：
因為發現了安全的問題停止部署，看起來是非常容易的事情，但是如果這個流程執行高效的話，還需要至少考慮到恢復也能夠很快地重新正軌。當然最為重要的還是降低了風險，使得系統免受了可能的風險。
解讀：停止部署這件事情背後的意義在於，在一個大型的項目之中，因安全問題停止部署這樣的決定往往是一箇中心化的安全團隊來做的，而現在將能力賦給了交付團隊，充分體現了分享的另外一層含義：責任共擔，這也是安全集成級別高的團隊所體現的一個重要特點，所有的團隊成員對於安全的意義和責任能充分意識，這種做法也避免了傳統方式下可能出現的官僚做法。
12、安全責任共擔
在傳統的大型組織中，安全往往被視作安全團隊的責任，主要原因是，安全是一個比較專業的領域，包含的專業知識角度；另外，思考的方式往往與普通編碼作業有所不同：更多的考慮代碼失敗的方式而不是正常動作的方式；開發者更為關心如何更快構建和發佈新的特性，而在安全團隊成員來看，這可能並不是最重要的。一個整體的安全集成方式可能包含：在需求階段識別的安全需求、編碼階段遵循的安全代碼規約、測試階段的脆弱性持續測試、生產環境的日誌和監控。
修復的階段與成本
而所有的這些：整體的安全集成以及安全責任共擔都是為了能在更早的階段發現安全問題，根據IBM的一項研究，顯示缺陷的修復越早成本越低，在實現階段的成本是設計階段的6倍，而在測試階段則上升至15倍，而部署至生產環境之後此成本則上升至100倍。而對於安全缺陷，所付出的成本可能會更高，比如一旦攻擊者利用生產環境中的漏洞獲得現金賬戶，將直接導致實際的資金的丟失的巨大風險，另外數據也可能會被賣給競爭對手，客戶數據的丟失還直接會使地公司被訴訟至法院，同時可能會丟失客戶的信任和市場的份額，這些都不是危言聳聽。
外部依賴與安全問題
另外，很容易陷入的一個思維誤區就是僅僅考慮代碼自身所導致的安全問題，而實際上在現代的系統中，幾乎不可避免的受到各種開源工具或者相關的開發框架以及依賴的影響，這些關聯的外部依賴是否有安全問題也是系統整體安全所必須考慮的問題。根據Snyk在2019年關於開源安全的調研報告，當今軟件中整體來說有接近78%的脆弱性問題就是由於這種間接的依賴所導致的，所以修復這些關聯部分所產生的安全問題顯得尤為重要。
安全共擔的意識
調查顯示，安全集成程度越高，對於安全應該是共同承擔的責任這一意識的認同度越高，從下圖的調查統計數據中可以看到Level 1和Level 5之間的差距達到31個百分點之多。
無論是安全團隊人員還是普通成員，對於安全責任共擔這一觀點基本相同，詳細比例可參看下圖
13、安全集成 & 審計結果
在2019年的調查中就安全審計和所確認出來的三類安全性問題的頻度進行了確認：需要立即更正的問題、需要作為較高優先度更新的問題以及較低優先度需要更新的問題，詳細內容如下圖所示：
可以清晰地看到，審計所能發現的這三種類型的安全問題，隨著安全級別的生狗都是有一個明顯的爬升和回落的狀態。
解讀：Level 1基本沒有安全相關的集成，自然發現的問題較少，而Level 5則是較為成熟，很多問題在早期階段就已經處理，同時大部分既存的問題也都得到了解決，是安全問題本身就很少的成熟階段，而中間階段是逐漸開始深化安全集成的部分，自然會發現很多的問題需要對應，這和前面的結論也能夠保持一致。
14、J曲線效應
安全集成的確能夠帶來正向的效應，但是通往成功的道路並非一帆風順，本文已經多次介紹過一些安全集成時的一些J曲線效應（本應該上升的趨勢卻在早期顯示為完全相反的趨勢，只有越過這個階段才能顯示出原本應該顯示的趨勢）
2016年的研究報告發現：中等績效者會比低績效者還要花更多的時間在rework上。
-
2017年的研究報告發現：中等績效者會需要比低績效者做更多的手工作業
解讀：這都顯示了J曲線的效應，一旦開始改善，打破原有的流程、規範和方式，反而可能會帶來一定的負面效果，套用一句常用的話來進行總結：前途是光明的，道路是曲折的，內心是堅定的。至於卡在中間的探索者能夠看到最後的光明還是死在黎明前的至暗時刻，這不僅僅是勇氣和毅力的考驗，還有團隊的支持和理解都非常重要。
團隊間的摩擦
而關於安全集成是否能夠以一種非常和諧的方式進行，如下圖所示的J曲線再次施展了它的魔力。
而J曲線也不因是否是安全團隊的成員而改變它的形態
解讀：這也使我們清醒地認識到，安全的集成所需要的跨團隊的融合，在達到成熟之前是無法避免摩擦的存在的，所以正視摩擦的存在，堅定信心最終是能夠跨越這個困難的終結階段的。
拖慢了的交付速度
而關於安全集成和軟件交付速度之間，同樣存在類似的問題，安全集成成熟度正處在中間的Level 3的受訪者有48%認同安全集成是拖慢軟件交付的重要原因之一。
解讀：每次當我們覺得已經做好足夠心理準備來面對可能會出現的J曲線的反覆，數據會告訴我們，我們還沒有做好準備？所以當有48%的處在Level 3的身處其中人會認為安全集成和改善確實拖慢了交付速度的時候，當我們按照這個節奏成為這48%之中的一員時，我們還能否說出：前途是光明的，道路是曲折的，內心是堅定的？
發現了更多問題
J曲線再次不負眾望，再次告訴我們，安全集成並不意味著所發現的問題更少，這裡我們再次看到熟悉的曲折過程
解讀：實際上這個問題多少已經有所不同，直至Level 5仍然比Level 1的程度要高，但是這並不是一個問題，安全問題就在那兒，我們對應還是不對應，都改不了它存在的本質，把頭埋在沙子裡或者掩耳盜鈴並不是聰明者的做法，而且明顯地可以看到整體的趨勢會向好，這才是這個統計結果所反饋給我們的內容。
15、理想的組織結構
不只是進行安全集成，在整體進行DevOps實踐的過程中，被問到的最多的問題之一大概就是“推動DevOps實踐時理想的組織結構是什麼樣的？”，目前的答案可能會另很多人失望：“需要視情況而定”。確實為了更好地實施DevOps，組織結構需要調整成什麼樣子才更有效率會有很多制約因素，比如包括：
組織文化
組織結構的靈活程度
團隊成員和團隊領導者之間的關係
職能團隊分割的狀況
團隊成員知識技能的實際狀況
…
雖然很難給出答案，但是就如同2018年的調查內容一樣，調查結果本身對我們可能就有一定的參照性，2019年根據調查者的反饋，根據組織大小不同，安全職能相關的組織結構如下圖所示：
而安全集成程度和組織結構的關係如下圖所示：
從中我們可以看到：
有48%的受訪者擁有一箇中心化的安全團隊對於交付團隊提供按需支持的能力，超過10億美金營收的企業這一比例達到57%。
有31%的受訪者擁有一箇中心化的安全職能，而交付團隊本身也有安全相關的專家成員，營收在1億～10億美金之間的企業這一比例達到46%
只有14%的受訪者有著去中心化的安全職能結構，每個交付團隊都有著自己專職的安全專家，這種結構對於營收在1百萬一下的小型公司中更為常見。
解讀：需要注意的是Level 3中無論是按需的中心化職能從Level 1的57%下降至44%，而同時是否有專職的安全專家方面的比例也有了一個非常顯著的提升，根據調研報告的分析推測，大概是在Level 1～Level 2的時候這方面並沒有足夠的資投資，而到了Level 3，隨著安全集成的成熟度的升高，對此也越加重視，所以團隊有了專門的安全專家予以支持，聽起來也比較合理，在2020年後續的調查中是否展開我們也將會繼續確認。
總結
在DevOps的演化中，安全的集成和演化發生在較後的階段這並非偶然，跨職能團隊的協作和責任共擔的理念需要團隊不斷成熟才能更好地理解和執行，安全的融入也是這樣，就像早期我們打破開發和運維之間的那堵牆一樣，安全的融入需要同樣的方式和原則來打破部門的隔閡，雖然不可避免地會出現J曲線的看似反覆的曲折過程，但是達到成熟階段的整體方向和趨勢是不會改變的。
參考內容
https://puppet.com/resources/report/state-of-devops-report/
https://wiki.owasp.org/index.php/Category:Threat_Modeling
https://owasp.org/www-project-top-ten/
聲明：本文為CSDN博主「liumiaocn」的原創文章，博文鏈接：https://blog.csdn.net/liumiaocn/article/details/104890968。
☞從VMWare到阿里神龍，虛擬化技術40年演進史
☞奇奇怪怪的知識增加了，大括號的歷史你知道嗎？
☞一站式殺手級AI開發平臺來襲！告別切換零散建模工具
☞那些神一樣的程序員
☞通過Python代碼實現時間序列數據的統計學預測模型
☞比特幣當贖金，WannaRen勒索病毒二度來襲！
☞你知道嗎？其實Oracle直方圖自動統計算法存在這些缺陷！（附驗證步驟）
閱讀更多 CSDN 的文章
