DevSecOps的三種解讀

DevSecOps現在是一個熱門辭彙，我喜歡它，也討厭它。

我喜歡它，因為它具體化了美國證券交易委員會行業(包括我在內)多年來一直試圖實現的一個目標——讓開發人員擁有自己的安全性。這個簡單的流行語給我們的使命舉起旗幟，幫助它鼓足動力，推動它成為一種常態。

討厭它，因為，就像所有的流行語一樣，它沒有正確地反映出這漫漫旅程背後的高度複雜性。安全性是一個廣泛的主題，涉及基礎設施、應用程序代碼、網路堆棧、第三方供應商，當然還有人員。追求安全的方式涉及很多細節，但流行詞沒有怎麼考慮這些細微差別。於是就難免不同的人用它來表達不同的意思——或者至少強調的是不同的部分。

這並不奇怪，許多流行語也有類似的情況。更具體地說，如果你在一個房間里有三個專家，你會得到對術語「DevOps」的4種解釋和對「雲」的5種解釋。雖然我們永遠不會得到一個唯一的定義，但把不同的觀點寫下來仍然是有幫助的，因為它們能讓我們區分別人在使用這個術語時表示的是什麼意思。

著眼於它的不同用法，我發現了DevSecOps這個詞的三個主要含義。這些觀點代表DevSecOps旅程中的不同里程碑，並與DevOps本身的共通解釋保持一致。讓我們仔細研究每一個，將這個美妙而可怕的術語帶入到一種更深的層次。

DevSecOps作為「DevOps技術的安全保障」

DevSecOps最直接的翻譯可能是描述DevOps帶來的一波技術的安全解決方案。雲、容器和無伺服器等技術是DevOps運動的關鍵。每一個都提供了新的功能並引入了新的技術棧，這些技術棧反過來又有特定的安全需求。

支持這些技術的第一步是使用現有的安全產品(主要用於舊的棧)，並在DevOps環境中添加所需的技術組件去使用它。這些都是對現有工具的小改動，而不是工具運維方式的實質性改變，只是為了支持新的環境。

我們以容器安全性為例。Symantec、McAfee、TrendMicro和其他公司都提供端點安全解決方案，包括反惡意軟體、監控惡意網路活動等。這些成熟的產品長期用於伺服器和虛擬機，在概念上同樣適用於容器。然而，容器和主機之間的控制，以及其他技術上的差異，使得這些產品無法支持開箱即用的容器，並要求它們進行調整。TrendMicro的深度安全產品就是一個很好的例子，它在版本10中增加了容器支持，並在主機和容器之間劃分了新的職責。這一變化足以使他們號稱參與了DevSecOps運動，儘管該產品仍然主要用於傳統的安全環境。

在保護DevOps技術的道路上更進一步是安全解決方案，它解決了這些技術引入的新安全需求。這裡的示例包括CloudCheckr和Evident.io檢查雲配置以查找無意中留下的存儲桶(以及其他問題，如下圖所示)，或者Snyk在開放源碼庫中尋找漏洞。處理更新的技術需要新穎的思維方式，而對於那些已經傾向於傳統思維方式的企業來說，這通常更加困難。因此，這通常是初創公司的領域，大公司通過收購來介入，而不是從頭開始構建解決方案。

圖:CloudCheckr的雲安全評估結果

容器很好地說明了這個場景。主機和容器之間的隔離並不完美，這一事實產生了一個新的風險——在容器中運行惡意代碼會從容器沙箱中跳出來並影響主機。由於相同的物理主機經常運行不同級別的容器，甚至屬於不同的所有者，沙箱逃逸是一個真正的、直接的威脅。容器帶來的這些額外的新風險為專註於容器安全的初創企業打開了大門，比如Sysdig、Aqua和Twistlock，它們會使容器更為堅固，並標記試圖突破容器的安全性。這些初創公司通常會安全將自己定位為DevSecOps公司。

