將安全融入 DevOps：啟用技巧

當新冠疫情發生時，很多公司不得不迅速改變他們的業務模式。事實上，許多人開始忽略了某些安全方面的問題，而這些問題是為擁有快速開發週期和為客戶提供新功能所做的權衡。現在是時候回過頭來重新審視安全政策和準則，以及如何最好地將它們整合到敏捷開發過程中。

當今許多組織面臨的最大挑戰是安全團隊幾乎總是與工程和運營組織分開。隨著新興的雲和雲原生技術的出現，安全團隊需要集中管理、監控和處理工程團隊的工作流。

為了在工程組織內建立安全思維，安全團隊必須為工程團隊提供適合其工作流程的工具。如果安全團隊的解決方案只是將包裝程式碼放在安全團隊要求的工具之上，那麼它將成為一種附加的管理技術，可能會減慢進度。

將安全融入敏捷和 DevOps 的工作方式中

很多人認為當安全被納入流程時速度會降低，但這是一種誤解。如果安全策略和閘門未整合或自動化到軟體交付系統中，則上市時間通常會延遲。即使有一個集中的安全團隊，讓他們成為敏捷開發流程和整個 DevOps 轉型之旅的一部分，也將幫助所有團隊更快、更有效地解決出現的安全問題。

DevOps在很大程度上被象徵為一個無限的連續反饋迴路的概念。如果我們把安全實踐放在這個無限的符號之上，安全策略就會從頭到尾被整合起來--計劃、構建、配置、測試、分析和監控。這描述了一組可以分配給不同應用程式團隊的共同目標，並使他們能夠對某些安全策略擁有所有權，而不是一個擁有安全策略責任和任務的集中團隊。

以下是一些需要考慮的步驟和做法：

●首先，工程和運營團隊需要預測威脅，不僅在應用程式層面，而且在基礎設施層面。對出現的問題做出反應是很麻煩的，團隊需要積極應對這種情況。這是人們現在正在創造的一種心態，而這種心態在新冠疫情剛剛發生時並不一定存在。

●集中式或聯合式的安全模式是實用的，但不能在第一天就實施。在這種組織範圍內的模式建立之前，它必須經歷逐步的轉變，以瞭解軟體交付管理的整體觀點。就像敏捷一樣，它是一個框架，需要隨著時間的推移進行審查和改進。

●構建一種通用方法，包括定義靜態程式碼分析、動態程式碼分析和程式碼漏洞監控方面所需的關鍵安全策略。這些政策可以從平臺的角度為應用團隊實現自動化和協調化。這使得安全領導更容易從這些不同的團隊中獲得可見性和洞察力。它還建立了關於存在哪些差距以及如何改進的必要反饋迴圈。

●提供 API 整合作為平臺方法的一部分——將程式碼從開發環境推送到生產環境，將有助於簡化工程團隊的工作流程，無需擔心每個階段新增的安全技術，因為它已經融入系統。無程式碼或低程式碼平臺可以更輕鬆地插入安全工具並執行它。

●無論您是否授權工程和運營團隊選擇工具，一種新興的做法是利用可擴充套件的、無程式碼的整合編排平臺來補充工程和運營流程。這將使安全實踐得以遵循，並且可以按照他們交付軟體的速度進行管理和維護。

●研究每個應用程式的情況，包括使用的技術，以及消費者如何使用該解決方案。這為所有的應用程式建立了一個基線，而不考慮技術、雲基礎設施、平臺等。這將有助於從安全威脅的角度根除誤報，併為後續步驟提供更清晰的畫面。如果誤報始終是強制性的安全補救措施(即使它可能不是實際威脅)，軟體交付的速度就會受到影響。

例如，使用 Spring Boot 微服務和 Node.js。在 Spring Boot 微服務中，你可能會有很多誤報，作為一個高度警惕的關鍵漏洞。實際上，這些並不是阻止程式碼部署到生產的關鍵漏洞。這種考慮必須迴圈到安全策略中，以瞭解它的需求、授予異常並管理未來的安全異常。這提供了管理異常的基線，以允許程式碼首先投入生產。如果安全團隊因為此類誤報而繼續停止流程，並且不瞭解應用程式環境和業務需求，那麼安全性可能會成為執行團隊和整個企業的麻煩事。

預料到陷阱，並避免它

最常見的陷阱是安全團隊對應用環境沒有足夠的瞭解，以及在公司的產品組合和平臺環境方面如何對業務下游產生影響。安全團隊需要在所有這四種情況下接受培訓，以瞭解需要實施哪些政策和準則。

從軟體工程的角度來看，人們總是在推動更高的速度。但是，對安全框架的戰略思考並不總是這種思維方式的一部分。

集中式的安全團隊經常推動為每一段被推送到生產中的程式碼制定政策。但安全團隊可能不提供API整合，例如，使這個過程更容易。僅僅實施安全策略是沒有任何好處的。

最終，目標是在集中式安全團隊和軟體工程團隊之間建立夥伴關係，以實現DevOps轉型之旅的承諾。為了確保開發和部署的獨特程式碼是安全的，需要一個漸進的學習過程，以及對應用團隊和軟體交付系統的需求有更多的瞭解。只有這樣才能在此基礎上建立一個安全框架。這種方法和思維的演變將使我們在未來更容易適應新出現的威脅，並在這個不確定的時代提供企業所需的可見性和控制力。