DevOps、DevSecOps、左移、安全態勢、云原生……說起現代應用程序的開發生命周期，大家總會聽到上面這些詞。它們作為解釋復雜流程的框架時，作用積極，誤用或濫用則反而有害。無論是刻意為之還是無意間的誤用，用戶在面對這些流行詞時往往都無法準確理解其背后代表的真正含義。

[[407274]]

DevOps與DevSecOps就是濫用與誤用之下造成不少負面影響的典型案例。自2009年被首次提出以來，DevOps所涵蓋的內容已經發生過多次迭代，其中的負面含義往往源自交流背景中種種不切實際的烏托邦元素、以及難以真正落地的理想假設。盡管不少組織堅稱自己以DevOps為中心，但卻幾乎沒多少人能真正準確地做出定義。沒有正確實踐作為前提，DevOps向團隊及企業做出的承諾也將無從談起。

DEVOPS與DEVSECOPS之間有何區別?

DevOps的實現依賴于五大核心組件： 敏捷框架、 一次構建/隨處運行的開發方法、一切即代碼、自動化、溝通與協作。

在全面普及之后，DevOps能夠加快部署速度、降低故障率并增強恢復能力。而這一切都將幫助團隊乃至企業打造出周期更短、適應性更強、質量更好的產品。但這也給我們提出了新的問題——如何把安全考量融入進去?DevSecOps的重點，正在于以符合安全要求的方式擴展DevOps核心原則。

理解DevSecOps的一種重要方法，在于拆分DevOps核心組件并審視適合在哪里插入安全要素。

(1) 敏捷框架——敏捷方法仍然是當今軟件開發生命周期(SDLC)的主要內容。與瀑布式開發方法相反，敏捷開發更強調短周期加小變化的組合，確保組織能夠針對客戶反饋做出快速反應。

然而，敏捷框架面臨著安全隱患。運營反饋從何而來?是否符合安全要求?這類框架在加快開發周期方面確實表現不錯，但卻又常常受制于運營與安全要求。開發人員希望將運營與安全工作交給支持性工具負責，自己則快速行動、一路奮勇向前。

總而言之，敏捷專注于提升開發人員的行動速度，也取得了不錯的效果;但其中的重點只有開發本身，一切運營與安全元素都成為事后才考慮的元素。

(2) 一次構建、隨處運行——容器技術讓SDLC更上一層樓。作為一項真正具有顛覆性的技術，容器使得開發人員能夠獨立于運營資源之外進行編碼、構建、運行以及測試。如今，由于開發人員不必分神設置運營環境，他們可以將更多精力集中在測試、安全與擴展方面。利用容器技術，一切都可由Dockerfile所容納并實現隨處運行。在提交最終鏡像之前，開發人員根本不需要接觸運營工作;但在整個過程中，運營仍然始終存在、在不知不覺中為開發者提供支持。

雖然存在這種開發與運營之間的隔絕，容器本身仍然是一項重大成就，而容器的起效又離不開編排工具的引導。

到這里，我們要請出下一位重量級嘉賓——Kubernetes。

Kubernetes使組織得以高效管理、擴展、觀察并接入容器。它將Dockerfile的需求抽象為可以管理及擴展的明確對象。這種聲明式抽象要求開發人員與運營人員開展溝通，進而有效運用Kubernetes。隨著時間推移，雙方的交流將逐漸升級、最終將安全問題納入進來。

(3) 自動化——那么，安全或者運營團隊又該如何要求、或者說約束開發人員?

通過在不影響開發速度的情況下向開發人員提供直接反饋，自動化成為實現DevSecOps的關鍵所在。單元測試、代碼分析與鏡像掃描已經成為可輕松被添加至持續集成(CI)管道的常見工具，即時向開發人員通報必要修改。在開發團隊的協作下，這些變更可以快速被集成至現有管道當中。運營與安全團隊應該明白，他們越早提供自動化反饋機制，開發人員就能越早適應這種新的協作模式。

這一點對安全團隊來說極為重要。在組織當中，安全團隊往往被視為一種“令人心煩”的存在，因為這幫家伙總在強調根本不可能實現的所謂“100%安全系統”。但行之有效的DevSecOps可不是這么簡單粗暴。

借助新的工具與最佳實踐，安全團隊可以為開發人員提供穩定且安全的基礎鏡像，由此不斷提升代碼質量。安全團隊還可以在管道中引入自動檢查機制，監控一切包含權限提升行為的YAML文件、未匹配網絡策略的命名空間或者存在漏洞及風險的容器鏡像。

(4) 一切即代碼——Kubernetes及其他編程語言的聲明性質，極大提高了基礎設施與應用程序的可重用性與可理解性。YAML文件將幫助各團隊準確理解容器如何才能發揮預期作用。時鐘時間、卷掛載以及secret注入等一切行為都可通過這個文件及注釋進行觀察。這種方法還讓代碼成功呈現為文檔的形式，以供隨時進行版本控制并實現迭代變更。

但即使有了最新、最好的工具，如果無法正確記錄和編目具體問題，一切努力仍然可能是徒勞的。沒有清晰的文檔，將很難跨團隊分享經驗教訓。而在嘗試新的管道配置時，各團隊掌握的經驗教訓很可能對其他團隊有著決定性的指導作用。因此，請使用代碼與版本控制系統充分展示變更內容，并允許各方據此開展討論。否則隨著單一團隊的快速推進，知識共享體系將土崩瓦解，各團隊間再難開展充分交流。

(5) 溝通與協作——如果團隊和個人間不進行充分溝通，那么一切代碼、應用程序與安全變更都將毫無意義。而IT部門中最常忽視的一大溝通要點，在于對意圖的明確解釋。

DevOps與DevSecOps之所以難以發揮其全部潛力，一大核心原因就是相關行動的意圖往往未被各方正確理解。安全團隊并不是要阻礙開發工作，他們只是在完成自己的本職工作并保證應用程序安全。而開發團隊雖然也關心安全性，但他們面前的頭號難題永遠是如何在限期之內讓新功能順利上線。

組織必須努力彌合各團隊之間的差距，專注于吸取教訓，鼓勵合理的嘗試失敗，并設定出切合實際的后續目標。從文化角度來看，這種變化通常由高層自上而下推動。在重視這種方法的組織當中，開發、運營及安全團隊會樂于討論哪些意圖較合理、哪些不合理，并愿意站在對方的立場上考慮問題。

DEVSECOPS將向何處去?

總而言之，DevSecOps向我們提出了以下幾項重點要求：

• 要求在快速迭代的軟件開發生命周期中建立嵌入式自動安全檢查機制
• 可重用的各開發環境間具有同類型的安全控制機制
• 版本控制CI管道
• 以組織或團隊職能范圍為邊界進行管道變更，借此改善事件后的安全調查流程
• 完善的說明文檔，最好以聲明式方法實現安全即代碼
• 鼓勵創新，并接納由此帶來的失敗文化

請注意，本文沒有明確指定任何具體工具。DevSecOps代表的是一種文化變革，其背后代表的思維方式轉變不限于任何特定工具。當然，大家也應盡可能采用支持協作解決問題的工具，包括保證其具有良好的可移植性、可觀察性并提供簡單易懂的說明文檔。最重要的，還有獲得團隊的支配以建立起可跨團隊共享的上下文素材。

結合種種成功案例與理論層面的巨大潛能，相信DevSecOps這波不斷發展的浪潮終將成為我們手中的有力武器。