4大維度3大預測，基於容器生態擴張的DevSecOps為啥引關注？

DevSecOps可能不是一個優雅的術語，但其結果是有吸引力的: 在開發的早期帶來更強大的安全性。DevOps最終是要建立更好的軟體，也意味著更安全的軟體。

像任何IT術語一樣，DevSecOps--由DevOps衍生而來，很容易被炒作和盜用。但是這個術語對擁抱DevOps文化的IT領導者以及實現其承諾的實踐和工具而言，具有真正的意義。

DevSecOps什麼意思？

Datic公司首席技術官兼共同創始人RobertReeves說：「DevSecOps是開發，安全和運維的組合。它提醒我們，對於應用程序來說，安全和創建、部署到生產上同樣重要。」

向非技術人員解釋DevSecOps的一個簡單方法：它有意識地更早地將安全性融入到開發過程中。

紅帽安全戰略家Kirsten Newcomer 最近告訴我們： 「歷史上，安全團隊從開發團隊中分離出來，每個團隊都在不同的IT領域擁有深厚的專業知識 。「其實不需要這樣。關心安全的企業也非常關心通過軟體快速交付業務價值的能力，這些企業正在尋找方法，將安全性留在應用開發生命周期內。通過在整個CI / CD中集成安全實踐，工具和自動化來採用DevSecOps。」

她說：「為了做到這一點，他們正在整合團隊。安全專業人員將從應用開發團隊一直嵌入到生產部署中。」 「雙方都看到了價值，每個團隊都拓展了他們的技能和知識基礎，成為更有價值的技術專家。正確的DevOps或DevSecOps ，提高IT安全性。」

IT團隊的任務是更快，更頻繁地交付服務。DevOps成為一個很好的推動因素，部分原因是它可以消除開發和運營團隊之間的一些傳統衝突，Ops通常在部署之前被排除在外，而Dev將其代碼丟在無形的牆上，從來不進行二次管理，更沒有任何的基礎設施維護責任。說得委婉一些，在數字化時代，這種孤立的做法會產生問題。按照Reeves的說法，如果安全是孤立的，也會存在類似的問題。

Reeves說：「我們採用DevOps，它被證明可以通過掃除開發與運維之間的障礙來提高IT的性能。「就像不應該等到部署周期結束才開始運維一樣，也不應該等到最後才考慮安全問題。」

DevSecOps為什麼會出現？

將DevSecOps看作是另一個流行語是一種誘惑，但對於安全意識強的IT領導者來說，這是一個實質性的概念。安全必須是軟體開發流程中的「一等公民」，而並非最終步驟部署，或者更糟糕，只有在發生實際的安全事件後才受到重視。

SumoLogic公司安全與合規副總裁George Gerchow表示：「DevSecOps不僅僅是一個流行詞，由於諸多原因它是IT的當前和未來狀態。「最重要的好處是能夠將安全性融入到開發和運營流程中，為實現敏捷性和創新提供保障。」

此外，在場景中出現的DevSecOps可能是DevOps自身正在成熟並深入挖掘IT內部的另一個標誌。

「企業DevOps文化意味著開發人員能夠以更快的速度向生產環境提供功能和更新，特別是當自組織團隊更加樂於協作和衡量結果。」CYBRIC首席技術官兼聯合創始人Mike Kail說。

在採用DevOps的同時，保持原有的安全實踐的團隊和公司會遇到更多的管理安全風險的痛苦，因為DevOps團隊會部署地更快、更頻繁。

手動測試安全方法逐漸落後

「目前，手動測試安全方法逐漸落後，利用自動化和協作將安全測試轉移到軟體開發生命周期，從而推動DevSecOps文化，這是IT領導者提高整體彈性和交付安全保證的唯一路徑。」凱爾說。

（早期）對安全性測試的改變也讓開發人員受益：在開發新服務或部署更新服務之前，他們並沒有發現代碼中的明顯漏洞，而是經常在開發的早期階段發現並解決潛在的問題，幾乎沒有安全人員的介入。

SAS首席信息安全官Brian Wilson表示：「正確的做法是，DevSecOps可以將安全性納入開發生命周期，使開發人員能夠更快，更方便地保護應用程序，不會造成安全乾擾。

Wilson將靜態（SAST）和源代碼分析（SCA）工具集成到團隊的持續交付中，幫助開發人員在代碼中對潛在問題，以及第三方依賴的漏洞進行反饋。

Wilson說：「開發人員可以主動、反覆地緩解app的安全問題，並重新進行安全掃描，無需安全人員參與。DevSecOps還可以幫助開發團隊簡化更新和修補程序。

DevSecOps並不意味著企業不再需要安全專家，就像DevOps並不意味著企業不再需要基礎架構專家一樣。它只是有助於減少瑕疵進入生產的可能性，或減緩部署。

DevSecOps遭遇的危機

來自Sumo Logic公司的Gerchow分享了DevSecOps文化的實例：當最近的Meltdown和Spectre消息出現時，團隊的DevSecOps方法能夠迅速做出響應，以減輕風險，而對內外部客戶沒有任何明顯的干擾。 對雲原生和受高度監管的公司來說非常重要。

第一步，Gerchow的小型安全團隊（具備開發技能）能夠通過Slack與其主要雲供應商之一合作，確保基礎設施在24小時內完全修補好。