在這兩種情況下，DevSecOps一詞都是指確保DevOps技術的安全性。也就是說，這些解決方案中有一些自然地滲入了我們應用devops的方式，這讓我們有了下一個含義……

DevSecOps作為「DevOps方法論的安全保障」

除了技術之外，DevOps還採用了強大的新方法論，如持續交付(CD)和微服務(接下來是無伺服器)。這些技術將導致更快的開發和更細粒度的組件，這兩種技術都將快速破壞現有的安全方法。

又一次，這些新方法需要對現有玩家進行演進。讓我們以CI/CD為例。

持續交付的採用意味著在發布過程中「為審核而停下來」不再被接受，而是需要在管道中進行強大的自動化安全測試。對自動化的需求引起了對靜態應用程序安全測試(SAST)工具的關注，但是這些工具花費了太長時間(通常是幾個小時)來完成單個代碼掃描，這在頻繁的構建環境中是不可行的。為了適應這種情況，大多數SAST工具引入了增量掃描的概念，只測試更改過的代碼。這些掃描完成得更快，因此可以適用於管道。再一次，這些調整常常被用來展示DevSecOps的威力。

雖然這種適應很重要，但往往還不夠。一些新的方法不僅改變了技術設置，而且還打破了現有工具所依賴的核心概念，這需要重新考慮整個產品——這又是一個初創企業擅長的領域。微服務安全監控就是一個很好的例子。

從獨體大型應用程序到微服務的移動改變了應用程序的定義，現在不再通過一組輸入和輸出來監視實體，而是數據在多個不同服務之間的流動，有時甚至上百個。在這樣的環境中成功地實時識別攻擊需要一個完全不同的安全監視解決方案，該解決方案可擴展到監視大量服務和它們之間的數據流。像Aporeto這樣的初創公司通過跟蹤服務到服務通信和標記未授權的連接嘗試來解決這個問題，而像SignalSciences這樣的初創公司則專註於將每個服務的安全性洞察與各自的操作指示板統一起來。

圖:Aporeto映射微服務和不可信連接標記(Aporeto演示網路研討會)

除了克服這些新方法的挑戰之外，這些專用的解決方案還利用了它們提供的機會。例如，雖然容器在邏輯上與vm相似，但它們通常是無狀態的，並部署在高彈性環境中。因此，關閉一個行為可疑且可能受到損害的容器是完全合理的，因為不會丟失任何數據，並且系統只會啟動個新的。這種粗劣的回應顯然不是裸機主機的選擇，在大型虛擬機中也不可行。而且，實際上，您將很難找到一種端點安全解決方案，可以在警報狀態下撤下一台機器，而實際上所有的容器和微服務安全初創公司都大力提倡這樣做。

有種更廣泛的解釋，是與只關注技術相比，DevSecOps要調整適應DevOps方法論，從長遠來看，這種解釋更有價值。它通常也需要一些技術支持(例如，如果沒有支持容器，就不能保證微服務的安全性)，並繼續理解和調整安全性以適應正在制定的新流程。然而，儘管它觸及了金三角的兩個部分(人、過程、技術)，但它仍然忽略了最重要的部分。

DevSecOps作為「DevOps共享所有權哲學的安全保障」

DevOps的核心不是技術或方法，而是人員和協作。它是關於接受」讓我們的軟體運行良好是每個人的問題，並且我們分擔責任去解決它」。DevOps反對開發「把代碼扔過牆」的做法，因為運維可以處理和幫助項目事務處理人員每天面對的約束。

這種文化和哲學的轉變推動了新的方法和技術。它導致開發人員編寫更多可運維的代碼，運維將基礎設施以及大量後續的軟體和技術視為代碼，以使其規模化。這種轉變才真正地讓企業在競爭中更快、更好。

DevSecOps的最後一幅最寬闊的景象也遵循著同樣的腳步。要以DevOps的速度真正解決安全問題，我們必須將它嵌入到常規的開發和操作過程中。由於安全團隊的人數就像之前的運維團隊一樣被開發人員的數量遠遠拋開，實現共享所有權的唯一方法是讓開發團隊執行大部分的日常安全活動。剩下的工作應該主要由運維來完成，安全團隊應該花大部分時間使其他團隊能夠完成常規工作，管理和自動化這個活動(「安全性即代碼」，延續「基礎設施即代碼」)。

