青藤云安全首先介紹了DevSecOps的發展歷程，將安全融入開發和運維中，讓安全更好的前移以取得更好的效果;其次說明了DevSecOps的解決方案以及相關的工具，如何讓DevSecOps更好的落地;然后提到了容器安全，因為容器是讓DevSecOps更好落地的基礎設施，容器安全從某種意義來說是DevSecOps的基礎安全;最后提到了DevSecOps的最佳實踐。

引發DevSecOps的這個概念背后有很強大的變化，安全一般來說是服務于其他信息技術，如果相應的技術或者解決方案或者流程發生變化，安全也要隨之改變，否則無法適應新的技術的安全要求。這里面的最重大的變化有三個：開發流程的變化;技術架構的變化;IT基礎設施環境的變化。

傳統的軟件開發流程分為六個階段：需求、設計、開發、實現、部署、維護。最常見的開發模型就是瀑布式的開發流程，將所有的階段進行規劃，然后執行。這樣的流程好處就是階段明顯，但是最大的弊端就是只要一個階段發生延期就會導致所有的延期，而且每個階段需要的人不一樣，互相溝通的機制也很少。瀑布式開發模型會極大的拖慢整個開發周期，所以引入了敏捷開發來解決這個問題。敏捷開發解決的核心問題就是持續交付，讓軟件的交付周期變短，是一個增量的、迭代式的開發模式。可能不是一次性交付所用的功能和特性，而是在每一次交付中有一些功能和特性的交付。開發人員這樣的交付速度，很明顯會給安全人員帶來挑戰，怎么在每一次的迅速交付中來保證安全?敏捷開發的流行必然形成了DevOps的趨勢，即開發運維一體化。

技術架構也由之前的單體應用向微服務架構調整。之前開發的產品基本屬于單體應用，大部分僅需進行進程內通信即可完成相關的功能。但是隨著解決問題的復雜性水平越來越高，同時為了更好的提高可用性以及運維的可維護性，引入了微服務的理念和架構。微服務很明顯的好處就是拆散了系統的復雜性，降低了系統的耦合性，提高了系統的可維護性。同時也可以在高可用、平行擴展上天然支持，而不需要外部運維組件支持。微服務的架構也需要安全人員關注的粒度要足夠細，之前可能只用關注一個應用的安全即可，對于微服務架構每個服務的安全都需要關注。

傳統的IT技術架構的變化也是驚人的。目前上云的趨勢已經成為主流，大部分公司的數據中心已經云化，無論私有云、混合云還是公有云。云計算除了帶來了很好的節省成本的優勢，同時也帶來了效率和速度的提升。尤其是云原生應用的興起，一切組件和相關的服務都在云端解決，自動化水平空前提高。特別提到的容器技術這個虛擬化技術可以更好的加快DevOps的落地。

從人員的角度來看，因為需求部門和開發部門的壁壘，敏捷開發出現了，持續交付的過程中讓需求和開發部門更好的溝通，而這種情況會引發開發和運維的矛盾，為了更快捷的交付引入了DevOps這種組織和實踐。在DevOps的過程中發現，安全的問題需要考慮進來，按照歷史的慣性，一開始只是開發運維走到了一起，安全的要素還是事后考慮，大部分的情況下安全人員還是屬于事后處置，安全效果沒有得到很好的提升，一個很明顯的現象是開發人員在部署最新的技術架構，而安全人員還在關注傳統的安全問題。為了解決這個問題，所以在整個流程中加入了安全的人員形成了DevSecOps這種協同機制或者特殊崗位，可以讓安全人員更早的介入開發和運維的過程，讓安全的措施向前移動，主要的目的是讓所有的技術人員都對安全負責。

DevSecOps角色交叉圖

在之前微軟提出的SDL流程中更多是側重于威脅建模(Threat modeling)，注重的階段全是在產品研發階段，忽略了運維的階段。DevSecOps剛好同時解決了開發和運維的安全問題。在實施DevOps過程中，實際的安全挑戰比較大，通過下面的Gartner統計圖可以發現DevOps團隊跟安全的協作是他們首要考慮的問題。

DevOps關心問題統計圖

在DevSecOps的實際人員配比中，開發人員、運維人員以及安全人員的比例是100:10:1，安全人員的配備是最少，同時交付的頻率又是很高的，大概是一天一個交付。安全的問題也很突出，做過的歷史經驗統計大概每千行的代碼Bug數量是0.5-10個區間，同時在222行代碼中就可能有5個直接引用庫，可能高達54依賴庫存在。同時在DevOps的過程中，香港服務器租用，運維人員的工具化水平已經比較高，大部分流程都是通過自動化的工具進行處理。

DevOps運維工具集