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

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

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

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

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

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

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

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

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

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

●提供 API 集成作為平臺方法的一部分——將代碼從開發環境推送到生產環境，將有助于簡化工程團隊的工作流程，無需擔心每個階段添加的安全技術，因為它已經融入系統。無代碼或低代碼平臺可以更輕松地插入安全工具并運行它。

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

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

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

預料到陷阱，并避免它

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

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

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

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