對於現有的安全解決方案來說，這是一個艱難的變化。這些企業的建立是為了迎合安全專業人士，並且他們的整個上市模式以及他們的世界觀都專註於這個行業。他們發起安全事件，使用安全人員的術語，並根據安全行業的標準對產品定價。安全廠商越大，他們改變目標市場的損失就越大，這樣做的可能性就越小。

更重要的是，安全產品的設計主要是為了幫助信息安全人員完成他們的日常工作，而開發人員都通常是從這種扭曲的視角完成開發。結果與VMWare構建IDE或Citrix創建CI產品時的情況類似。這些都是功能強大的運維工具，但他們沒去考慮開發人員，所以不太可能為這些用戶設計合適的工具。

有趣的是，DevSecOps的哲學更適合相反的方向，那就是擁抱安全的公司的開發人員做工具。這些公司已經贏得了開發人員的心和思想，現在可以讓這些開發人員在他們的DevOps之旅中更進一步。源代碼供應商可以解決代碼安全性問題，APM供應商可以監控安全性缺陷，而管道供應商可以讓流轉過程更為穩定。

這不再是一個理論上的機會。在2017年，我們看到GitHub將安全警報添加到repos、谷歌Chrome在其內置開發工具中標記脆弱人JavaScript庫，而Sysdig也推出了容器安全產品。這些公司也有一個學習曲線來理解如何構建安全解決方案，但是它們定位在了正確的位置上。

圖:Chrome開發工具標記脆弱的JavaScript庫

最後，對於創業公司來說，這是一個絕好的機會。銷售給開發人員比他們的安全部門要高效得多，因為前者的銷售成本要低得多。此外，如今的CSO也越來越多地提出他們已經學著忽略電話銷售了，但開發團隊已經接受的安全解決方案，並仍將投入注意力。我們現在已經清楚，開發人員是運維領域的新擁護者，安全也可能會步其後塵。

目前，很少有安全公司關注開發人員。在認證領域有一個很好的例子，Auth0為開發者贏得了大量的文檔、最底層的定價模型和強大的社區論壇和程序。他們最新推出的價值5500萬美元的D系列是贏得回報的一個標誌。在此，我可以給出的另一個例子，我自己的公司斯奈德，它修復了開源依賴中的漏洞。我們主要關注開發人員，從深度開發工具集成，到許多思想領導力活動，投資於自動化的修復，這對開發人員比對審計人員更有幫助，並且獲得了巨大的回報。

圖:將自動修復引入GitHub內的開發人員上下文。

統計數據顯示，真正採用DevOps哲學的組織無論使用何種技術和方法，都能獲得更好的商業結果。我希望那些真正採用DevSecOps的組織能夠在保持自身和用戶數據安全方面得到同等的提升。

理解DevSecOps

DevSecOps是一個熱門辭彙，它不會消失。這個詞很快就會成為信息安全的流行詞，而且這個詞越熱，就會有越多的公司和供應商使用它，不管它的意思是什麼。

下次您遇到使用這個術語的解決方案時，我希望本文將幫助您正確地對其進行分類。它是支持DevOps技術、適應DevOps方法論的安全解決方案，還是支持DevOps哲學並幫助您改變組織?或者它可以適用於許多情況?有了正確的分類，可以幫助您消除噪音，專註於DevSecOps任務。

關於作者

Guy Podjarny(@guypod) 是斯奈德的聯合創始人兼CEO，專註於使用開源並保持安全性。Guy在收購了自己的初創公司Blaze之後，曾在Akamai擔任首席技術官，並參與了第一個web應用程序防火牆和安全代碼分析器工作。Guy經常在會議上發言，著有O"Reilly的《安全性開源庫》、《響應和快速》和《高性能圖像》。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！