「然後，我的團隊立即開始了OS級別的修復，不需要給終端用戶停機時間，也無需請求工程師，那樣意味著要等待長時間的變更管理流程。所有這些變化都是通過Slack打開自動化Jira tickets進行的，並通過日誌和分析解決方案進行監控，「Gerchow解釋說。

這聽起來像DevOps文化，正確的人員、流程和工具組合相匹配，但它明確地將安全作為該文化和組合的一部分。

Gerchow說：「在傳統環境下，停機需要花費數周或數月的時間，因為開發、運營和安全這三項功能都是孤立的。憑藉DevSecOps流程和理念，終端用戶可以通過簡單的溝通和當天的修復獲得無縫的體驗。」

02

2018DevSecOps三大預測

2018年企業的DevSecOps將迎來一些真正的變革。

對於DevSecOps來說，2017年是美好的一年，DevSecOps從一個半朦朧的概念演變成可行的企業功能。

容器和容器市場的迅速擴張在很大程度上推動了這一演變，容器市場本質上與DevOps和DevSecOps相互交織在一起。一般來說，快速增長和創新往往比科學更能預測趨勢，但我仍然願意嘗試一下。

從Docker Hub和成熟的容器生態系統中獲取了超過120億張圖片，就企業的DevSecOps而言，我們幾乎看不到冰山的一角。不過，相信在2018年，我們將看到：基礎變革的開始。我認為它會是這樣的：

>>>>1.企業領導者和IT利益相關者意識到DevSecOps正在改進DevOps

DevOps將開發團隊和運維團隊聚在一起，它推動協作文化不足為奇。加入安全舉措可能聽起來很簡單，但多年來，安全問題一直是事後的事情，導致企業文化容易使安全團隊與其他IT團隊形成對立，包括開發團隊。

但是事情發生了變化。

在雅虎虧損3.5億美元的商業環境下，暴露了其脆弱的安全狀況，企業領導者將網路安全看作是一個運維sinkhole的時代已經結束。加強網路安全現在是企業的當務之急。但這種轉變需要時間才能重新回到IT文化中。

DevOps和DevSecOps的崛起無疑為重塑應用程序安全性創造了一個難得且令人興奮的機會，但是DevOps可能會導致轉變速度發生變化。DevOps團隊和應用程序架構師每天都能夠認識到安全的重要性，並歡迎安全團隊的加入，但他們之間仍然存在需要磨合的鴻溝。

為正確實施DevSecOps，安全團隊需要與DevOps團隊保持一致，企業領導者需要為此打造空間和預算。到2019年，希望企業領導人能夠意識到推動一個重要的、合法的安全勝利的機會。

>>>>2.成功的組織模式將會出現，最可能的是，安全與DevOps團隊之間的緊密協作。

雖然該預測並不特別具有啟發性，但是相關的。了解DevSecOps需要來自安全和DevOps團隊的平等協作，快速跟蹤標準藍圖或實施模型，將DevSecOps集成（並最終自動化）到CI / CD進程中。

雖然不同企業有不同的需求，但大多數公司都使用相同的技術工具，特別是在使用容器的情況下。這就為統一的標準化提供了條件。此外，容器的開源特性可以促進相關信息的共享和標準開發。

到目前為止，由於DevOps團隊擁有開發流程，他們一直在安全方面處於領先地位。然而，我認為，DevSecOps需要由安全團隊領導， 他們是負責企業安全和風險的人，當安全事故發生時，他們會被解僱或被迫離開。

2018年，安全團隊需要加強並展示團隊的價值和技能。將安全性融入到IT結構中，而不是在網路安全問題成為事實之後才想起。現在我們有機會來實現這一目標。

>>>>3.安全團隊仍然要緩慢適應DevOps的現實

過去，企業安全團隊通常在不重視或不了解安全需要的文化中運營。難怪今天的電商環境是大多數企業相對容易被破壞的環境。

強大的安全性不僅僅是外圍的防火牆。儘管許多安全專家可能最終會看到這種轉變，但可能不像DevOps團隊所期望的那樣靈活。當談到容器（通常是appsec）時，即使是最有才華和最優秀的安全專家也會面臨學習的瓶頸。更不用說已經被充分證明的網路安全技能短缺的現狀。

雖然這些因素可能在短期內降低安全對DevOps和 DevSecOps的支持，但是我認為DevSecOps是解決技能短缺問題的一部分。將安全集成到應用程序交付過程中，並將其自動化比用回溯方法更有效率和更具成本效益，可以解決在部署應用程序之前解決安全漏洞。安全專業人士可以通過開放的態度，以新的方式發揮他們的才能，從而獲得很多收益。

2018年希望這個故事有一個快樂的結局。

推薦閱讀：

企業級落地容器與DevOps，選用K8S都有哪些「姿勢」

7大ChatOps&5種團隊協作工具助力DevOps實踐

如果沒按這7種習慣，你可能實踐的是假DevOps

這款分散式配置中心，會是微服務的降維打擊利器嗎？

從架構到組件，深挖istio如何連接、管理和保護微服務2.0？

添加小數微信：xiaoshu062

備註公司、姓名、職位

小數將拉您進入相應技術群

數人云shurenyun.com

推薦閱讀：